Drei Tage Update-Pause: Software-Lieferkette im Blindflug

7 Min. Lesezeit

Dependabot wartet bei Versionsupdates standardmäßig drei Tage, bevor es einen Pull Request öffnet. Für IT und Risikoverantwortliche im Mittelstand verschiebt sich die Frage von „automatisch aktuell“ zu „welche Update-Kanäle greifen wann – und wer freigibt, wenn etwas offen bleibt“. Die Policy trifft Teams, die Dependency-Updates als laufenden Hintergrundprozess behandeln und.

Verwandt:Wer drei Tage braucht, hat den Lead schon verloren  /  Predictive Logistics: Wenn Software den Nachschub vorausdenkt

Was die Verzögerung technisch und organisatorisch bedeutet

Technisch ändert die Cooldown-Phase nichts an Schwachstellen in Abhängigkeiten. Sie verschiebt den Zeitpunkt, ab dem ein Versionsupdate im Repository als Pull Request erscheint und in CI, Review und Release einfließen kann. GitHub hat die Änderung im Changelog vom 14. Juli 2026 und im Security-Blog beschrieben: Dependabot wartet bei Versionsupdates standardmäßig mindestens drei Tage nach Veröffentlichung einer Release, bevor es einen PR erzeugt. Laut GitHub-Dokumentation und dem Dependabot-Team gilt der Default über die unterstützten Package-Ökosysteme; Teams steuern ihn über die Option cooldown in der dependabot.yml und können ihn auf null setzen. Heise und der GitHub-Blog fassen denselben Mechanismus zusammen.

Entscheidend ist die Abgrenzung zu Security-Updates. Die dreitägige Pause gilt laut GitHub ausdrücklich nicht für Security-Updates: Bei bekannter Schwachstelle mit Advisory erstellt Dependabot Alert und Patch-PR weiterhin ohne diese Verzögerung. Die Cooldown-Phase zielt auf das Muster kurzer, giftiger Package-Releases – oft binnen Stunden erkannt und aus der Registry entfernt. Sie schützt damit vor dem unkontrollierten Nachziehen frischer Versionen; sie ersetzt weder Advisory-Monitoring noch Patch-Governance.

Organisatorisch reißt das die stillschweigende Annahme, ein Update-Bot decke den gesamten Pfad von Registry bis Produktion ab. Für viele Teams war Dependabot die Standardbrücke zwischen Registry und Pull Request. Wer Freigabeprozesse allein an den Eingang von Versions-PRs koppelt, steuert nur einen Kanal. Die Latenz sitzt vor dem ersten sichtbaren Versions-PR; Security-Alerts und alternative Scanner bleiben parallel nötig.

Wer betroffen ist: Eigenentwicklung, SaaS-Stack, Dienstleister

Am direktesten trifft es Organisationen mit eigener Softwareentwicklung auf GitHub und aktivem Dependabot Version Updates. Dort steuern Dependency-PRs oft Backlog, Security-Queue und Release-Zyklen. Mittelständische Produkt- und Plattformteams, die viele Open-Source-Bibliotheken bündeln, spüren die Pause dort, wo Teams bislang jede frische Version schnell übernehmen wollten. Weniger betroffen sind reine No-Code- oder Standardsoftware-Nutzer ohne eigene Dependency-Pipeline, solange der Hersteller den Patch-Prozess intern steuert.

SaaS-Stacks sind indirekt betroffen. Die eigene Firma baut vielleicht wenig und verlässt sich auf Anbieter, die Dependabot oder vergleichbare Bot-Ketten nutzen. Wenn der Dienstleister seine Lieferkette verlangsamt oder Security- und Version-Kanäle unklar trennt, bleibt das Risiko im Vertragsprodukt. Einkauf und Informationssicherheit brauchen Nachweise, wie der Provider kritische Dependency-Fixes priorisiert und welche SBOM- oder Update-Zyklen vertraglich gelten.

Dienstleister und Nearshore-Teams sind besonders relevant, wenn sie Repositories des Auftraggebers betreiben oder Libraries als Komponenten liefern. Eine dreitägige Bot-Pause beim Partner multipliziert sich mit dessen Sprint- und Freigaberhythmus. Wer nur den eigenen GitHub-Account prüft und den Lieferantenstack ausblendet, unterschätzt die reale Expositionsfläche in der Software-Lieferkette.

