GitHub laesst seinen Update-Bot Dependabot kuenftig drei Tage warten, bevor er ein neues Paket vorschlaegt. Die Standard-Wartezeit soll verhindern, dass automatisierte Updates eine frisch gekaperte Version in Ihr Projekt ziehen. Der Schutz ist gratis, hat aber eine klar benennbare Luecke.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Zwischen dem Upload einer manipulierten npm-Version und dem ersten automatischen Update-Vorschlag von Dependabot sind bisher oft nur Minuten vergangen. Genau dieses Zeitfenster schliesst GitHub jetzt: Seit dem 14. Juli 2026 wartet der Bot standardmaessig drei Tage, bevor er eine neue Paketversion zur Aktualisierung anbietet.
Das Wichtigste in Kürze
- Dependabot oeffnet Versions-Update-Pull-Requests jetzt erst, wenn eine Release mindestens drei Tage alt ist.
- Die Wartezeit gilt als neuer Standard ueber alle Oekosysteme, ohne Konfiguration; Sicherheits-Updates bleiben ausgenommen und laufen sofort.
- Ausloeser ist eine Serie sich selbst verbreitender npm-Angriffe seit September 2025.
- Fuer deutsche Teams zahlt der Schritt auf NIS2- und CRA-Pflichten ein, ersetzt aber keine eigene Pruefung.
Was ändert sich für Ihre Dependency-Updates?
Dependabot verschiebt Routine-Updates jetzt um drei Tage, damit kompromittierte Releases in dieser Frist auffallen. Sicherheits-Updates gegen bekannte Luecken sind ausgenommen und erscheinen weiterhin sofort.
Bislang war die Wartezeit eine Option, die Teams seit Juli 2025 selbst in die dependabot.yml eintragen mussten. Jetzt dreht GitHub das Verhaeltnis um: Drei Tage Cooldown gelten als Voreinstellung, wer schneller aktualisieren will, muss das aktiv konfigurieren.[1]
Der Kern des Ganzen: Neue Releases sind das Haupteinfallstor fuer Lieferketten-Angriffe. Ein kurzes Warten gibt Sicherheitsscannern und Maintainern Zeit, eine manipulierte Version zu erkennen, bevor ein Bot sie in tausende Projekte merged.
Warum drei Tage einen npm-Wurm ausbremsen
Sich selbst verbreitende npm-Wuermer leben von den ersten Stunden nach der Veroeffentlichung. Ausgerechnet automatische Update-Bots tragen eine frische Schadversion am schnellsten weiter, weshalb GitHub sein eigenes Werkzeug verlangsamt.
Den Anlass liefert eine Angriffsklasse, die 2025 neu war. Im September 2025 ist mit Shai-Hulud der erste sich selbst verbreitende Wurm im npm-Oekosystem aufgetaucht: Einmal installiert, hat er die Umgebung mit dem Werkzeug TruffleHog nach Zugangsdaten durchsucht und mit gestohlenen Tokens selbsttaetig neue, verseuchte Paketversionen veroeffentlicht.
Ende 2025 hat Microsofts Sicherheitsforschung den Nachfolger Shai-Hulud 2.0 als aktive Kampagne eingestuft, 2026 sind weitere Wellen gefolgt.[2] Das Muster bleibt stabil: Der Angriff lebt von den ersten Stunden nach dem Upload.
Und genau hier liegt die Ironie. Automatische Update-Bots wie Dependabot sind der schnellste Weg, eine frische Schadversion in tausende Projekte zu tragen. GitHub bremst also sein eigenes Werkzeug.
Warum GitHub reagiert
Die Grenze: Der Cooldown steuert nur, wann Dependabot einen Pull Request oeffnet. Ein npm install in der CI-Pipeline oder auf dem Entwicklerrechner zieht weiter sofort die neueste Version.
Drei Tage Wartezeit sind kein Bollwerk, sondern eine Versicherung gegen die eigene Geschwindigkeit. Der Fehler waere, sie mit Sicherheit zu verwechseln und die eigene Pruefung einzustellen.
— Markus Seyfferth, Chefredakteur Dr. Web
Was deutsche Teams jetzt tun sollten
Die Software-Lieferkette abzusichern ist unter NIS2 Pflicht, und der EU Cyber Resilience Act verschaerft die Vorgaben ab September 2026. Der Cooldown hilft dabei, deckt aber nur einen Teil der Angriffsflaeche ab.
Fuer Unternehmen im Geltungsbereich von NIS2 ist die Absicherung der Software-Lieferkette keine Kuer mehr, sondern Teil der geforderten Risikomassnahmen. Wie schnell daraus eine Haftungsfrage wird, zeigt unsere Analyse, warum die Produktionshalle unter NIS2 zur Haftungsfalle wird.
Ab dem 11. September 2026 verlangt zudem der Cyber Resilience Act, dass Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden; die vollen Pflichten samt Komponenten-Stueckliste (SBOM) greifen ab dem 11. Dezember 2027. Dieselbe Dynamik treibt gerade den Markt fuer Cyberversicherungen, waehrend der Mittelstand ungeschuetzt bleibt.
Die Grenze der Neuerung ist wichtig: Der Cooldown steuert nur, wann Dependabot einen Pull Request oeffnet. Ein npm install in der CI-Pipeline oder auf dem Entwicklerrechner zieht weiter sofort die neueste Version. Dass Entwickler-Werkzeuge selbst zum Leck werden, haben zuletzt der hochgeladene Git-Datenabfluss bei Grok Build und die Attacke auf GitHubs KI-Agent gezeigt.
Verlaesst sich ein Team allein auf den Bot, sichert es nur einen von mehreren Zugaengen ab. Konkret heisst das: die Voreinstellung eher verschaerfen als abschalten und dieselbe Wartelogik auch dort verankern, wo Dependabot nicht hinreicht, in der CI-Pipeline.
Quellen
[1] GitHub Changelog: „Dependabot version updates introduce default package cooldown“ ↩
[2] Microsoft Security Blog: „Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack“ ↩
Mehr Newshunger?
- Cursor-Zero-Day: Wenn nur noch die volle Offenlegung schützt
- SAP-Patchday im Juli: Eine 9,9-Lücke trifft den Kern jedes ABAP-Systems
- GitLost: Wie sich GitHubs KI-Agent zur Preisgabe privater Repositories verleiten lässt
- NIS2: Die Produktionshalle wird zur Haftungsfalle
- Cyberversicherung: Der Markt boomt, der Mittelstand bleibt ungeschützt
