Wenn ein Versions-Bump den Build bricht, behebt GitLab ihn

KI schreibt mehr Code und zieht mehr Dependencies nach – das erhöht das Risiko für Anwendungen. Der Großteil dieser Angriffsfläche stammt nicht aus Code, den das eigene Team aktiv ausgewählt hat. Eine Studie zum Maven-Ökosystem aus 2025 fand Schwachstellen in rund 63 % der aktuellsten Releases über transitive Dependencies, gegenüber 31 % über direkte.

Dependency Scanning Auto-Remediation, jetzt in der Beta, schließt diese Lücke bei der Security. Findet Dependency Scanning ein verwundbares Paket, öffnet GitLab eine Merge Request zur Aktualisierung, nutzt KI zur Behebung von Build-brechenden Änderungen und iteriert, bis die Pipeline durchläuft – wobei jede Änderung den bestehenden Gates und dem Audit-Trail unterliegt.

Dadurch schrumpfen Security-Backlogs, ohne Entwicklungsteams von ihrer eigentlichen Arbeit abzulenken, werden Schwachstellen mit hoher Severity innerhalb der Compliance-Fristen behoben, und Breaking Upgrades kommen als freigabebereite Merge Requests an.

Warum der Dependency-Backlog immer weiter wächst

Verwundbare und veraltete Komponenten sind ein altbekanntes OWASP-Top-10-Risiko und eine der Hauptquellen für Remediation-Backlogs. Findings zu beheben ist langsame, manuelle Arbeit, die mit der Feature-Entwicklung konkurriert – Schwachstellen mit hoher Severity bleiben dadurch über die 30-Tage-Fristen von PCI-DSS und FedRAMP hinaus ungelöst. Gleichzeitig beschleunigt KI-gestütztes Exploit-Engineering die Offenlegung und Bewaffnung von Schwachstellen, selbst in etablierten Libraries.

Etwa jedes achte Dependency-Update führt zu einem Breaking Change, und viele als abwärtskompatibel gekennzeichnete Updates brechen trotzdem den Build. Teams verschieben komplexe Änderungen tendenziell – und je länger diese Schwachstellen liegen bleiben, desto gravierender werden sie.

Vom Backlog zum Fix, ohne Entwicklungsteams abzulenken

Dependency Scanning Auto-Remediation macht aus verwundbaren Dependencies geprüfte, merge-bereite Fixes, sodass Findings abgearbeitet werden und die Auflösung von Breaking Changes nicht länger die Entwicklungsteams bindet. Teams profitieren dabei in drei Bereichen: Backlog, Aufwand und Kontrolle.

• Den Dependency-Backlog verkleinern. Verwundbare Dependencies werden aktualisiert, sobald sie gefunden werden – Findings stapeln sich dadurch nicht, und Issues mit hoher Severity bleiben innerhalb der Compliance-Fristen.
• Aufwändige Breaking-Change-Rewrites vermeiden. Bricht ein Bump den Build, committet die GitLab Duo Agent Platform einen Fix – Entwicklungsteams prüfen dann eine funktionierende Änderung, statt sie von Grund auf selbst zu schreiben.
• Jede Änderung unter Kontrolle behalten. Auto-Remediation entwirft die Änderung, aber gemergt wird erst nach Freigabe durch einen Reviewer – und jede MR hinterlässt einen Audit-Trail zu dem, was sich geändert hat und wer es freigegeben hat.

Schwachstellen schließen, auch wenn Code-Änderungen nötig sind

Dependency Scanning Auto-Remediation behebt Schwachstellen und löst Breaking Changes in zwei Stufen:

Automated Dependency Version Bumping läuft automatisch, sobald das Scanning eine verwundbare Dependency erkennt, und öffnet eine Merge Request zur Aktualisierung auf die nächste fehlerbereinigte Version. Existiert kein geeigneter Fix, bleibt das Finding im Vulnerability Report, bis ein sicherer Upgrade-Pfad verfügbar ist. Jede MR wird einem dedizierten Service-Account zugeordnet, wodurch sich jede Änderung einer eindeutigen Identität zuordnen lässt.