Risiko-Fenster: kritische Patches und Produktions-Releases

Das Risiko-Fenster ist die Spanne zwischen öffentlicher Kenntnis einer Schwachstelle und dem produktiven Einsatz des Fixes. Die Dependabot-Cooldown-Phase verlängert dieses Fenster nicht für den Security-Update-Pfad mit Advisory. Sie verlängert den Nachzug regulärer Versionssprünge und damit die Zeit, in der Teams „frische“ Features und Fixes nur außerhalb des Version-Update-Kanals sehen. Kritisch bleibt das, wenn Teams Security-Fixes ausschließlich über Versions-PRs erwarten, Advisories ignorieren oder Scanner abschalten.

Für regulierte und sicherheitskritische Umgebungen zählt die eigene Patch-Disziplin. Der BSI-Baustein OPS.1.1.3 (IT-Grundschutz, Edition 2023) fordert ein strukturiertes Patch- und Änderungsmanagement: zeitnahe Bewertung und Installation von Sicherheitsupdates, Testumgebungen, Rollback-Konzepte und Dokumentation. Fixe Stunden-SLAs nennt der Baustein in den öffentlich referenzierten Kernanforderungen nicht; er setzt den Prozessrahmen. Als internationale Orientierung für aktiv ausgenutzte Schwachstellen dient der CISA-Katalog Known Exploited Vulnerabilities (KEV): US-Bundesbehörden müssen Einträge unter den jeweils geltenden Binding Operational Directives binnen vorgegebener Fristen beheben – oft im Bereich von zwei Wochen, je nach Katalogeintrag und Richtlinie. Das ist kein deutsches Recht, aber ein belastbarer Maßstab für prioritisiertes Remediation.

Produktions-Releases verschärfen das Bild. Wer am Release-Freitag nur Dependabot-Versions-PRs als Sicherheitsinput akzeptiert, kann Advisories und Scanner-Findings verpassen. Umgekehrt erzeugt Eile ohne Regressionstests neue Betriebsrisiken. Die Entscheidung liegt zwischen beschleunigtem Hotfix mit engem Scope und bewusster Risikoakzeptanz bis zum nächsten regulären Slot. Beides braucht dokumentierte Kriterien.

Gegenmaßnahmen ohne Vollbremsung im Release-Prozess

Eine Vollbremsung aller Releases ist selten die beste Antwort. Zielführender ist ein abgestuftes Modell: Security-Updates und Advisories über den schnellen Kanal halten, reguläre Versionsupdates im Cooldown belassen oder bewusst verkürzen. Alternative Quellen sind Advisory-Feeds der Package-Registry, eigene Dependency-Scanner, Vendor-Mailings und manuelle Version-Pins mit Changelog-Review. Der Release-Zug fährt weiter; Security-Hotfixes behalten eine Überholspur mit verkürztem Review und gezielten Tests.

Praktisch hilft eine kurze Allowlist der Top-Risiko-Dependencies nach Exposition und Business-Kritikalität. Für diese Komponenten gilt ein beschleunigter Pfad: Advisory-Abo, tägliche Diff-Prüfung und vorbereitete Rollback-Pläne. Für den breiten Long Tail bleiben wöchentliche Sammel-Updates und automatisierte Kompatibilitätstests. So steigt der Aufwand dort, wo Schaden und Eintrittsnähe am höchsten sind, ohne jede Library zum Sonderprojekt zu machen.

Auch die SBOM- und Dependency-Policy gehört auf den Tisch. Eine Software Bill of Materials (SBOM) listet Komponenten und Abhängigkeiten eines Produkts maschinenlesbar. Die NTIA-Mindestelemente und die CISA-Aktualisierung 2025 fordern unter anderem, dass zu neuer Build- oder Release-Version eine passende SBOM entsteht und dass Inventare mit Komponentenänderungen nachziehen. Sie definieren keine universellen Stundenlimits für offene Findings. Die eigene Policy muss festhalten, welche Update-Quellen gelten, wie lange bekannte kritische Findings offen bleiben dürfen und wann ein Release trotz offener Dependency-Tickets freigegeben werden darf. Ohne diese Regeln ersetzt die dreitägige Bot-Pause nur eine Automatik durch informelle Zurufe.

