Dein Blog zum Thema digitales Business

Der schnellste Pull Request ist nicht der sicherste

Ein Update-Bot kann den Pull Request kurz nach dem Release einer Paketversion öffnen. Renovate tut das, solange du minimumReleaseAge nicht setzt, Dependabot wartet nach der Doku standardmäßig 3 Tage. Ein Dependabot cooldown dreht das um: Der Bot wartet eine festgelegte Zeit, bevor er eine neue Version vorschlägt. Denn der Zeitpunkt direkt nach dem Release ist der, an dem am wenigsten Menschen diese Version gesehen haben.

Die Renovate-Doku nennt als Zweck nicht, schnell veröffentlichende Projekte zu bremsen, sondern Risiken in der Lieferkette zu senken. Die Wartezeit lasse Sicherheitsforschern und automatisierten Werkzeugen Zeit, bösartige Absicht in Paketen zu erkennen. Wie real dieses Risiko ist, zeigt der GitHub-Blogbeitrag vom 22.09.2025: Er beschreibt einen sich selbst verbreitenden Wurm, der über kompromittierte Maintainer-Konten bösartige Post-Install-Skripte in verbreitete JavaScript-Pakete einschleuste.

Dieser Beitrag zeigt, wie du eine Wartezeit in Dependabot, Renovate und npm einstellst, wo die drei Optionen nicht dasselbe tun und was mit Sicherheitsupdates passiert. Ob Dependabot oder Renovate besser passt, klärt Dependabot vs. Renovate, nicht dieser Beitrag.

Grundlage sind die Dependabot-Optionsreferenz, die Renovate-Seiten zu minimumReleaseAge und Minimum Release Age, die npm-Konfigurationsreferenz und die GitHub-Changelogs zu npm v12 und zur Freigabe von npm v12, Stand 26.09.2026. Wo eine Aussage aus der Doku stammt, steht die Quelle im Satz, Empfehlungen sind als solche gekennzeichnet.

Dependabot cooldown: was die Option tut

Laut Optionsreferenz definiert cooldown eine Wartezeit für Abhängigkeits-Updates in Tagen. Die Option gilt nur für Versionsupdates, nicht für Sicherheitsupdates. Wichtig ist der Standard: Dependabot wendet nach der Doku auch ohne Konfiguration eine Wartezeit von 3 Tagen auf Versionsupdates an, eine neue Version wird erst 3 Tage nach ihrem Release berücksichtigt. Diese Standardwerte überschreibst du mit cooldown. Die Optionen im Einzelnen:

• default-days: Wartezeit für alle Abhängigkeiten ohne eigene Regel.
• semver-major-days, semver-minor-days, semver-patch-days: getrennte Fristen je Versionssprung, nur für Paketmanager mit SemVer. Fehlen sie, gilt default-days.
• include und exclude: Listen von Abhängigkeiten, für die der Cooldown gilt oder nicht gilt, mit Wildcards und bis zu 150 Einträgen. Steht ein Paket in beiden Listen, gewinnt exclude, und es wird sofort aktualisiert.

Laut Tabelle der Optionsreferenz unterstützt cooldown npm (dort als „NPM und Yarn“ geführt), sowohl default-days als auch die semver-*-days-Fristen. Nicht jedes Ökosystem kennt SemVer-Fristen, etwa Docker und GitHub Actions nicht.

Gerüst in der dependabot.yml, die Tageszahl ist ein Platzhalter und deine Entscheidung:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: <Tage>  # Platzhalter: ganze Zahl eintragen
      exclude:
        - "<internes-paket>"

Renovate minimumReleaseAge: gleiche Idee, andere Mechanik

Nach der Doku verlangt minimumReleaseAge, dass Renovate eine angegebene Zeit wartet, bevor es ein Update vorschlägt. Drei Eigenheiten sind wichtig:

• Pro Version, nicht pro Paket. Renovate wartet für jede Version einzeln. Es wartet nicht, bis das Paket eine Zeit lang ruhig war.
• Standardmäßig kein Branch. Der Standard von internalChecksFilter ist strict: Solange eine Version die Frist nicht erreicht hat, legt Renovate laut Konzeptseite weder Branch noch Pull Request an; sichtbar ist sie im Dependency Dashboard unter „Pending Status Checks“. Existiert ein Branch, trägt er einen „pending“ Statuscheck (renovate/stability-days), den Renovate nach Ablauf durch „passing“ ersetzt. Die Konfigurationsseite nennt zusätzlich die Kombination mit prCreation="not-pending"; läuft deine CI nur auf pull_request-Ereignisse, braucht es dort internalChecksAsSuccess=true, sonst kann die Erstellung unbegrenzt aufgeschoben werden.
• Der Zeitstempel kommt von der Registry. Die Datenquelle muss einen Release-Zeitstempel liefern. Die Konzeptseite begründet das damit, dass ein Maintainer den Zeitpunkt sonst selbst vorverlegen könnte.

Als Beispiel für npm nennt die Doku 3 Tage: npm-Pakete, die jünger als 72 Stunden sind, können aus der Registry entfernt werden, was zu Störungen führen kann, wenn du schon darauf aktualisiert hast. Die Konzeptseite rechnet an anderer Stelle mit 14 Tagen als Beispiel. Beide Zahlen sind Beispiele der Doku, keine Vorgabe für dich.

