Dependency-Update-Hygiene für MSPs: von der Policy zu Renovate

Dieser Leitfaden richtet sich an MSP-Plattformteams, die die Lücke zwischen der Veröffentlichung eines Fixes durch einen Hersteller und seiner tatsächlichen Verteilung in der Flotte schließen wollen: was inventarisiert werden sollte, wie oft Abhängigkeiten überprüft werden sollten und wo ein Tool wie Renovate die Routinearbeit automatisieren kann, ohne die Risikoentscheidung zu automatisieren.

Wissen, was läuft

Die meisten dependency-bezogenen Vorfälle sind keine Zero-Days. Es handelt sich um bekannte Fixes, die Wochen oder Monate vor der Ausnutzung durch einen Angreifer veröffentlicht wurden – die Lücke zwischen Release und Adoption. Für MSP-Plattformen mit kundenseitiger Infrastruktur beginnt das Schließen dieser Lücke mit einem Inventar – idealerweise einer echten Software Bill of Materials statt einer Tabelle mit Hostnamen. Es sollte die verwendete Version, den Expositionsort und die verantwortliche Person erfassen. Ohne das ist ein Patch-Advisory nicht umsetzbar: Ein Team kann nicht feststellen, welche Systeme betroffen sind, ohne jedes einzeln manuell zu prüfen.

Eine Kadenz festlegen – und einhalten

Eine feste Review-Kadenz – wöchentlich, zweiwöchentlich, je nach Änderungstoleranz der Plattform – ist besser als Ad-hoc-Patches, die nur durch eine Schlagzeile ausgelöst werden. Gestufte Rollouts fangen Regressionen in einer Canary-Gruppe ab, bevor sie alle Kunden erreichen, und ein Rollback-Plan, der im selben Change-Ticket wie das Update steht, verhindert, dass ein fehlerhafter Patch zu einem langen Ausfall wird, während jemand improvisiert eine Lösung sucht.

Hygiene ersetzt keine Isolation

Gute Update-Hygiene verringert, wie oft eine Abhängigkeit mit einer bekannten Schwachstelle exponiert ist, ersetzt aber keine Isolationskontrollen. Eine verwundbare Bibliothek, die fail-open reagiert, wirkt sich weiterhin nur auf den erreichbaren Radius aus – und der ist kleiner, wenn eine Plattform einen Tenant pro Kunde durchsetzt, als wenn sich Tenants eine Grenze teilen. Beide Kontrollen ergänzen sich: Hygiene verringert, wie oft etwas kaputtgeht, Isolation begrenzt, was dabei kaputtgeht.

Den Pull Request mit Renovate automatisieren

renovatebot/renovate gehört zu den am weitesten verbreiteten Tools, um Abhängigkeiten aktuell zu halten: Es scannt die Paketdateien eines Repositorys und öffnet Pull Requests, um veraltete Versionen anzuheben, statt Änderungen direkt anzuwenden. Das von Mend.io betreute Projekt ist auf rund 22.000 GitHub-Stars gewachsen und deckt mehr als 90 Paketmanager ab, sodass es einen gemischten MSP-Stack abdecken kann, statt für jedes Ökosystem einen eigenen Bot zu benötigen. Zeitpläne und Paketregeln lassen sich pro Repository festlegen, sodass ein unruhiger Dependency-Baum im Code eines Kunden nicht ein kritisches Update im Code eines anderen überdeckt.

Als Backlog behandeln, nicht als Stempel

Die Aufgabe von Renovate endet beim Pull Request; es merged oder deployt nicht selbst. Ein Mensch – oder ein Policy-Bot, der Tests und ein Vulnerability-Gate durchsetzt – muss die Änderung weiterhin freigeben. Die Kombination mit einem Fail-closed-Scan-Gate, das einen Build blockiert, wenn eine Abhängigkeit eine bekannte Schwachstelle enthält, macht aus den beiden Tools eine Arbeitsteilung: Renovate schlägt den Fix vor, das Gate entscheidet, ob die Pipeline ohne ihn weiterlaufen darf. Die entstehenden Pull Requests sollten als operativer Backlog mit einer verantwortlichen Person und einem Ziel-Merge-Termin behandelt werden, statt anzunehmen, dass ein offener PR gleich einem geschlossenen Risiko ist. Wer eine strukturierte externe Prüfung der eigenen Lücken bei Updates und Schwachstellenmanagement möchte, kann dafür auch eine dedizierte Bewertung heranziehen; die Altovar-Cybersecurity-Services umfassen Penetrationstests, Vulnerability-Assessments, Incident Response sowie NIS2-/DORA-/GDPR-Compliance.

Was zu tun ist

1. Ein Inventar aufbauen – idealerweise ein SBOM – mit Dependency-Versionen und deren Einsatzorten.
2. Eine feste Review-Kadenz festlegen, statt nur bei Schlagzeilen-CVEs zu patchen.
3. Ein Tool wie Renovate aktivieren, das Update-Pull-Requests automatisch öffnet, pro Repository konfiguriert.
4. Es mit einem Fail-closed-Gate kombinieren, das Merges blockiert, wenn eine Abhängigkeit eine bekannte Schwachstelle hat.
5. Rollouts über eine Canary-Stufe staffeln, bevor sie auf die gesamte Flotte ausgerollt werden.
6. Den Rollback-Plan im selben Ticket wie das Update festhalten, bevor es angewendet wird.

Quellen: CISA Known Exploited Vulnerabilities Catalog, renovatebot/renovate auf GitHub.