Governance: wer Update-Risiken freigibt

Update-Risiken sind keine reine Entwicklerfrage. Fachlich freigeben sollten die Rollen, die Betriebsrisiko und Compliance verantworten: typischerweise CISO oder Informationssicherheit gemeinsam mit Engineering-Leitung, bei produktkritischen Systemen mit dem Product Owner. Der CFO ist relevant, wenn Ausfall, Haftungsfragen oder aufsichtliche Anforderungen den Business Case für schnellere Patch-Kapazität bestimmen. Die Freigabe muss schriftlich und zeitgestempelt sein, sonst bleibt im Audit nur der Chatverlauf.

Sinnvoll ist ein einfaches Eskalationsraster. Niedrige und mittlere Findings laufen über das Security-Backlog im Sprint. Hohe und kritische Findings mit aktiver Ausnutzbarkeit lösen den Hotfix-Pfad aus und brauchen eine benannte Entscheiderin oder einen Entscheider innerhalb definierter Stunden. Dienstleister-Verträge sollten spiegeln, wer beim Partner entscheidet und welche Nachweispflichten gelten. Sonst endet die Lieferkettenverantwortung an der Repo-Grenze, während das Risiko im Produkt bleibt.

Governance heißt auch, Ausnahme und Regel zu trennen. Eine dreitägige Plattform-Latenz bei Versionsupdates ist kein Freibrief für monatelang offene Dependencies. Sie ist ein Anlass, die Annahme „Bot gleich Kontrolle“ zu revidieren und Ownership klar zuzuweisen.

Scope der Dependabot-Anpassung: was belegt ist

Für die redaktionelle und betriebliche Belastbarkeit zählt der exakte Scope. Belegt sind Stand Mitte Juli 2026:

• Dauer: Standard-Cooldown von drei Tagen für Dependabot Version Updates; eine neue Version gilt erst nach drei Tagen als Kandidat für einen Versions-PR.
• Start und Quelle: GitHub-Changelog vom 14. Juli 2026 sowie der begleitende Security-Blogeintrag; Dependabot-Core-Announcement bestätigt den Default ohne Pflichtkonfiguration.
• Geltungsbereich: Versionsupdates über die unterstützten Package-Ökosysteme; konfigurierbar pro Ecosystem über cooldown (inkl. default-days und SemVer-Staffeln wo unterstützt).
• Ausnahmen: Security-Updates öffnen laut GitHub weiterhin sofort. Teams können den Cooldown verkürzen, verlängern oder auf null setzen.
• Zweck: Zeitfenster für Erkennung und Entfernung manipulierter Packages, bevor der Bot sie vorschlägt; laut GitHub nur eine Schicht neben Lockfiles, CI-Härtung und Review.

Ohne diese Abgrenzung droht aus einer Plattform-Policy eine pauschale Sicherheitsstory. Nicht jedes Unternehmen ist gleich betroffen. Wer andere Bot-Ketten, Mirror-Registries oder Vendor-Patches nutzt, hat ein anderes Fenster. Wer kaum eigene Dependencies pflegt, trägt das Risiko vor allem über SaaS und Integratoren. Die Einordnung bleibt an den belegten Mechanismus gebunden und bewertet Auswirkungen nach Betriebsmodell.

Für Entscheider im DACH-Mittelstand liegt die Konsequenz in der Steuerung des Risiko-Fensters: Update-Automation bleibt nützlich und die Cooldown-Phase adressiert ein reales Supply-Chain-Muster. Sie ersetzt weder SBOM-Disziplin noch benannte Freigaben für kritische Dependency-Fixes. Wer die dreitägige Pause nur als Tool-Störung liest, verpasst den Governance-Punkt. Wer sie als Anlass nimmt, Version- und Security-Kanäle, SLAs und Eskalation sauber zu koppeln, hält den Release-Prozess arbeitsfähig und die Software-Lieferkette nachvollziehbar.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)