Heute nur die Sicherheitswarnungen mit Laufzeit-Scope und hoher oder kritischer Stufe; alles andere kann auf einen festen Termin in der Woche warten. Entwicklungsabhängigkeiten und gruppierte Versionsupdates sind echte Arbeit, ändern aber selten, was bei deinen Nutzern läuft.
Laufzeit oder Entwicklung?
Zuerst die Laufzeit, weil das der Code ist, den deine Anwendung im Betrieb ausführt. GitHubs Dokumentation sagt es in zwei Sätzen: «Runtime dependencies are used by an application in production», dagegen «development dependencies are only used during development, testing, or build processes» (GitHub Docs, Dependabot-Warnungen priorisieren, geprüft am 9. Oktober 2026). Dieselbe Seite schlägt die Reihenfolge vor: zuerst die Stufe, dann die Wahrscheinlichkeit eines Angriffs (EPSS), dann Scope und ob die Abhängigkeit direkt ist.
Über unsere eigenen Repos öffnete Dependabot zwischen dem 25. September und dem 9. Oktober 2026 50 Warnungen (gezählt am 9. Oktober 2026 über die GitHub-API, offen, behoben und verworfen zusammen): 18 zur Laufzeit und 32 zur Entwicklung. Unter den 18 Laufzeit-Warnungen waren 14 hoch, unter den 32 Entwicklungs-Warnungen 12. Der Filter scope:runtime mit severity:high hätte 14 von 50 für denselben Tag übrig gelassen.
Der Scope ist nur so gut wie seine Erkennung. GitHub führte den Filter für RubyGems, npm, Composer, Maven, Poetry, pip, teilweise NuGet und Cargo ein; Yarn und Go-Module zählen alles als Laufzeit (GitHub Changelog, 23. Juni 2022, geprüft am 9. Oktober 2026). In diesen Ökosystemen heisst Laufzeit «nicht eingeordnet», nicht «im Betrieb».
Was ändern Gruppen?
Gruppen ändern, wie viele Pull-Requests kommen, nicht, welche Warnungen es gibt. «A Dependabot group bundles multiple dependency updates into one pull request», schreibt der GitHub-Blog, und Gruppen und Zeitplan «shape your version updates, not your security fixes» (GitHub Blog, Tame Dependabot, 29. Juli 2026, geprüft am 9. Oktober 2026).
Für Einzelentwickler ist das die brauchbare Trennung: Versionsupdates als ein gruppierter Pull-Request je Woche oder Monat, Sicherheitsupdates, sobald sie kommen. In gitpuls stehen die gruppierten Updates deshalb am Ende jedes Dependabot-Eintrags. Am 9. Oktober 2026 um 18:48 Uhr führte unsere gitpuls-Datenbank 0 offene Warnungen über 18 geprüfte Repos, also 0 zur Laufzeit und 0 zur Entwicklung; die 50 Warnungen oben waren bis dahin alle behoben oder verworfen.
Wie alt darf ein Update werden?
So alt wie der Termin, den du ihm gibst, solange es keine Laufzeit-Warnung mit hoher Stufe ist. Von unseren 39 behobenen Warnungen waren die zur Laufzeit im Mittel nach 0,9 Tagen und höchstens nach 2 Tagen geschlossen, die zur Entwicklung im Mittel nach 0,6 Tagen und höchstens nach 5 Tagen (von der Öffnung bis zur Behebung, gezählt am 9. Oktober 2026).
Die Entwicklungs-Warnungen blieben nicht liegen, obwohl es mehr waren. Eine Regel, die für uns trägt: Laufzeit und hoch am selben Tag, alles andere innerhalb der Woche, und eine Warnung, die älter als eine Woche ist, bekommt einen Entscheid, entweder ein Update oder ein Verwerfen mit Begründung.
Wie dieser Text entstanden ist
Dieser Artikel ist mit einem KI-Assistenten aus unseren eigenen Messungen und den oben verlinkten Quellen entstanden; die Quellen wurden am 9. Oktober 2026 geprüft. Die Zahlen stammen von der Methodenseite, geschätzt ist nichts.