Agentic Breaking Change Resolution übernimmt die schwierigen Fälle, in denen ein Versions-Bump Breaking Changes verursacht. Schlägt die Pipeline einer Remediation-MR fehl, weil die neue Version das Projekt bricht, analysiert die GitLab Duo Agent Platform automatisch die Pipeline-Fehler, den Changelog der Dependency und wie der Code die Dependency nutzt. Anschließend committet sie innerhalb derselben MR Fixes, damit das Projekt mit der aktualisierten Version funktioniert. Bekommt sie die Pipeline nicht zum Laufen, stoppt sie und hält in der MR fest, was sie gefunden hat, damit von dort aus weitergearbeitet werden kann. Unterstützte Ökosysteme umfassen Bundler, Maven, Gradle sowie die wichtigsten Python- und JavaScript/TypeScript-Paketmanager; Rust und Go sind für die kommenden Monate geplant.

Auto-Remediation mergt nie von sich aus. Für das Review legt jede MR offen, welche Schwachstelle sie adressiert, auf welche Version sie hebt und welchen Code die GitLab Duo Agent Platform vorgeschlagen hat, damit der Build durchläuft – so muss beim Review niemand die Änderung erst rekonstruieren.

So funktioniert Dependency Scanning Auto-Remediation

Auto-Remediation läuft automatisch, sobald SBOM-basiertes Dependency Scanning eine verwundbare Dependency mit verfügbarem Fix erkennt. Für ein einzelnes Finding lässt es sich auch manuell aus dem Vulnerability Report heraus starten. GitLab öffnet dann eine Remediation-MR, die den gewohnten Review- und Merge-Prozess durchläuft; ist Agentic Breaking Change Resolution aktiviert und bricht der Versions-Bump die Pipeline, versucht die GitLab Duo Agent Platform, die daraus entstehenden Code-Änderungen innerhalb derselben Merge Request zu beheben.

Eingebaute Schutzmechanismen verhindern, dass die Remediation-Automatisierung zur Belastung wird. Cooldown-Zeiträume verhindern, dass stark frequentierte Projekte bei jeder Pipeline eine Remediation auslösen, und GitLab legt eine geschlossene MR nur dann neu an, wenn ein neuerer Fix verfügbar ist.

Remediation lässt sich an die jeweilige Risikotoleranz anpassen. Möglich ist die Ausrichtung auf Schwachstellen jeder Severity von Low bis Critical, das Begrenzen, wie weit Versions-Bumps gehen dürfen (Patch, Minor oder Major), sowie das Speichern der Einstellungen in Konfigurationsprofilen auf Projekt- oder Gruppenebene (während der Beta über die API).

Remediation läuft über die eigene Pipeline der Organisation und übernimmt damit die bestehenden Zugriffskontrollen und Freigabe-Gates. Zusätzlich entsteht ein vollständiges, auditierbares Protokoll dazu, was sich geändert hat, wer es freigegeben hat und warum.

Dependency Scanning Auto-Remediation in Aktion:

Den Dependency-Backlog schon heute abbauen

Dependency Scanning Auto-Remediation befindet sich in der Public Beta. Verfügbar ist es auf GitLab.com und wird schrittweise für GitLab Self-Managed und GitLab Dedicated ausgerollt.

Der Einstieg gelingt über die Dokumentation zu Dependency Scanning Auto-Remediation.

Automated Dependency Version Bumping ist in GitLab Ultimate ohne Zusatzkosten enthalten.

Der Zugang zu Agentic Breaking Change Resolution lässt sich über eine kostenlose Testversion der GitLab Duo Agent Platform erhalten. Bereits im GitLab-Ultimate-Abo? Die Duo Agent Platform aktivieren und die im Abonnement enthaltenen GitLab Credits nutzen.

Feedback vorhanden? Es lässt sich im Feature-Feedback-Epic teilen.