Dependabot wartet jetzt: 3 Tage gegen Paket-Malware

Am 23. Juli 2026 hat GitHub um 16:00 UTC eine Änderung angekündigt, die auf den ersten Blick unspektakulär wirkt, in der Praxis aber ziemlich viel verschiebt: Dependabot wartet bei Versionsupdates künftig standardmäßig mindestens drei Tage, bevor ein Pull Request überhaupt erstellt wird. Wer Abhängigkeiten in Projekten pflegt, kennt das Muster – ein neues Release erscheint, Dependabot registriert es fast in Echtzeit, und Minuten später liegt ein Update-Vorschlag im Repository. Genau dieses Tempo hat GitHub jetzt gedrosselt, allerdings nicht überall gleich.

Die Änderung betrifft ausschließlich reguläre Versionsupdates, also das automatische Anheben von Paketversionen ohne sicherheitsrelevanten Anlass. Sie hat nichts mit der Geschwindigkeit zu tun, mit der sicherheitsrelevante Patches ausgerollt werden. Diese Unterscheidung ist der Kern der ganzen Neuerung, und sie verdient mehr Aufmerksamkeit, als eine kurze Ankündigung normalerweise bekommt.

Versionsupdates und Sicherheitsupdates: der entscheidende Unterschied

GitHub trennt bei Dependabot seit jeher zwei Update-Arten, die sich in ihrer Dringlichkeit fundamental unterscheiden. Versionsupdates reagieren auf jede neue Paketversion, unabhängig davon, ob sie Bugfixes, neue Funktionen oder einfach nur eine Aufräumaktion des Maintainers enthält. Sicherheitsupdates dagegen entstehen aus konkreten Advisories – aus dokumentierten, bekannten Schwachstellen, die in einer Abhängigkeit gefunden wurden.

Die neue Wartezeit von drei Tagen gilt ausschließlich für die erste Kategorie. Sicherheitsupdates öffnen weiterhin sofort, ohne Verzögerung, ohne cooldown, ohne Ausnahmeregelung, die erst greifen müsste. Wenn eine Schwachstelle bekannt wird, die eine Ihrer Abhängigkeiten betrifft, bekommen Sie den entsprechenden Pull Request also genauso schnell wie bisher. GitHub hat an dieser Front nichts verändert, und das ist auch gut so, denn ausgerechnet bei Sicherheitslücken wäre jede zusätzliche Verzögerung schwer zu rechtfertigen.

Bei Versionsupdates sieht die Lage anders aus. Hier hat GitHub offenbar ein Muster beobachtet, das viele Teams aus eigener Erfahrung kennen: Manipulierte oder kompromittierte Paketversionen werden häufig kurz nach der Veröffentlichung entdeckt und dann vom Registry-Betreiber oder vom Maintainer wieder entfernt. Wer sofort automatisiert aktualisiert, riskiert, genau in diesem kurzen Zeitfenster eine problematische Version einzuziehen, bevor die Community überhaupt reagieren konnte.

Man sollte diese drei Tage aber nicht überbewerten. Eine Wartezeit macht ein Update nicht sicher, sie verschafft lediglich mehr Zeit für Entdeckung und Reaktion. Das ist ein Unterschied, der in vielen Kommentaren zur Ankündigung untergeht, und genau deshalb lohnt sich die Klarstellung an dieser Stelle.

Warum GitHub die Lieferkette so genau im Blick hat

Die Zahlen, mit denen GitHub die Entscheidung untermauert, sind deutlich. Laut eigener Advisory-Datenbank wurden im Jahr bis Mai 2026 mehr als 6.500 npm-Malware-Advisories veröffentlicht. Umgerechnet bedeutet das rund 18 neu katalogisierte bösartige npm-Pakete pro Tag. Diese Größenordnung erklärt, warum GitHub nicht länger bei einer rein reaktiven Haltung bleiben wollte.

