Abhängigkeiten veralten leise. Eine Bibliothek, die du vor einem Jahr eingebunden hast, hat seitdem vielleicht ein halbes Dutzend Patches bekommen, darunter Sicherheitsfixes. Wer das manuell verfolgt, verliert. Dependabot und Renovate nehmen diese Arbeit ab, indem sie veraltete Pakete erkennen und automatisch Pull Requests öffnen. Beide lösen dasselbe Problem, gehen aber unterschiedlich vor.
Warum automatische Updates kein Luxus sind
Die meisten verwundbaren Anwendungen sind nicht durch exotische Angriffe kompromittiert, sondern durch bekannte Lücken in veralteten Abhängigkeiten. Der Fix existiert längst, er wurde nur nicht eingespielt. Ein Bot, der dir jeden neuen Patch als Pull Request vorlegt, verkürzt die Zeit zwischen Veröffentlichung eines Fixes und seinem Einsatz drastisch. Das ist der eigentliche Gewinn: nicht Bequemlichkeit, sondern eine kleinere Angriffsfläche.
Dependabot einrichten
Dependabot ist in GitHub eingebaut. Du brauchst keine externe App, nur eine Konfigurationsdatei unter .github/dependabot.yml. Ein minimales Setup für npm und GitHub Actions sieht so aus:
version: 2updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" open-pull-requests-limit: 5 groups: dev-dependencies: dependency-type: "development" - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly"
Wichtig ist der groups-Block. Ohne Gruppierung bekommst du pro Paket einen eigenen Pull Request, was bei mittelgroßen Projekten schnell zu zwanzig offenen PRs pro Woche führt. Gruppiert nach Dev-Abhängigkeiten oder nach Patch-Level bleibt die Liste überschaubar. Der zweite Eintrag hält deine GitHub-Actions-Workflows aktuell, was oft vergessen wird, obwohl genau dort Supply-Chain-Risiken sitzen.
Renovate als flexiblere Alternative
Renovate kommt von Mend und läuft als GitHub-App oder selbst gehostet. Die Konfiguration ist mächtiger, die Lernkurve dafür etwas steiler. Eine schlanke renovate.json mit Auto-Merge für unkritische Updates:
{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "schedule": ["before 6am on monday"], "packageRules": [ { "matchUpdateTypes": ["patch", "pin", "digest"], "automerge": true }, { "matchDepTypes": ["devDependencies"], "matchUpdateTypes": ["minor"], "automerge": true } ], "vulnerabilityAlerts": { "labels": ["security"] }}
Der entscheidende Unterschied liegt in den packageRules. Renovate erlaubt feingranulare Regeln pro Paket, pro Update-Typ und pro Verzeichnis. Patches und Digest-Updates werden hier automatisch gemerged, sobald die Pipeline grün ist. Minor-Updates bei Dev-Abhängigkeiten ebenfalls. Major-Updates bleiben bewusst manuell, weil dort Breaking Changes wahrscheinlich sind.
Wann welches Tool
Dependabot ist die richtige Wahl, wenn du ohnehin auf GitHub bist und schnell starten willst. Es ist ohne Setup verfügbar und deckt die häufigsten Ökosysteme ab. Renovate lohnt sich, sobald du viele Repositories vereinheitlichen willst, Monorepos pflegst oder differenzierte Auto-Merge-Strategien brauchst. Renovate unterstützt zudem deutlich mehr Paketmanager und lässt sich über eine geteilte Basiskonfiguration zentral steuern. Wer zwischen beiden schwankt: Fang mit Dependabot an, wechsle zu Renovate, wenn die Standardregeln zu eng werden.
Auto-Merge braucht eine grüne Pipeline
Automatisches Mergen ist nur dann verantwortbar, wenn deine CI etwas taugt. Ohne aussagekräftige Tests merged der Bot kaputten Code direkt in den Hauptzweig. Bevor du Auto-Merge aktivierst, sollten Branch Protection Rules erzwingen, dass alle Checks grün sind und mindestens die Testsuite plus ein Lint-Lauf durchläuft. Für sicherheitskritische Pakete lohnt sich ein zusätzlicher Scan im PR, etwa mit Grype oder Trivy. So fängst du eine kompromittierte Version ab, bevor sie automatisch landet.
Der Aufwand ist überschaubar, der Effekt groß: Du bekommst kontinuierlich aktuelle Abhängigkeiten, ohne sie manuell zu jagen, und behältst über die Regeln trotzdem die Kontrolle darüber, was ohne menschlichen Blick durchgeht. Wie sich solche automatisierten Schritte in eine durchgängige sichere Lieferkette einfügen, behandle ich regelmäßig auf digital-business.blog.
Hinterlasse einen Kommentar