{
  "packageRules": [
    { "matchDatasources": ["npm"], "minimumReleaseAge": "3 days" }
  ]
}

npm: min-release-age und ignore-scripts

Bot und Paketmanager sind zwei Schichten. Die Renovate-Doku empfiehlt ausdrücklich, die Mindestwartezeit in beiden zu setzen: Renovate kann die Einstellung des Paketmanagers nicht auslesen, und beim Aktualisieren der Lockfile kann eine transitive Abhängigkeit hereinkommen, die Renovates Prüfung nicht sieht. Für npm reicht Renovate dafür beim Erzeugen der Lockfile --before=<Datum> durch, und bei einer bereits vorhandenen before– oder min-release-age-Einstellung in der .npmrc gilt die strengere.

min-release-age ist in npm eine Konfigurationsoption (Standard null, Wert in Tagen). Nach der Doku baut npm den Baum so, dass nur Versionen installiert werden, die länger als die angegebene Zahl an Tagen verfügbar sind. Gibt es für die Abhängigkeiten keine passende Version, bricht der Befehl mit einem Fehler ab. Mit min-release-age-exclude nimmst du Paketnamen oder Glob-Muster aus, etwa interne Pakete.

ignore-scripts ist die zweite Hälfte der Geschichte, weil der im Einstieg genannte Wurm Post-Install-Skripte nutzte. Nach der Doku führt npm bei ignore-scripts=true keine Skripte aus package.json aus; ausdrücklich aufgerufene Befehle wie npm test oder npm run laufen weiter, aber ohne ihre Pre- und Post-Skripte. Der Standard ist false. Ab npm v12, laut GitHub-Changelog vom 08.07.2026 allgemein verfügbar, gilt zusätzlich: Die Skripte preinstall, install und postinstall von Abhängigkeiten sowie implizite node-gyp-Builds laufen nur noch, wenn du sie erlaubst (allowScripts steht standardmäßig auf aus). Die Freigabeliste pflegst du mit npm approve-scripts und npm deny-scripts, sie steht in der package.json und gehört ins Repository. Die Konfigurationsreferenz hält fest, dass --ignore-scripts die Einstellung allow-scripts überschreibt.

Empfehlung, keine Aussage der Doku: In CI-Installationen, in denen keine Abhängigkeit einen Build-Schritt braucht, ist ignore-scripts=true der härteste Schalter. Wo native Module gebaut werden, ist die Freigabeliste die feinere Lösung. Prüfe außerdem, ob dein eigener Build Skripte aus der package.json braucht, denn ignore-scripts überspringt sie mit.

Der Zielkonflikt: Wartezeit gegen Sicherheitsupdate

Ein Cooldown ist nur dann eine gute Idee, wenn er das Einspielen einer Schwachstellen-Korrektur nicht ausbremst. Die drei Werkzeuge gehen damit verschieden um:

Daraus folgt eine Lücke, die die Doku so nicht benennt: Die beiden Bots nehmen Sicherheitsupdates vom Cooldown aus, die npm-Einstellung nicht. Wer min-release-age in der .npmrc setzt, kann sich den Weg zum Fix selbst versperren. Empfehlung: Lege vorab fest, wer im Notfall ein Paket in min-release-age-exclude einträgt, und trage die Rücknahme gleich mit ein, sonst wird aus der Ausnahme ein Dauerzustand.

Ein Cooldown schützt außerdem nur gegen Versionen, die innerhalb der Frist auffallen. Eine manipulierte Version, die erst danach entdeckt wird, kommt trotzdem durch, und Versionen, die schon in deiner Lockfile stehen, betrifft er nicht. Das ist eine Schlussfolgerung aus der Funktionsweise, keine Aussage der Doku. Er ergänzt Review und Analyse und ersetzt sie nicht.

Einführen in vier Schritten (Empfehlung)

1. Ist-Stand lesen. Was steht in dependabot.yml, renovate.json und .npmrc? Bei Dependabot gilt ohnehin der 3-Tage-Standard.
2. Frist bewusst wählen. Die Doku nennt 3 Tage als Standard und Beispiel, 14 Tage als Beispiel. Frage dich, wie schnell du bei einem echten Sicherheitsproblem reagieren musst und welche Pakete du intern pflegst, und leite die Tage daraus ab.
3. Ausnahmen festlegen. Interne Pakete in exclude bzw. min-release-age-exclude, dazu der dokumentierte Notfallweg für Fixes.
4. Gegenprobe. Beobachte, dass der Bot eine frisch veröffentlichte Version tatsächlich zurückhält, und dass ein Sicherheitsupdate bei dir ankommt, ohne zu warten.

Wo das Thema an Nachbarthemen grenzt

Dependabot vs. Renovate behandelt die Werkzeugwahl, dieser Beitrag die Verzögerung frischer Versionen. Was eine Lockfile festhält und warum das gegen Aktualität steht, beschreibt Lockfiles richtig nutzen. Und wie riskant Pakete sind, die nur eine Person betreut, steht in Bus-Faktor 1. Der Cooldown beantwortet eine dritte Frage: Wann vertraust du einer neuen Version.

Wo Unterstützung ansetzt

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.