Man muss sich diese Dimension bewusst machen, um die Entscheidung nicht als bloße Bequemlichkeit misszuverstehen. Wenn täglich knapp zwei Dutzend neue bösartige Pakete im npm-Ökosystem auftauchen, ist die Wahrscheinlichkeit, dass ein automatisiertes System eines davon aufgreift, kein theoretisches Risiko mehr, sondern eine statistisch fassbare Größe. Angriffe auf die Software-Lieferkette funktionieren gerade deshalb so zuverlässig, weil viele Prozesse auf Geschwindigkeit statt auf Prüfung optimiert sind. Dependabot war in seiner ursprünglichen Ausrichtung genau so ein Prozess: schnell, aber ohne eingebaute Verzögerung.

Einige bösartigen Versionen fliegen erst nach wenigen Tagen auf, weil Sicherheitsforscher, Community-Mitglieder oder automatisierte Scanner erst dann anschlagen. In dieser Lücke zwischen Veröffentlichung und Entdeckung haben sich in der Vergangenheit wiederholt Angriffe abgespielt, bei denen kompromittierte Maintainer-Zugänge oder gezielt eingeschleuste Schadfunktionen in scheinbar harmlosen Patch-Releases landeten. Eine automatisierte Wartezeit adressiert genau dieses Zeitfenster, ohne den gesamten Update-Prozess lahmzulegen.

Wie stark solche Lieferkettenrisiken in der Praxis durchschlagen, lässt sich auch an anderer Stelle beobachten. Es gibt Bereiche, in denen sich Supply-Chain-Probleme besonders unmittelbar zeigen, etwa dort, wo wie sich Supply-Chain-Risiken bei Container-Workflows konkret bemerkbar machen – ein Umfeld, in dem eine kompromittierte Abhängigkeit sich schnell über mehrere Ebenen eines Deployments fortpflanzen kann.

GitHub selbst begründet den Schritt ausführlich in einem eigenen Beitrag, der die Motivation hinter der Wartezeit im Detail beschreibt. In GitHubs Begründung für die dreitägige Wartezeit wird deutlich, dass es dem Unternehmen weniger um eine allgemeine Verlangsamung geht, sondern um eine gezielte Reaktion auf beobachtete Angriffsmuster im npm-Ökosystem und darüber hinaus.

Der cooldown-Parameter in der dependabot.yml

Technisch umgesetzt wird die neue Wartezeit über einen cooldown-Parameter in der Konfigurationsdatei dependabot.yml. Wer bereits mit Dependabot arbeitet, kennt diese Datei als zentralen Ort, an dem Update-Intervalle, betroffene Verzeichnisse und Ignore-Regeln definiert werden. Der cooldown-Parameter reiht sich dort ein und legt fest, wie lange Dependabot nach einer neuen Version wartet, bevor ein Update-Pull-Request erstellt wird.

Die genauen Details zur Syntax und zu den verfügbaren Optionen lassen sich direkt in die Dependabot-Dokumentation zum cooldown-Parameter nachlesen. Wichtig ist an dieser Stelle vor allem eines: Der Standardwert von drei Tagen greift automatisch, sobald keine eigene Konfiguration hinterlegt ist. Teams, die andere Vorstellungen von der passenden Wartezeit haben, können den Wert über die Konfigurationsdatei anpassen, entweder verkürzen oder verlängern, je nach eigener Risikobereitschaft und Update-Kadenz.

Wer stark auf schnelle Feature-Updates angewiesen ist, etwa weil ein Projekt aktiv an neuen Funktionen einer Bibliothek hängt, wird die drei Tage möglicherweise als spürbare Bremse empfinden. Das ist eine berechtigte Sorge, und GitHub hat mit dem konfigurierbaren Parameter reagiert, statt eine starre Regel ohne Ausweg vorzugeben. Trotzdem bleibt festzuhalten: Der Standardwert wurde nicht willkürlich gewählt, sondern orientiert sich an den beobachteten Zeitfenstern, in denen problematische Pakete typischerweise entdeckt und zurückgezogen werden.

Was die Wartezeit für Entwicklungsteams bedeutet

Für die tägliche Arbeit ergeben sich aus dieser Änderung mehrere praktische Konsequenzen. Erstens: Wer Dependency-Updates als festen Bestandteil des Sprints plant, muss die drei Tage in den eigenen Rhythmus einkalkulieren. Ein Update, das am Montag erscheint, landet frühestens am Donnerstag als Pull Request im Repository. Für Teams mit wöchentlichem Update-Review ist das meist kein Problem, für Teams, die auf tagesaktuelle Patches setzen, schon eher.

