Tools

Dependabot zähmen - Updates gruppieren, Rhythmus drosseln, Sicherheit schnell halten

dependabot github devops security supply-chain

Montagmorgens, du öffnest deine Notifications - und da sind sie: fünf, zehn, manchmal ein Dutzend Dependabot Pull Requests, jeder für eine einzelne Abhängigkeit. Individuell hilfreich, kollektiv Lärm. Und Lärm ist, wie wichtige Updates ignoriert werden.

Ein Blick auf Microsofts GCToolkit-Repo zeigte: 92 von 578 Commits waren Dependabot-Bumps. Das ist jeder sechste Commit. Das muss nicht so sein.

Die Lösung: Drei Änderungen

1. Alles in einen Pull Request gruppieren

Ein groups-Block mit Wildcard-Pattern (patterns: ["*"]) bündelt alle Updates pro Ökosystem in einem einzigen PR. Statt 10 Pull Requests bekommst du einen Titel wie “Bump the monthly-batch group with 10 updates”. Ein Branch, ein CI-Lauf, eine Review.

2. Kadenz von daily auf monthly

schedule.interval: "monthly" ändert den Rhythmus von “immer wenn sich etwas ändert” zu “einmal pro Monat, planbar”. Kombiniert mit Gruppierung ist das die echte Lärmreduktion: ein gebündelter PR pro Ökosystem pro Monat.

3. Alle Ökosysteme abdecken

Viele Configs uberwachen nur github-actions, vergessen aber maven, npm, pip etc. Jedes Ökosystem bekommt seinen eigenen Schedule und seine eigene Gruppe.

Sicherheit bleibt sofort

Der Schlüssel: Gruppen und Schedule betreffen nur Version-Updates, nicht Security-Fixes. Dependabot Security Updates werden weiterhin sofort bei Bekanntwerden einer Schwachstelle ausgelöst, unabhängig vom Schedule. Monatliche Routine-Bumps verzögern also keinen kritischen Patch.

Zusätzlich gibt es seit kurzem einen Default-Cooldown: Dependabot wartet drei Tage, bevor ein Version-Update-PR eröffnet wird - als Schutz vor Supply-Chain-Angriffen über frisch veröffentlichte Releases.

Praxis-Tipps

  • Starte breit mit einem Wildcard-Gruppe, splitte später bei Bedarf
  • Nutze directories mit Globs für Monorepos (/apps/*)
  • group-by: dependency-name fasst gleiche Libraries über mehrere Verzeichnisse zusammen
  • Cooldown-Länge ist konfigurierbar (cooldown.default-days: 7)

Mit etwa einem Dutzend Zeilen YAML wird aus einem Daily-PR-Strom ein sauberer monatlicher Batch. Weniger PRs, weniger CI-Läufe, und die Updates, die wirklich zählen, gehen nicht im Rauschen unter.

Quelle: GitHub Blog