In der dritten Juliwoche 2026 sind zwei Meldungen erschienen, die auf den ersten Blick in entgegengesetzte Richtungen zeigen. Am 20. Juli hat das Next.js-Team ein Security-Release mit neun CVEs veröffentlicht, vier davon mit hoher Schwere, verbunden mit der klaren Ansage, bitte sofort patchen. Drei Tage später hat GitHub angekündigt, dass Dependabot neue Paketversionen ab jetzt standardmäßig drei Tage liegen lässt, bevor es einen Update-PR öffnet. Einmal Tempo, einmal angezogene Handbremse.
Der Widerspruch löst sich auf, wenn man die beiden Fälle auseinanderhält, und genau darum geht es in diesem Beitrag. Die Unterscheidung zwischen “eine bekannte Lücke ist öffentlich” und “eine neue Version ist erschienen” ist inzwischen die wichtigste Weiche in jeder Update-Strategie.
Was GitHub geändert hat
Dependabot legt bei Versions-Updates jetzt eine Wartezeit von drei Tagen ein. Erscheint eine neue Version eines Pakets, entsteht der zugehörige Pull Request nicht mehr am selben Tag, sondern frühestens 72 Stunden später. Die Änderung ist der neue Standard und automatisch aktiv, ohne dass jemand seine Konfiguration anfassen muss.
Die entscheidende Ausnahme steht direkt dabei: Security-Updates sind vom Cooldown ausgenommen und kommen weiterhin sofort. Sobald ein Advisory zu einer Abhängigkeit veröffentlicht ist, wartet Dependabot keine Sekunde, denn ab diesem Moment kennen auch Angreifer die Lücke.
Warum Warten schützt
Die Begründung liefert GitHub gleich mit, und die Zahlen sind deutlicher, als man erwarten würde. In der Advisory-Datenbank landen im Schnitt rund 18 neu katalogisierte bösartige npm-Pakete pro Tag. Bei einer Auswertung von 21 gemeldeten Vorfällen aus den Jahren 2018 bis 2026 wurden die bösartigen Versionen jeweils innerhalb von Stunden nach Veröffentlichung wieder entfernt. In einem Fall waren kompromittierte Pakete gerade einmal zwei Stunden live, bevor die Community sie erwischte.
Foto: nate_dumlao / Unsplash
Das ist das Muster fast aller Supply-Chain-Angriffe über Paket-Registries: Der Schadcode wird eingeschleust, fällt schnell auf und wird entfernt. Gefährlich ist er fast nur für die Projekte, die ihn in genau diesem kurzen Fenster automatisch einsammeln. Eine unabhängige Auswertung von zehn bekannten Angriffen macht die Fenster konkret. Beim Angriff auf das chalk-Paket lagen unter zwölf Stunden zwischen Veröffentlichung und Entdeckung, bei Nx waren es vier Stunden, bei rspack eine, bei tj-actions drei Tage. Acht der zehn untersuchten Angriffe hatten ein Fenster von unter einer Woche. Der große Ausreißer bleibt xz-utils mit rund fünf Wochen, ein langfristig angelegter Fall, gegen den keine realistische Wartezeit geholfen hätte.
Daraus ergibt sich eine unspektakuläre, aber wirksame Rechnung. Wer neue Versionen drei Tage liegen lässt, verpasst nichts außer der Ehre, Erster zu sein, und lässt die Mehrheit der Angriffe ins Leere laufen. Mit sieben Tagen hätte man acht der zehn dokumentierten Fälle abgefangen, mit vierzehn alle bis auf xz-utils. Der Schutz kostet exakt nichts.
Der Gegencheck: das Next.js-Release
Bleibt die Frage, ob man sich mit der Wartezeit nicht an anderer Stelle ein Loch reißt. Das Next.js-Security-Release vom 20. Juli ist dafür der passende Testfall. Neun CVEs, darunter vier mit hoher Schwere, von Denial of Service über einen Middleware-Bypass bis zu Server-Side Request Forgery. Die gepatchten Versionen 15.5.21 und 16.2.11 standen bereit, und jede Stunde Verzögerung war ab Veröffentlichung eine Stunde, in der Angreifer die öffentlich dokumentierten Lücken gegen ungepatchte Anwendungen richten konnten.
Genau dieser Fall läuft am Cooldown vorbei. Ein Advisory existiert, also erstellt Dependabot den Update-PR sofort, und der gehört dann auch zügig gemerged und deployt. Die Handbremse gilt nur für den Normalfall ohne bekanntes Sicherheitsproblem. Wer beide Situationen gleich behandelt, macht es in beide Richtungen falsch, entweder zieht er riskant frische Versionen am Tag null, oder er lässt öffentliche Lücken tagelang offen.
Cooldown konfigurieren
Der Drei-Tage-Default lässt sich in der dependabot.yml pro Ökosystem anpassen. Ein Beispiel mit sieben Tagen Wartezeit für npm-Pakete:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
cooldown:
default-days: 7
Foto: cdr6934 / Unsplash
Wer feiner steuern will, kann Major-Sprünge länger reifen lassen als Patch-Releases, denn ein Major bringt ohnehin Umbauarbeit mit und profitiert am meisten davon, wenn die Community die ersten Kinderkrankheiten schon gefunden hat. Wichtig zu wissen ist, was der Cooldown nicht abdeckt: Er bremst nur Dependabots eigene PRs. Ein npm install von Hand zieht weiterhin die frischeste Version. Wer die Schutzwirkung bis dorthin ausdehnen will, findet die passenden Stellschrauben im Paketmanager selbst, pnpm nennt sie minimumReleaseAge, Renovate minimum-release-age, uv das Flag exclude-newer.
Was ich für kleine Teams davon halte
Ich betreue eine ganze Reihe von Projekten, in denen Updates über Dependabot laufen, und aus dieser Praxis heraus finde ich die Änderung überfällig. Der Reflex, jede neue Version möglichst am Erscheinungstag einzuspielen, stammt aus einer Zeit, in der das größte Risiko veraltete Pakete waren. Das hat sich gedreht. Veraltete Pakete bleiben ein Problem, aber die akuteste Gefahr im npm-Ökosystem ist inzwischen die zu frische Version, die noch niemand angeschaut hat.
Für kleine Teams und Einzelentwickler ist der Cooldown deshalb ein Geschenk, weil er die eine Schutzmaßnahme ist, die keinerlei laufende Arbeit erzeugt. Kein zusätzliches Tool, kein Dashboard, keine Prozesse. Der Default von drei Tagen ist dabei bewusst vorsichtig gewählt, und wer keinen Grund für maximale Frische hat, kann ihn ohne schlechtes Gewissen auf sieben Tage stellen. Die Gegenseite der Abmachung muss man dann allerdings ernst nehmen: Security-Alerts gehören eingeschaltet, und wenn ein echtes Security-Update aufschlägt, ist es fällig, nicht irgendwann.
Unterm Strich ist das eine seltene Sorte Sicherheitsmaßnahme, nämlich eine, die Arbeit wegnimmt statt welche zu machen. Drei Tage Geduld bei Routine-Updates, null Geduld bei bekannten Lücken. Mehr Strategie braucht der Normalfall nicht.
Wenn in deinem Projekt seit Monaten niemand mehr Updates eingespielt hat oder du nicht sicher bist, ob Dependabot und die Security-Alerts überhaupt aktiv sind, melde dich gerne. Ich schaue mir den Stand an und richte den Update-Prozess so ein, dass er ohne tägliche Aufmerksamkeit sicher läuft.
Häufige Fragen
Verzögert der Cooldown nicht auch wichtige Sicherheits-Fixes?+
Nein. Der Drei-Tage-Default gilt nur für normale Versions-Updates. Sicherheits-Updates, die auf einem bekannten Advisory basieren, erstellt Dependabot weiterhin sofort. Die Logik dahinter ist sauber, denn bei einer veröffentlichten Lücke läuft die Uhr gegen dich, bei einem gewöhnlichen Versionssprung läuft sie für dich.
Welche Cooldown-Dauer ist sinnvoll?+
Der Default von drei Tagen ist ein brauchbarer Kompromiss. Eine Auswertung von zehn dokumentierten Supply-Chain-Angriffen zeigt, dass acht davon ein Angriffsfenster von unter einer Woche hatten. Sieben Tage hätten diese acht abgefangen, vierzehn Tage alle bis auf den xz-utils-Fall, der rund fünf Wochen unentdeckt blieb. Für Projekte ohne Release-Druck sind sieben Tage eine vernünftige Einstellung, bei Major-Versionen darf es auch mehr sein.
Gilt der Cooldown auch, wenn ich Pakete von Hand installiere?+
Nein, Dependabot bremst nur seine eigenen Update-PRs. Ein npm install zieht weiterhin die neueste Version. Wer die Schutzwirkung auch dort will, kann beim Paketmanager ansetzen, pnpm bietet dafür die Einstellung minimumReleaseAge, Renovate kennt minimum-release-age und uv das Flag exclude-newer. Damit ignoriert auch die Handinstallation zu frische Versionen.
Reicht ein Cooldown als Schutz vor Supply-Chain-Angriffen?+
Er ist eine von mehreren Schichten, aber eine bemerkenswert günstige. Ein Cooldown kostet nichts, erfordert keine neuen Tools und filtert die Mehrheit der dokumentierten Angriffe allein über die Wartezeit. Gegen langfristig angelegte Angriffe wie xz-utils, wo der Schadcode über Wochen unauffällig blieb, hilft er nicht. Deshalb gehören Security-Alerts, Lockfiles und ein wacher Blick auf ungewöhnliche Paketänderungen weiterhin dazu.
Du willst mehr erfahren?
In einem kostenlosen Erstgespräch besprechen wir, wie du diese Themen für dein Unternehmen nutzen kannst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung.
Kostenloses Erstgespräch vereinbaren