Zweitens verändert sich die Erwartungshaltung gegenüber Dependabot selbst. Bisher galt das Tool vielen als reiner Geschwindigkeitsmesser – je schneller ein Update vorgeschlagen wurde, desto aktueller die eigene Codebasis. Diese Logik funktioniert jetzt nur noch für Sicherheitsupdates uneingeschränkt. Bei regulären Versionsupdates tritt an die Stelle der reinen Geschwindigkeit eine bewusst eingebaute Verzögerung, die man als Reifezeit verstehen kann. Das ist meiner Ansicht nach die richtige Priorität, denn nicht jedes Update muss am Tag der Veröffentlichung eingespielt werden, während jede offene Sicherheitslücke tatsächlich zählt.

Drittens betrifft die Änderung auch die Art, wie Betriebsteams über Patchstände sprechen. Wenn ein Audit oder eine interne Richtlinie verlangt, dass Abhängigkeiten binnen bestimmter Frist aktualisiert werden, muss diese Frist die neue Wartezeit berücksichtigen. Ähnliche Fragen stellen sich schon länger in anderen Kontexten, etwa dort, wo warum Patchstände bei GitHub Enterprise Server inzwischen sogar Supportwege beeinflussen – ein Beispiel dafür, wie technische Patch-Details plötzlich organisatorische Konsequenzen bekommen, die weit über die reine IT-Abteilung hinausreichen.

Viertens sollten Sie sich fragen, ob Ihre bestehenden Alerts und Dashboards die neue Trennung zwischen Versionsupdates und Sicherheitsupdates überhaupt sauber abbilden. Wenn ein Monitoring-System beide Kategorien bislang undifferenziert als „offene Dependabot-Pull-Requests“ zählt, verschwimmt genau die Unterscheidung, auf die es jetzt ankommt.

Checkliste für den Umgang mit Dependabot-Updates

Damit die neue Wartezeit nicht nur zur Kenntnis genommen, sondern auch praktisch eingeordnet wird, lohnt sich ein kurzer Blick auf die wichtigsten Punkte, die Sie jetzt prüfen sollten:

• Prüfen Sie, ob Ihre dependabot.yml bereits einen cooldown-Wert definiert oder ob der Standardwert von drei Tagen greift.
• Stellen Sie sicher, dass Ihre internen Prozesse Sicherheitsupdates weiterhin ohne Verzögerung behandeln, unabhängig von der neuen Wartezeit für Versionsupdates.
• Passen Sie Sprint- oder Review-Zyklen so an, dass die drei Tage nicht zu unnötigen Leerläufen bei der Update-Planung führen.
• Kontrollieren Sie Dashboards und Alerts darauf, ob sie Versionsupdates und Sicherheitsupdates getrennt ausweisen.
• Dokumentieren Sie intern, warum ein Update erst nach der Wartezeit erscheint, damit Nachfragen aus anderen Teams nicht zu Verwirrung führen.
• Beobachten Sie nach der Einführung, ob sich die Anzahl zurückgezogener oder problematischer Paketversionen in Ihrem Stack tatsächlich reduziert.

Dependabot im Kontext größerer Lieferketten-Strategien

Die dreitägige Wartezeit ist kein isoliertes Feature, sondern Teil einer Entwicklung, bei der GitHub zunehmend versucht, Automatisierung und Vorsicht in ein neues Verhältnis zu bringen. Man kann diese Verschiebung als Reaktion auf eine Branche lesen, die lange Zeit Geschwindigkeit über Prüfung gestellt hat. Ist es wirklich sinnvoll, jedes neue Release binnen Minuten in Produktionssysteme zu übernehmen, nur weil es technisch möglich ist? Diese Frage stellt sich nicht erst seit dieser Ankündigung, aber sie bekommt durch die Zahlen zu npm-Malware-Advisories ein deutlich schärferes Gewicht.

