Veraltete Abhängigkeiten sind der häufigste Weg, über den Schwachstellen in Software gelangen. Nicht der eigene Code, sondern die 300 Pakete darunter. Automatische Update-Tools wie Dependabot und Renovate lösen genau dieses Problem. Trotzdem scheitert die Einführung in vielen Teams. Nicht am Tool, sondern an der fehlenden Strategie dahinter.
Was beide Tools tun
Dependabot und Renovate beobachten die Manifest-Dateien eines Repositories, also package.json, pom.xml, go.mod, requirements.txt und ähnliche. Erscheint eine neue Version einer Abhängigkeit, öffnen sie automatisch einen Pull Request mit dem Update. Die Pipeline testet den PR, ein Mensch oder eine Regel entscheidet über den Merge. Wichtig ist die Unterscheidung zwischen Sicherheitsupdates, die eine bekannte Schwachstelle schließen, und normalen Versionsupdates, die nur Aktualität herstellen. Beide Kategorien brauchen unterschiedliche Behandlung.
Dependabot: schnell aktiviert, bewusst begrenzt
Dependabot ist in GitHub eingebaut. Eine Datei .github/dependabot.yml genügt, und die Update-PRs laufen. Sicherheitswarnungen sind direkt mit den GitHub Security Advisories verknüpft. Das ist der große Vorteil: kein zusätzlicher Dienst, keine Wartung, kein Onboarding.
Die Grenzen zeigen sich bei Skalierung. Gruppierung von Updates ist erst seit der Einführung von groups möglich und bleibt gröber als bei Renovate. Auto-Merge muss über Workflows oder Branch-Regeln nachgebaut werden. Wer viele Repositories oder exotische Paketmanager hat, stößt schnell an Grenzen.
Renovate: mächtig, aber konfigurationsbedürftig
Renovate läuft als GitHub App, selbst gehostet oder in GitLab und Bitbucket. Die Konfiguration über renovate.json kann viel: Updates nach Semver-Ebene gruppieren, Zeitfenster festlegen, Auto-Merge nur für bestimmte Pakete erlauben, ein Dependency Dashboard als Übersichts-Issue pflegen. Für Monorepos und Organisationen mit vielen Repositories ist Renovate meist die bessere Wahl.
Der Preis ist Komplexität. Eine unüberlegte Renovate-Konfiguration produziert genauso viel Rauschen wie gar keine. Die mitgelieferten Presets wie config:recommended sind ein solider Start, ersetzen aber nicht die Entscheidung, was automatisch gemergt werden darf und was nicht.
Der typische Fehler: PRs ohne Strategie
Das Muster wiederholt sich in vielen Teams. Tool aktivieren, erste Woche 40 offene Update-PRs, Team ignoriert sie, nach drei Monaten wird das Tool abgeschaltet. Das Problem war nie das Tool, sondern die fehlenden Regeln.
Was funktioniert: Patch- und Minor-Updates zu wöchentlichen Sammel-PRs gruppieren. Sicherheitsupdates davon ausnehmen, die kommen sofort und einzeln. Major-Updates immer manuell prüfen, weil sie Breaking Changes enthalten können. Auto-Merge nur dort erlauben, wo die Testabdeckung das Risiko trägt. Ein Update-PR, den niemand ansieht und den keine Pipeline ernsthaft testet, ist keine Sicherheitsmaßnahme, sondern Selbstberuhigung.
Der Sicherheitsaspekt hinter dem Komfort
Automatische Updates sind nur so vertrauenswürdig wie die Pipeline, die sie prüft. Wer Auto-Merge aktiviert, verlagert die Entscheidung von einem Menschen auf seine Tests. Das kann richtig sein, muss aber bewusst passieren. Dazu gehören Lockfiles, damit die Pipeline exakt das baut, was der PR beschreibt, und ein Blick auf die Herkunft neuer Versionen. Ein kompromittiertes Paket kommt über denselben Weg ins System wie ein legitimes Update. Automatische Updates ersetzen deshalb keine Software Composition Analysis, sie ergänzen sie.
Empfehlung für den Einstieg
Klein anfangen und messen. Sicherheitsupdates sofort und einzeln, alle übrigen Updates gebündelt in einem festen wöchentlichen Zeitfenster. Nach vier Wochen zwei Zahlen ansehen: wie viele Update-PRs offen sind und wie alt der älteste ist. Wenn beide Zahlen wachsen, stimmt die Gruppierung nicht oder die Verantwortung ist ungeklärt. Dann nachschärfen statt abschalten.
Wie aktuell sind die Abhängigkeiten in Ihren Repositories wirklich? Der GitSecOps QuickCheck prüft Ihre Pipelines und Repositories auf die relevanten Schwachstellen, inklusive Update-Strategie und Dependency-Hygiene. Ergebnis in 3 Werktagen, 1.990 Euro netto. Kontakt: mm@crank.zone
Dein Blog zum Thema digitales Business 