Gleichzeitig zeigt sich, dass einzelne Schwachstellen oder kompromittierte Pakete selten isoliert bleiben. Sie entfalten ihre Wirkung oft erst dann richtig, wenn sie in bestehende Automatisierungsketten eingespeist werden, die ohne menschliche Kontrolle weiterlaufen. Genau an dieser Stelle wird deutlich, wie aus einer bekannten Lücke ein echter Patchdruck für Betriebsteams wird, sobald eine Schwachstelle öffentlich dokumentiert ist und Angreifer gezielt nach ungepatchten Systemen suchen. Dependabot kann diesen Druck nicht vollständig auffangen, aber es kann die Wahrscheinlichkeit senken, dass ein Team ein kompromittiertes Update überhaupt erst automatisiert übernimmt.

Wichtig bleibt dabei die Erwartungssteuerung: Die Wartezeit ist ein zusätzlicher Sicherheitsmechanismus, kein Ersatz für Code-Reviews, Signaturprüfungen oder eigene Abhängigkeitsanalysen. Wer glaubt, mit drei Tagen Wartezeit sei das Thema Lieferkettensicherheit erledigt, unterschätzt die Bandbreite der Angriffsmethoden, die im npm-Ökosystem längst dokumentiert sind. Genau deshalb sollte die Änderung als ein Baustein unter mehreren verstanden werden, nicht als abschließende Lösung.

Governance-Fragen jenseits von Dependabot

Die Einführung einer Standard-Wartezeit wirft auch grundsätzlichere Fragen zur Governance automatisierter Prozesse auf. Wer entscheidet, welche Verzögerung angemessen ist? Wie transparent werden solche Entscheidungen kommuniziert, und wie leicht lassen sie sich für einzelne Projekte anpassen? GitHub hat sich hier für einen zentral gesetzten, aber konfigurierbaren Standardwert entschieden – ein Kompromiss, der einerseits Sicherheit für die Mehrheit der Projekte erhöht, andererseits Flexibilität für Teams mit abweichenden Anforderungen lässt.

Diese Balance zwischen zentraler Vorgabe und lokaler Anpassbarkeit taucht auch in anderen Bereichen der Plattform zunehmend auf, etwa bei der Frage, wie viel Autonomie automatisierte Agenten innerhalb von Repositories bekommen sollen. Solche Governance-Debatten laufen derzeit parallel auf mehreren Ebenen, und Dependabot ist dabei nur ein besonders sichtbares Beispiel für ein grundsätzliches Muster: Automatisierung wird nicht zurückgenommen, sondern mit mehr Kontrollpunkten versehen.

Häufige Fragen zu Dependabot und der neuen Wartezeit

Verzögert die Wartezeit auch Sicherheitsupdates?

Nein. Die dreitägige Wartezeit gilt ausschließlich für reguläre Versionsupdates ohne sicherheitsrelevanten Hintergrund. Sicherheitsupdates, die aus dokumentierten Advisories entstehen, werden von Dependabot weiterhin sofort als Pull Request bereitgestellt, ohne cooldown und ohne zusätzliche Verzögerung durch den neuen Standardwert.

Kann ich die Wartezeit individuell anpassen?

Ja. Über den cooldown-Parameter in der dependabot.yml lässt sich der Standardwert von drei Tagen verändern, sowohl verkürzen als auch verlängern. Details zur genauen Konfiguration und den verfügbaren Optionen finden sich in der offiziellen Dependabot-Dokumentation, die den Parameter ausführlich beschreibt.

Am Ende bleibt die Erkenntnis, dass Dependabot mit dieser Änderung erwachsener geworden ist, ohne seine Kernfunktion zu verlieren. Die Wartezeit adressiert ein reales, mit Zahlen belegtes Problem im npm-Ökosystem, sie verändert aber nichts an der Dringlichkeit, mit der echte Sicherheitslücken behandelt werden müssen. Wer Dependabot in seinen Projekten einsetzt, sollte die neue Standardeinstellung nicht ignorieren, sondern bewusst in die eigene Update-Strategie einbauen – und dabei genau im Blick behalten, welche Updates wirklich warten können und welche das nicht dürfen.