Die GitLab Duo Agent Platform ist auf intelligente Orchestrierung ausgelegt und führt agentische Workflows über den gesamten Software-Lebenszyklus aus. Sie ist aber flexibel genug, um auch wiederkehrende Arbeit jenseits der Entwicklung zu übernehmen. Ich habe sie stattdessen auf die Demo-Erstellung angesetzt, und das lief so gut, dass sich derselbe Versuch mit jeder Aufgabe lohnt, die gerade auf dem eigenen Schreibtisch liegt. Für den Einstieg habe ich dieses praxisnahe Tutorial geschrieben. Und noch etwas: Man muss dafür nicht programmieren können. Auch aus nicht-technischen Rollen kommt zunehmend Interesse daran, agentische Workflows wie diesen mit GitLab zu betreiben. Wer sich darin wiedererkennt, kann direkt mitmachen.

In diesem Artikel:

• Warum Click-Through-Demos so wirksam sind
• Die Entwicklung: von VMs über externe Demo-Tools zu Agenten
• Die Phasen einer Demo-Erstellung
• So funktioniert der Demo-Generator
• Demos liegen jetzt im Code
• Was die GitLab Duo Agent Platform möglich gemacht hat
• Den ersten Agenten bauen

🎯 Die GitLab Duo Agent Platform heute ausprobieren!

Warum Click-Through-Demos so wirksam sind

Wer eine Funktion in Aktion sieht, versteht sie besser als beim Lesen. Live-Demos sind allerdings heikel: Sie brauchen Produktzugang und genug Routine, um sich sicher durch die Oberfläche zu bewegen.

Eine Click-Through-Demo löst das. Man klickt die Schritte selbst durch, geführt von einem kurzen Erzähltext bei jedem Schritt. Anders als bei einem Video bestimmt man das Tempo selbst. Und anders als ein echter Zugang, für den eine reale Umgebung nötig ist, ist sie nur ein Link: frei teilbar, wiederverwendbar und jedes Mal gleich.

Beispiele finden sich im GitLab Demo Hub.

Die Entwicklung: von VMs über externe Demo-Tools zu Agenten

So sahen Demos nicht immer aus. Über meine Berufsjahre hinweg ist daraus diese Entwicklung geworden:

• VMs (2000er): virtuelle Maschinen mit vorinstalliertem Produkt und Demo-Inhalten, später zentral auf ESX-Servern.
• Externe Werkzeuge (SaaS-Ära): Wechsel auf Anbieterplattformen mit eingebauter Analytik, die aber weiterhin von Hand gebaut werden mussten und an die Infrastruktur des Anbieters gebunden blieben.
• Agentisch (jetzt): Agenten erzeugen Demos aus einem Prompt, ausgeliefert aus demselben Projekt, in dem sie entstehen, ohne Abhängigkeit von einem Anbieter.

Jede Schicht machte Demos zugänglicher. Die agentische Schicht macht sie tragfähig.

Die Phasen einer Demo-Erstellung

Zu einer Click-Through-Demo gehören diese Phasen:

1. Die Funktion verstehen: Dokumentation lesen, Issues und Slack durchgehen, sich mit Product Managern und Engineering abstimmen, um wirklich zu erfassen, was gezeigt wird, und vor allem das Problem, das es löst, samt Wirkung und Nutzen für die Kundschaft.
2. Die Geschichte bauen: ein realistisches Szenario entwickeln, das die Wirkung auf die Kundschaft zeigt, also welches Problem es im Alltag löst und warum das zählt.
3. Die Umgebung aufsetzen: ein Projekt anlegen und realistische Demo-Daten erzeugen, die die Geschichte tragen, etwa eingestreute Schwachstellen für ein Security-Dashboard oder Daten für aussagekräftige Diagramme.
4. Die Inhalte aufnehmen: Screenshots machen oder Clips des tatsächlichen Ablaufs aufzeichnen.
5. Den Erzähltext schreiben: Inhalte formulieren, die durch jeden Schritt führen, aufbauend auf der Geschichte und dem Kundenszenario aus Schritt 2.
6. Die Demo bauen: in einem externen Werkzeug alles zu einem klickbaren Durchlauf zusammenfügen, Verweise auf verwandte Materialien ergänzen und für jeden Schritt den Call to Action festlegen.
7. Mit Beteiligten prüfen: einen Entwurf teilen, Feedback sammeln, nachschärfen.
8. Änderungen einarbeiten: Erzähltext aktualisieren, Schritte umsortieren, bei Bedarf neu erzeugen.
9. Veröffentlichen: nach GitLab Docs, in den Demo Hub und an alle weiteren Zielorte ausliefern.
10. Ankündigen: intern über Slack teilen, in Blogbeiträge einbetten, in sozialen Netzwerken posten.

Zusammengenommen können diese Schritte Tage dauern, und sobald sich am Produkt etwas ändert, geht es ab Schritt 3 von vorn los.

Bei fast allen diesen Schritten kann ein Agent helfen: Dokumentation lesen, Issues durchsuchen, Kontext aus Slack ziehen, Demo-Daten im Projekt anlegen und das Wesentliche herausarbeiten. Den Menschen, der entscheidet, was entstehen soll, und die Ergebnisse vor dem Ausliefern prüft, ersetzt er damit nicht. Die Grundlagenarbeit nimmt er ihm aber zu einem bemerkenswerten Teil ab.

In meinem Click-Through Demo Generator habe ich mich auf die Schritte 1, 2, 5, 6 und 9 konzentriert: die mit klaren Eingaben, vorhersehbaren Ergebnissen und bislang vollständig manueller Ausführung. Die übrigen Schritte lassen sich ebenfalls von spezialisierten Agenten übernehmen.

So funktioniert der Demo-Generator

Der Ablauf sieht so aus: Screenshots in einen Ordner im Projekt legen, optional mit einer context.md als Hintergrund zur Funktion, dann den Workflow aus einem Issue-Kommentar heraus starten. Der Agent sortiert und benennt die Screenshots, schreibt den Erzähltext, baut die Demo mit einer eingebauten Markenvorlage und öffnet einen Merge Request. Ist der geprüft und gemergt, geht die Demo automatisch über GitLab Pages online. Soll sich etwas ändern, genügt eine Nachfrage beim Agenten.

Unter der Haube wird ein Custom Flow ausgelöst. Der Agent ruft ein selbst gebautes Tool auf, das die Demo in eine HTML-Vorlage einbaut, jeden Screenshot mit seinem Erzähltext-Kasten überlagert und den Link zum Merge Request zurück in das Issue kommentiert. Eine Skill gibt dem Schreiben die Richtung, damit der Erzähltext GitLabs Marketing-Botschaften folgt und auf den Nutzen für die Kundschaft zielt statt auf unsere eigenen Funktionen.

Hier der tatsächliche Anweisungstext aus der SKILL.md dieser Skill, den der Agent bei jedem Erzähltext liest und befolgt:

"Great narration sells an outcome, not a UI tour. Someone who clicks through should understand what problem the product solves, why this approach is better, and what they could now do, without reading any docs.

Structure every demo as three acts: Open on the customer's pain, show the product solving it step by step, and close by naming the value they walk away with."

Für Demos in weiteren Sprachen genügt eine Lokalisierungs-Skill im Projekt, von da an wird jede Demo automatisch lokalisiert.

Veröffentlichen mit einer Skill

Auch die Veröffentlichung im Demo Hub, unserem produktiven Demo-Portal, läuft ohne Handarbeit ab. Ist eine Demo fertig, wird sie in der Entwicklungsgalerie als production markiert. Das ist das Signal für den Agenten: Er führt in diesem Projekt eine Skill aus, die in das Demo-Hub-Projekt greift und den Rest übernimmt. Sie schreibt eine kurze Beschreibung, versieht sie mit dem heutigen Datum, markiert sie als neu und öffnet einen Merge Request, der die Demo als Karte ergänzt. Diesen MR zu mergen und die Demo live zu stellen, bleibt eine menschliche Entscheidung.

Demos liegen jetzt im Code

Eine Click-Through-Demo besteht im Kern aus ein paar Dateien: HTML, Screenshots und Konfiguration. Damit gehört sie in ein Repository. Sie steckt nicht länger in einem separaten Werkzeug, das nur wenige bedienen können. Sie liegt in einem GitLab-Projekt und lässt sich deshalb:

• in Merge Requests prüfen
• von Kolleginnen und Kollegen verbessern
• über die Zeit versionieren
• von Agenten aktualisieren, nicht nur von Menschen

Damit wird die Demo zur Sache des Teams und nicht mehr zur Aufgabe einer einzelnen Person. Das macht einen großen Unterschied. Deutlich mehr Kolleginnen und Kollegen können Demos erstellen, prüfen, verbessern und veröffentlichen, ohne besonderes Werkzeugwissen. Wer ein Issue öffnen und einen MR freigeben kann, kann diesen Workflow nutzen.

Selbst ausprobieren?

Das Projekt Click-Through Demo Generator forken und die README für das vollständige Setup lesen. Custom Flows werden beim Forken nicht mitkopiert, deshalb muss der Flow "Generate click-through demo" (dafür ist eine Anmeldung bei GitLab nötig) im geforkten Projekt zusätzlich aktiviert werden. Alles Weitere steht in der README.

Was die GitLab Duo Agent Platform möglich gemacht hat

Ohne die GitLab Duo Agent Platform wäre dieses Projekt deutlich schwieriger geworden.

Die GitLab Duo Agent Platform lieferte mir die fehlende Infrastruktur: einen Custom Flow, der aus einem Issue-Kommentar heraus startet, und ein Container-Image, das ich mit genau der Laufzeit und den Abhängigkeiten definiere, die es braucht. Dazu kommen eingebaute Tools für die direkte Arbeit mit GitLab, etwa das Öffnen von Merge Requests und das Kommentieren von Issues. Im Merge Request prüfe ich die Demo, bevor ich sie merge und der Agent sie im Demo Hub veröffentlicht.

Im Vokabular der Plattform heißt das agentische Automatisierung: Der Custom Flow orchestriert das Verhalten des Agenten, und GitLabs eingebaute Tools lassen ihn mit Issues, Projektdateien, Merge Requests und GitLab Pages arbeiten, ohne separate Integrationen.

Mit Custom Flows lässt sich ein eigener mehrstufiger Workflow festlegen und der Agent um eigene Tools erweitern. Eines davon habe ich selbst gebaut: Es baut Screenshots und Erzähltext in die HTML-Vorlage der Demo ein und läuft als Teil des Flows auf GitLabs Compute.

Alles bleibt in GitLab: die Anfrage, die Prüfung, das Ergebnis, die Auslieferung. Das macht den Ablauf klarer und leichter zu übergeben.

Den ersten Agenten bauen

Einmal weg von meinem eigenen Ablauf und hin zur Frage, was passiert, wenn wiederkehrende Arbeit an einen Agenten mit Zugriff auf die eigenen GitLab-Daten übergeht. Für eine Teamleitung heißt das: weniger Aufwand für die Erstellung von Material, mehr für Prüfen und Entscheiden. Dieselbe Verschiebung zeigt sich überall dort, wo eine wiederholbare, klar umrissene Aufgabe auf GitLab-Kontext aufsetzt.

Klein und einfach anfangen. Der Demo-Generator ist nur ein Beispiel für dieses Muster, für den Anfang braucht es aber weder eigenen Code noch einen Custom Flow. Also mit einem einzelnen Agenten beginnen, ihm eine klare Aufgabe geben und schauen, was er kann, bevor es komplizierter wird.

In diesem kurzen Tutorial entsteht der erste eigene Agent, einer, der bei der Planung der eigenen Arbeit hilft. Kein Zugang zur GitLab Duo Agent Platform? Zum Mitmachen genügt eine kostenlose Testversion. Zwei Aufgaben, mit überschaubarem Aufwand:

Aufgabe 1: einen eigenen Agenten anlegen. In der GitLab-Oberfläche einen eigenen Agenten anlegen und ihn "Daily Planner" nennen. Ihm mitteilen, was Priorität bedeutet, etwa Issues, die Kolleginnen und Kollegen blockieren, alles mit Fälligkeit in dieser Woche, oder "alles mit dem Label customer gilt als höchste Priorität, unabhängig vom Fälligkeitsdatum". Er soll die zugewiesenen Issues und Merge Requests ansehen, diese Regeln anwenden und benennen, was zuerst anzugehen ist, was andere blockiert und was warten kann.

Aufgabe 2: aktivieren und prüfen. Den Agenten im Projekt aktivieren, dann GitLab Duo Agentic Chat öffnen, ihn auswählen und um eine Tagesplanung bitten. Er hat eingebauten Zugriff auf GitLab und zieht die tatsächlich zugewiesenen Issues und MRs selbst. Seinen Plan mit dem vergleichen, was man selbst zusammengestellt hätte, und die Anweisungen des Agenten nachschärfen, bis der Plan wirklich brauchbar ist.

Damit steht der erste eigene Agent, und er macht den Tag schon ein wenig leichter. Ab hier wird es interessant: Was würde man ihm noch übergeben? Welche Entscheidung ist man leid, selbst zu treffen? So wächst aus dem Agenten für einen Zweck die Assistenz, die den ganzen Ablauf trägt.

Die Lücke im bisherigen Fingerprinting

2022 haben wir das erweiterte Vulnerability-Tracking eingeführt, um genau dieses Problem der Code-Volatilität anzugehen. Grundlage ist unsere Scope+Offset-Methode zum Fingerprinting: Statt ein Finding über Datei und Zeilennummer zu identifizieren, identifizieren wir es über den engsten umschließenden Scope (Modul, Klasse, Funktion) und den Zeilen-Offset innerhalb dieses Scopes. Damit wurde das Tracking robust dagegen, dass Code innerhalb einer Datei verschoben wird, und die vergebliche Nachprüfung ging gegenüber zeilenbasiertem Tracking um etwa 30 % zurück.

Eine Klasse von Änderungen blieb allerdings weiterhin problematisch: nicht-funktionale Änderungen. Der Offset zählte jede Zeile zwischen Scope-Grenze und Finding, also auch Kommentare und Leerzeilen. Kommt über einer verwundbaren Anweisung ein Kommentar hinzu, verschiebt sich der Offset. Das Tracking sieht eine neue Schwachstelle, im Ergebnis steht ein Duplikat.

Der normalisierte Offset

Unsere verbesserte Methode löst das, indem sie nicht-funktionalen Code, also Kommentare und Leerzeilen, bei der Berechnung des Fingerprints einfach überspringt. Da diese Zeilen das Verhalten des Programms nicht verändern, sollen sie auch die Identität einer Schwachstelle nicht verändern. Mit dieser Normalisierung ändert ein zusätzlicher Kommentar oder eine Neuformatierung den Fingerprint nicht mehr, während die Präzision des Trackings unverändert bleibt. Ausführlich beschrieben ist der Ansatz in unserem begleitenden Forschungsbeitrag.

Bewertet haben wir die normalisierte Methode auf einem gezielt zugeschnittenen Benchmark: 439 Quelldateien in C/C++, C#, Go, Java, JavaScript, Python und Ruby. Daraus haben wir 2.247 Commits erzeugt, von denen jeder genau einen Kommentar oder eine Leerzeile direkt vor einer bekannten Schwachstelle einfügt, und den Code beim Abspielen der Historie gescannt. Der Benchmark belastet bewusst den schlechtesten Fall: Jeder Commit ist eine nicht-funktionale Änderung unmittelbar neben einem Finding.

Auf diesem Benchmark sammelte die ursprüngliche Scope+Offset-Methode 1.361 doppelte Fingerprints an und stieg damit von 1.768 auf 3.129 eindeutige Fingerprints, ein Wachstum von 77 % gegenüber der Ausgangslage. Die normalisierte Methode blieb bei 1.768, erzeugte also kein einziges Duplikat, und senkte die Zahl der eindeutigen Fingerprints insgesamt um 43 %.

Der Benchmark ist bewusst zugunsten der normalisierten Methode gebaut, denn er provoziert genau die Schwäche, die sie beheben soll. Die 43 % markieren damit die Obergrenze des erreichbaren Effekts und nicht den Wert, der sich im Alltag einstellt.

Verfügbarkeit und Forschungshintergrund

Normalized Scope+Offset steckt in GitLab im Tracking-Algorithmus scope_offset_compressed und unterstützt C#, C/C++, Go, Java, JavaScript, Python, Ruby und PHP. Der Algorithmus nutzt den Parse-Tree weiter, den der Scanner ohnehin aufbaut, sodass die Scan-Dauer unberührt bleibt. Das Format des Security-Reports ist unverändert, wodurch sich die Methode mit beliebigen Kombinationen von SAST-Werkzeugen in heterogenen Setups verträgt.

Der Preprint unserer Studie "Vulnerability Tracking using Normalized Scope+Offset" von Julian Thome, Hua Yan, Lucas Charles, Craig Smith und Jason Leasure wird auf der 41. IEEE/ACM International Conference on Automated Software Engineering, dem ASE 2026 Industry Showcase, vorgestellt.

Hua Yan, Lucas Charles, Craig Smith und Jason Leasure haben zu diesem Beitrag und zur Studie beigetragen.

Der kritischste Teil der externen Phase dieses Vorfalls war die erste Stunde, in der der Agent seiner Sandbox entkam, indem er eine Schwachstelle in einem Package-Proxy auf der Allowlist seiner Sandbox nutzte, um ins Internet zu gelangen.

Während immer mehr Entwicklerinnen und Entwickler von Frontier-Modellen ähnliche Vorfälle offenlegen, muss die Sicherheitsbranche genau prüfen, wie Agenten die Erreichbarkeit innerhalb von Testumgebungen verändern. Und es braucht keine Evaluierungs-Harnesses, damit dieses Problem das eigene wird. Jeder Workload, der Code hinter einer Egress-Liste ausführt, hat dieselbe Struktur: CI-Runner, gehostete Sandboxes und über das Netzwerk erreichbare Tool-Server. Die meisten dieser Allowlists wurden gebaut, um zu verhindern, dass Daten hinausgelangen. Das ist jedoch nicht mehr das Einzige, was sie verhindern müssen.

Warum Allowlists die Reichweite erweitern

Beim Aufbau einer Allowlist überlegt man üblicherweise, was ein Workload kontaktieren muss, und gewichtet jeden Eintrag danach, welche Daten darüber abfließen könnten.

Der Agent von OpenAI legte einen blinden Fleck in genau diesem Vorgehen offen. Der Package-Proxy, auf den der Agent zugriff, ist ein Dienst: Er authentifiziert Aufrufende, führt Software mit Schwachstellen aus und spricht mit dem öffentlichen Internet. Die Sandbox erreichte das Internet nicht, wohl aber der Package-Proxy, zu dem der Agent Zugang erhielt.

Eine Allowlist übergibt dem eigenen KI-Workload die Reichweite jedes Ziels, das er übernehmen kann.

Wie das Modell von OpenAI ausbrach

Um auszubrechen, fand der Agent von OpenAI im Package-Proxy auf seiner Allowlist zwei Zero-Day-Schwachstellen mit sehr großer Wirkung.

Die erste war eine Server-Side-Request-Forgery-Schwachstelle, mit der der Agent den Proxy bitten konnte, beliebige URLs in seinem Auftrag abzurufen. In OpenAIs Präsentation auf der Black Hat liest sich die Überlegung des Modells in diesem Moment als "ausgezeichnet, wir haben beliebige SSRF". Die Sandbox lieh sich die Internetverbindung des Proxys.

Die zweite war eine Rechteausweitung. CVE-2026-65616 (CVSS 8.8) führt dazu, dass der Refresh-Token-Endpunkt eines Package-Proxys neue Token ausstellt, ohne die Token-Signaturen zu prüfen. Diese Token führen ihren Geltungsbereich als Claim mit, statt dass der Server ihn nachschlägt. Sobald die Signatur ungeprüft bleibt, ist der Claim also das, was die aufrufende Seite behauptet.

In diesem Fall war die aufrufende Seite der Agent. Er erweiterte den Zugriff seines lesenden Tokens innerhalb der Sandbox, indem er dessen Claim auf administrativ änderte. Anschließend reichte er das Token beim Package-Proxy zur Erneuerung ein und erhielt ein Token mit Administratorrechten zurück. Damit konnte der Agent mit Administratorberechtigung handeln statt mit seiner ursprünglichen Leseberechtigung.

Die Agenten arbeiteten als Gruppe am Ausbruch. Gemeinsam erkundeten sie den einen Dienst, den sie erreichen konnten, bis sie einen Weg fanden, ihn in ihrem Auftrag abrufen zu lassen, und teilten die Methode anschließend, damit auch andere Agenten sie nutzen konnten. Ein Agent hielt fest, dass externes Ausnutzen außerhalb des Rahmens seiner Anweisungen lag, machte aber dennoch weiter.

Hugging Face und OpenAI verorten die Kompromittierung des Proxys zudem in etwa der ersten halben Stunde des Sandbox-Tests, und das trotz der schwer zu findenden Schwachstellen. Es handelte sich um Zero-Days, der Agent konnte sich also weder auf eine CVE noch auf ein Advisory stützen. Der Package-Proxy ist zudem Closed Source, und sein Code war nie Teil der Trainingsdaten des Agenten.

Warum das Modell ausbrach

Inzwischen wissen wir, warum der Agent sich den Proxy vornahm. Er steckte bei seiner Evaluierungsaufgabe fest, und die Präsentation von OpenAI zeigt, wie das Modell "Antwort vielleicht online" überlegt, bevor es nach einem Ausweg sucht. Frontier-Modelle werden dafür belohnt, Aufgaben zügig zu lösen, weshalb ein feststeckendes Modell nach Abkürzungen sucht. OpenAI schließt diese eine Abkürzung normalerweise, indem der Internetzugang deaktiviert wird.

Zum Verhalten des Agenten sind weiterhin Fragen offen, darunter alles, was er während seines viertägigen Eindringens tat, und was er unternahm, nachdem er Zugang zum Internet erlangt hatte. Bekannt ist: Dieser Agent hat ganz praktisch gezeigt, dass wir beim Bau von Testumgebungen für sicherheitsfähige, autonome KI einige neue Überlegungen anstellen müssen.

Wie sich das Risiko in KI-Testumgebungen reduzieren lässt

Wer Sandboxes für KI-Agenten baut, kann das Risiko auf vier Arten reduzieren und so die Erreichbarkeit begrenzen:

1. Die Routen sperren, die ein Build-Client nie nutzt. Ein Build-Client lädt nur Dateien herunter. Er hat keinen Grund, die Admin-API des Proxys, dessen Konfigurationsrouten oder dessen Token-Refresh-Route aufzurufen, die ein ablaufendes Token gegen ein neues tauscht und in diesem Vorfall missbraucht wurde.
2. Einschränken, was der Proxy selbst erreichen kann. Der Agent kam heraus, weil der Proxy das gesamte Internet erreichte, und damit auch jede Instanz, die den Proxy kontrolliert. Die ausgehenden Verbindungen des Proxys sollten auf die Registries begrenzt sein, die er tatsächlich bedient.
3. Den Proxy überwachen. Ein Proxy, der eine Build-Flotte bedient, arbeitet eintönig: kurze Verbindungen, kleine Downloads, Anfragen, die meist erfolgreich sind. Alles, was diesem Muster nicht folgt, ist eine Alarmierung wert, etwa dauerhaft offene Verbindungen, Daten, die in großen Mengen nach außen wandern, eine Serie von Anfragen nach nicht vorhandenen Paketen und jeder Aufruf einer Admin-Route.
4. Nicht vertrauenswürdige Workloads wie internetseitige behandeln. Erreicht ein nicht vertrauenswürdiger Workload einen internen Dienst, sollte dieser Dienst als internetseitig gelten. Was den Workload kompromittiert, erreicht ihn ebenfalls. Dieselbe Frage für CI-Runner haben wir uns bereits früher in diesem Jahr gestellt, dort läuft der nicht vertrauenswürdige Code in einer Pipeline statt in einer Agenten-Sandbox.

Cyberfähige Modelle verlangen neue Überlegungen zur Sandbox

Eine Sandbox ist eine Liste dessen, womit der Workload darin sprechen darf, und jeder Eintrag auf dieser Liste bringt seine eigene Reichweite mit. Bei einem Build-Job spielt das keine Rolle, bei Agenten schon, weil sie diese Liste auf eine Weise verbreitern, die im Entwurf von Allowlists nie vorgesehen war.

Über Evaluierungs-Harnesses hinaus ziehen agentische Workloads auch in CI, in die Produktionsautomatisierung und in Werkzeuge ein, die mit internen Diensten interagieren. Jeder dieser Bereiche hat eine Liste mit ähnlichen Eigenschaften und ähnlicher Struktur. Je besser Modelle darin werden, Schwachstellen zu finden und zu verketten, desto weiter reicht das, worauf Agenten über diese Listen einwirken können.

OpenAI stellt fest, dass diese Agenten "begrenzt bleiben durch die Rechte, die sie erlangen können, und die Systeme, mit denen sie kommunizieren können", bestehende Kontrollen also weiterhin wirken.

Ändern muss sich, wie sorgfältig wir diese Listen ziehen, um die Erreichbarkeit möglichst klein zu halten.

Weitere Beiträge des Threat-Research-Teams stehen auf unserer Security-Labs-Seite.

Also haben wir ein eigenes gebaut.

Hier steht, was wir dabei gelernt haben und warum ein eigenes Security-Control-Framework auch für das eigene Compliance-Programm der richtige Schritt sein kann.

Der Weg durch die Frameworks

Als ich im November 2022 zum Security-Compliance-Team von GitLab kam, verwalteten wir unsere Controls über das Secure Controls Framework, sowohl für externe Zertifizierungen als auch für interne Compliance-Anforderungen. Mit wachsenden Anforderungen zeigte sich jedoch, dass wir etwas Umfassenderes brauchten.

Da die FedRAMP-Autorisierung auf unserer Roadmap stand, entschieden wir uns als Nächstes für NIST SP 800-53. NIST SP 800-53 umfasst mehr als 1.000 Controls, doch diese Vollständigkeit passt nicht ideal zur Umgebung von GitLab.

Wir mussten nicht jedes NIST-Control umsetzen, sondern nur die, die für unsere konkreten Anforderungen gelten. Unser Fokus lag auf der Qualität der Controls, nicht auf ihrer Zahl. Unnötige Controls verbessern die Sicherheit nicht. Im Gegenteil: Zu viele können eine Umgebung unsicherer machen, weil Menschen Wege finden, übermäßig restriktive oder irrelevante Controls zu umgehen.

Manchen Controls fehlte außerdem die nötige Granularität. Das NIST-Control AC-2 "Account Management" etwa deckt Kontoerstellung und Provisionierung ab, Kontoänderung und Deaktivierung, Kontoentfernung und Beendigung, die Verwaltung geteilter Konten und Gruppenkonten sowie Kontoüberwachung und -prüfungen.

In der Praxis sind das mindestens sechs eigenständige Controls mit unterschiedlichen Verantwortlichen, Prüfverfahren und Risiken. Bei Attestierungen wie SOC 2 wird jede dieser Tätigkeiten als eigenes Control geprüft, weil sie unterschiedliche Nachweisanforderungen und operative Kontexte haben. Das allumfassende AC-2 von NIST bildete weder ab, wie wir Controls tatsächlich betreiben, noch wie Auditoren uns tatsächlich bewerten. Wir brauchten Controls, die granular genug sind, um unsere operative Umgebung abzubilden.

So kam es, dass wir NIST-Controls ständig anpassten, ergänzten und umbauten. Irgendwann wurde uns klar: Wir nutzten NIST SP 800-53 gar nicht mehr, wir bauten unser eigenes Framework darauf auf. Wir entschieden, dass ein eigenes, auf die Umgebung von GitLab zugeschnittenes Control-Framework unserem Multi-Produkt-Angebot und den jeweiligen Compliance-Anforderungen jedes Produkts am besten gerecht wird.

Das GitLab Control Framework aufbauen

In fünf methodischen Schritten haben wir unser eigenes Common-Controls-Framework aufgebaut: das GitLab Control Framework (GCF).

1. Analysieren, was wir brauchen

Wir haben unsere bestehenden Controls durchgesehen und jede Anforderung erfasst, die sich aus bereits gehaltenen Zertifizierungen, aus Zertifizierungen auf unserer Roadmap und aus unserem internen Compliance-Programm ergibt:

Externe Zertifizierungen:

• SOC 2 Type II
• ISO 27001, ISO 27017, ISO 27018, ISO 42001
• PCI DSS
• TISAX
• Cyber Essentials
• FedRAMP

Interne Compliance-Anforderungen:

• Controls für unternehmenskritische Systeme, die nicht im Geltungsbereich externer Zertifizierungen liegen
• Controls für Systeme mit Zugriff auf sensible Daten

Damit stand die Ausgangsbasis: welche Controls existieren müssen, um unsere Compliance-Pflichten zu erfüllen.

2. Von etablierten Frameworks lernen

Anschließend haben wir unsere Anforderungen mit anerkannten Frameworks abgeglichen:

• NIST SP 800-53
• NIST Cybersecurity Framework (CSF)
• Secure Controls Framework (SCF)
• Common Controls Framework (CCF) von Adobe und Cisco

Da wir in der Vergangenheit bereits Frameworks eingeführt hatten, wollten wir aus deren Struktur lernen und sicherstellen, dass uns keine wichtigen Sicherheitsdomänen, Controls oder bewährten Vorgehensweisen entgehen.

3. Eigene Control-Domänen schaffen

Aus dieser Analyse heraus haben wir 18 eigene Control-Domänen entwickelt, zugeschnitten auf die Umgebung von GitLab:

Jede Domäne fasst verwandte Controls zu logischen Familien zusammen, die sich daran orientieren, wie das Security-Programm von GitLab tatsächlich organisiert ist und betrieben wird. Diese Struktur gibt uns ein methodisches Vorgehen an die Hand, um Controls zu ergänzen, zu aktualisieren oder zu entfernen, wenn sich unsere Anforderungen ändern.

4. Kontext und Daten ergänzen

Mit den definierten Domänen standen zwei zentrale Fragen an: wie sich Controls über mehrere Produkte hinweg abbilden lassen, ohne das Framework zu duplizieren, und wie sich aussagekräftiger Umsetzungskontext erfassen lässt, um im großen Maßstab tatsächlich betreiben und auditieren zu können.

Über mehrere Produkte hinweg skalieren

GitLab bietet mehrere Produktvarianten an: GitLab.com (mandantenfähiges SaaS auf GCP), GitLab Dedicated (Single-Tenant-SaaS auf AWS) und GitLab Dedicated for Government (GitLabs Single-Tenant-FedRAMP-Angebot auf AWS). Jede Variante hat eigene Infrastruktur, eigene Compliance-Geltungsbereiche und eigene Audit-Anforderungen. Wir mussten produktspezifische Audits unterstützen, ohne dafür jeweils komplett eigene Frameworks anzulegen.

Wir haben eine Control-Hierarchie entworfen, in der Level-1-Controls das Framework bilden und festlegen, was auf Organisationsebene umgesetzt sein muss. Level-2-Controls sind die Umsetzung und halten produktspezifisch fest, wie die jeweilige Anforderung tatsächlich erfüllt wird.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
  accTitle: Control-Hierarchie
  accDescr: Level-1-Anforderungen laufen auf Level-2-Umsetzungen herunter.

  L1["Level 1: Framework<br/>Was umgesetzt sein muss"];
  L2A["Level 2: GitLab.com<br/>Wie es umgesetzt ist"];
  L2B["Level 2: Dedicated<br/>Wie es umgesetzt ist"];
  L2C["Level 2: Dedicated for Gov<br/>Wie es umgesetzt ist"];
  L2D["Level 2: Entity<br/>(von allen geerbt)"];

  L1-->L2A;
  L1-->L2B;
  L1-->L2C;
  L1-->L2D;

Diese Trennung erlaubt es uns, ein einziges Framework mit produktspezifischen Umsetzungen zu pflegen, statt für jede Variante ein eigenes Framework zu verwalten. Entity-Controls gelten organisationsweit und werden von GitLab.com, GitLab Dedicated und GitLab Dedicated for Government geerbt.

Controls mit Kontext anreichern

Klassische Control-Frameworks führen nur wenige Informationen mit: eine Control-ID, eine Beschreibung und eine verantwortliche Person. Das GCF geht einen anderen Weg, und seine eigentliche Stärke sind die umfangreichen Metadaten, die wir zu jedem Control führen. Über die Control-Beschreibung oder das Implementation Statement hinaus erfassen wir:

• Control-Verantwortung: Wer trägt die Verantwortung für das Control und sein Risiko?
• Umgebung: Gilt es organisationsweit (Entity, von allen Produktvarianten geerbt), für GitLab.com oder für Dedicated?
• Assets: Welche konkreten Systeme deckt dieses Control ab?
• Häufigkeit: Wie oft wird das Control durchgeführt oder geprüft?
• Art: Manuell, teilautomatisiert oder vollautomatisiert?
• Klassifizierung: Dient es externen Zertifizierungen oder dem internen Risikomanagement?
• Prüfdetails: Wie bewerten wir es? Welche Nachweise sammeln wir?

Dieser Kontext macht aus dem GCF mehr als eine einfache Control-Liste: ein operationalisiertes Control-Inventar.

Mit dieser Struktur lassen sich Fragen wie diese beantworten:

• Welche Controls gelten für unser SOC-2-Audit für GitLab.com und welche für GitLab Dedicated? → Nach Umgebung filtern: GitLab.com
• Welche Controls verantwortet das Infrastructure-Team? → Nach Verantwortung filtern
• Welche Controls lassen sich automatisieren? → Nach Art filtern: manuell

5. Iterieren, reifen lassen und skalieren

Das GCF ist nicht statisch, sondern darauf angelegt, sich mit unserem Geschäft und der Compliance-Landschaft weiterzuentwickeln.

Neue Zertifizierungen angehen

Weil der Kontext im GCF operationalisiert ist, lassen sich Geltungsbereich und Lücken bei neuen Zertifizierungen (ISMAP, IRAP, C5 und weitere) rasch bestimmen:

• Geltungsbereich bestimmen: Welches Produkt hat den geschäftlichen Bedarf (GitLab.com, GitLab Dedicated oder beide)?
• Anforderungen zuordnen: Decken bestehende Controls die neuen Zertifizierungsanforderungen bereits ab?
• Lücken erkennen: Welche neuen Controls müssen entstehen?
• Zuordnungen aktualisieren: Bestehende Controls mit den neuen Zertifizierungsanforderungen verknüpfen.

Auf neue Regulierung reagieren

Wenn neue Regulierung entsteht oder sich bestehende Anforderungen ändern:

• Bestehende Controls prüfen: Deckt ein vorhandenes Control die neue Anforderung bereits ab?
• Aktualisieren oder neu anlegen: Entweder den Wortlaut eines bestehenden Controls anpassen oder ein neues Control anlegen.
• Die strengste Fassung anwenden: Wenn mehrere Zertifizierungen ähnliche Anforderungen stellen, setzen wir die strengste um. Einmal absichern, vielfach erfüllen.
• Über Zertifizierungen hinweg zuordnen: Das Control mit allen einschlägigen Zertifizierungsanforderungen verknüpfen.

Den Control-Lebenszyklus steuern

Das Framework passt sich verschiedenen Veränderungen an:

• Geänderte Anforderungen: Aktualisieren Zertifizierungen ihre Anforderungen, prüfen wir die betroffenen Controls und passen Beschreibungen oder Zuordnungen an.
• Abgekündigte Controls: Entfällt eine Anforderung oder wird ein Control nicht mehr gebraucht, markieren wir es als deprecated und nehmen es aus dem Monitoring-Plan.
• Neu erkannte Risiken: Risikobewertungen können Lücken aufzeigen, die neue interne Controls erfordern.

Die Stärke gemeinsamer Controls: ein Control, mehrere Anforderungen

Einmal absichern und vielfach erfüllen ist nicht bloß ein Prinzip. Es bringt handfeste Vorteile dabei, wie wir Audits vorbereiten, Control-Verantwortliche unterstützen und neue Zertifizierungen angehen. So sieht das in der Praxis aus, qualitativ wie in Zahlen.

Qualitative Ergebnisse

Seit der Einführung des GCF haben sich unsere Compliance-Abläufe deutlich verbessert:

Integrierter Audit-Ansatz

Mit dem GCF pflegen wir ein Framework, dessen Controls mehreren Zertifizierungsanforderungen zugeordnet sind, statt für jedes Audit eigene Control-Sets zu verwalten. Ein einziges Control kann Anforderungen aus SOC 2, ISO 27001 und PCI DSS gleichzeitig erfüllen.

Schnellere Audit-Vorbereitung

Über das GCF pflegen wir eine konsolidierte Anfrageliste statt getrennter Listen je Audit. Weil wir Controls mit konkretem Kontext definiert haben, steht in unseren Anfragelisten "Okta-Nutzerliste" statt eines generischen "Produktions-Nutzerlisten". Das nimmt Mehrdeutigkeit und Auslegungsspielraum heraus. Wir sammeln keine "N/A"-Nachweise und überlassen es nicht den Auditoren, zu deuten, was "Produktion" in unserer Umgebung bedeutet. Alles ist bereits auf unsere tatsächlichen Systeme zugeschnitten.

Weniger Aufwand für Beteiligte

Diese Integration entlastet unmittelbar alle Beteiligten. Control-Verantwortliche liefern Nachweise einmal, statt auf getrennte Anfragen von SOC-2-, ISO- und PCI-Auditoren zu antworten. Wenn wir Nachweise für Zugriffskontrollen sammeln, erfüllen diese die Anforderungen von SOC 2, ISO 27001 und PCI DSS gleichzeitig. Ein Control, eine Prüfung, ein Nachweis, und mehrere Zertifizierungen und Anforderungen sind erfüllt.

Effizientere Gap-Analysen

Bei neuen Zertifizierungen oder neuen Funktionen ermöglicht der operationalisierte Kontext eine gezieltere Gap-Analyse. Wir können bestimmen, welche Controls bereits existieren, was fehlt und welche Umsetzung nötig ist.

Quantifizierbare Ergebnisse

Control-Effizienz:

• SOC-Controls um 58 % reduziert (200 Controls → 84) für GitLab.com und um 55 % (181 → 82) für GitLab Dedicated
• Ein Framework trägt inzwischen 8+ Zertifizierungen

Audit-Effizienz:

• 4 Audit-Anfragelisten zu einer konsolidiert, Anfragen um 44 % reduziert (415 → 231)
• 95 % Evidence-Acceptance-Rate vor dem Fieldwork bei den jüngsten PCI-Audits

Umfang des Frameworks:

• 220+ aktive Controls über 18 eigene Domänen
• Zugeordnet zu 1.300+ Zertifizierungsanforderungen
• Trägt mehrere Produktvarianten

Wie es weitergeht

Das GCF entwickelt sich weiter, während wir Security- und KI-Controls ergänzen, neue Zertifizierungen angehen und unser Vorgehen schärfen.

Für Fachleute in der Security-Compliance: Keine Scheu davor, ein eigenes Framework zu bauen, wenn die Industriestandards nicht passen. Der anfängliche Aufwand zahlt sich in Skalierbarkeit, Effizienz und Controls aus, die für die eigene Umgebung tatsächlich Sinn ergeben. Manchmal ist das beste Framework das selbst entworfene.

Wer tiefer einsteigen möchte, findet in unserer Dokumentation zum GitLab Control Framework die Methodik, die Control-Domänen und die Feldstruktur im Detail.

Dieser Beitrag zeigt, welche Fehler beim Aufbau eines DevOps Stacks besonders häufig auftreten und wie sich diese gezielt vermeiden lassen: mit klaren Best Practices für jede Phase des Software Delivery Lifecycle.

Was ist ein DevOps Stack?

Ein DevOps Stack ist die Gesamtheit aller Tools, Plattformen und Technologien, die ein Team für den gesamten Lebenszyklus der Softwareentwicklung einsetzt: von der Planung und Versionierung über Build, Test und Deployment bis hin zu Monitoring und Feedback. Anders als eine reine Tool-Liste beschreibt der DevOps Stack auch, wie diese Komponenten zusammenwirken: welche Daten zwischen ihnen fließen, welche Automatisierungen sie verbinden und wie sie in die bestehenden Prozesse und DevOps-Praktiken eines Unternehmens eingebettet sind.

Ein gut aufgebauter DevOps Stack ermöglicht schnelle, sichere und wiederholbare Releases. Ein schlecht aufgebauter dagegen erzeugt Reibung an jeder Schnittstelle.

Warum DevOps Stacks in der Praxis häufig zu komplex werden

Die Komplexität eines DevOps Stacks entsteht selten durch eine bewusste Entscheidung. In der Regel wächst sie schleichend: Jedes Team wählt das Tool, das seine unmittelbaren Anforderungen am besten erfüllt, ohne den Gesamtkontext zu berücksichtigen. Über Monate und Jahre entsteht so eine Landschaft aus Einzellösungen, die zwar jeweils für sich funktionieren, aber nicht miteinander.

Die Folgen sind vielfältig und teuer. Jede Schnittstelle zwischen zwei Tools erfordert eine eigene Integration, die gebaut, gewartet und bei Updates angepasst werden muss. Entwickler(innen) wechseln ständig zwischen verschiedenen Oberflächen und verlieren dabei den Kontext. Sicherheitsrelevante Informationen sind über mehrere Systeme verteilt, sodass kein einheitliches Bild der Risikolage entsteht. Und je mehr Tools im Einsatz sind, desto schwieriger wird es, konsistente Governance-Regeln durchzusetzen.

Ein typisches Szenario: Das Planungstool kennt den Build-Status nicht, das CI/CD-System weiß nichts über offene Security-Findings, und das Monitoring-Dashboard hat keine Verbindung zu den Deployment-Logs. Jede Information muss manuell zusammengetragen werden – ein Aufwand, der mit jeder Iteration wächst.

Entscheidend ist: Komplexität entsteht nicht nur durch die Anzahl der Tools, sondern vor allem durch fehlende Integration, unklare Prozesse und getrennte Datenflüsse. Ein DevOps Stack mit fünf schlecht integrierten Tools kann aufwendiger sein als einer mit zehn, die über eine gemeinsame Plattform verbunden sind.

Finde heraus, wie viel dich deine fragmentierte Toolchain wirklich kostet!

Häufige Fehler beim Aufbau eines DevOps Stacks

Die folgenden acht Fehler treten in der Praxis besonders häufig auf. Zu jedem gehört eine Best Practice, die zeigt, wie sich das Problem vermeiden oder beheben lässt.

1. Den DevOps Stack nur als Tool-Liste verstehen

Der häufigste Fehler beginnt schon bei der Grundannahme: Ein DevOps Stack wird als Sammlung einzelner Tools betrachtet, die bestimmte Funktionen abdecken. CI/CD, Versionierung, Testing, Monitoring: Für jede Kategorie wird ein Produkt ausgewählt, und damit gilt der Stack als komplett.

Dabei fehlt das Entscheidende: der Workflow. Tools sind Mittel zum Zweck, kein Selbstzweck. Ohne ein klares Bild davon, wie Software im Unternehmen entwickelt, getestet, gesichert und ausgeliefert wird, bleibt jede Tool-Auswahl willkürlich. Das Ergebnis ist ein Stack, der auf dem Papier vollständig aussieht, in der Praxis aber voller Brüche steckt, weil die einzelnen Bausteine nicht aufeinander abgestimmt sind.

Best Practice: Zuerst den Software Delivery Workflow definieren: von der Idee bis zum Release und darüber hinaus. Dann die passenden Tools oder Plattformfunktionen auswählen, die diesen Workflow unterstützen, statt ihn nachträglich um vorhandene Tools herum zu bauen.

2. Tools isoliert nach Einzelfunktionen auswählen

Ein Tool überzeugt im Proof-of-Concept. Es löst ein konkretes Problem hervorragend. Also wird es eingeführt, ohne zu prüfen, wie es sich in die bestehende Landschaft einfügt. Das Ergebnis: Tools, die für sich betrachtet exzellent sind, aber in der Gesamtarchitektur Brüche erzeugen.

Isolierte Tool-Entscheidungen führen dazu, dass Berechtigungsmodelle nicht kompatibel sind, Daten manuell zwischen Systemen übertragen werden müssen und Automatisierungsketten an Systemgrenzen abbrechen.

Best Practice: Bei jeder Tool-Auswahl prüfen, wie sie in den gesamten Workflow passt: hinsichtlich Integration, Berechtigungen, Datenfluss, Automatisierung, Skalierbarkeit und Governance. Ein Tool, das isoliert gut funktioniert, aber nicht integrierbar ist, schafft langfristig mehr Probleme als es löst.

3. CI/CD und Pipeline-Architektur zu spät planen

CI/CD wird in vielen Teams erst dann strukturiert aufgesetzt, wenn die Komplexität bereits überhandnimmt. In der Anfangsphase reichen einfache Skripte und manuelle Deployments. Doch mit wachsender Teamgröße und steigender Release-Frequenz werden fehlende Standards zum Flaschenhals: Jedes Team baut eigene Pipelines, es gibt keine einheitlichen Vorgaben für Tests, Security Checks oder Artefakt-Management.

Best Practice: Die DevOps Pipeline von Anfang an als Rückgrat des Stacks planen. Standards für Pipeline as Code, Jobs, Tests, Security Checks, Artefakte und Deployment-Strategien früh definieren, bevor sich unterschiedliche Ansätze in den Teams verfestigen.

4. Automatisierung nur punktuell statt durchgängig denken

Viele Teams automatisieren dort, wo der Leidensdruck am größten ist: den Build-Prozess, einzelne Tests oder das Deployment in die Staging-Umgebung. Der Rest bleibt manuell, insbesondere Security-Scans, Compliance-Prüfungen, Release-Freigaben und das Monitoring nach dem Go-live.

Punktuelle Automatisierung erzeugt gefährliche Lücken. Manuelle Schritte zwischen automatisierten Phasen sind nicht nur langsamer, sondern auch fehleranfälliger und schwerer nachzuvollziehen.

Best Practice: DevOps Automation entlang des gesamten Software Delivery Lifecycle planen: von der Code-Änderung über Tests und Security bis Deployment, Monitoring und Feedback. Das Ziel ist eine durchgängige Kette, in der manuelle Eingriffe die Ausnahme sind, nicht die Regel.

Erfahre, wie Bitpanda mit GitLab den manuellen Aufwand stark reduziert hat und stündlich flexibel deployen kann.

"Wir haben keinen festen Release-Termin. Wir deployen täglich, stündlich." — David Papp, Head of Development, Bitpanda

5. Security und Compliance erst nachträglich integrieren

Security wird in vielen DevOps Stacks als nachgelagerter Schritt behandelt: Der Code wird entwickelt und getestet, erst danach prüft ein separates Security-Team auf Schwachstellen. Dieses Vorgehen führt zu späten Entdeckungen, teuren Nachbesserungen und Verzögerungen im Release-Zyklus.

Dasselbe gilt für Compliance: Wenn Audit-Anforderungen, Freigabeprozesse und Nachweispflichten nicht im Workflow verankert sind, entstehen sie als zusätzlicher manueller Aufwand, oft unter Zeitdruck und mit lückenhafter Dokumentation.

Best Practice: Security und Compliance von Anfang an in den DevOps Stack integrieren. Shift-left Security bedeutet, automatisierte Scans bereits in der Pipeline laufen zu lassen und nicht erst am Ende. Klare Rollenmodelle, definierte Freigabeprozesse und auditierbare Workflows sollten Teil der Architektur sein, nicht nachträglich aufgesetzt werden.

6. Monitoring und Feedback-Loops vernachlässigen

Viele DevOps Stacks enden beim Deployment. Was danach passiert – ob die Anwendung stabil läuft, wie Nutzer(innen) sie verwenden, wo Fehler auftreten – wird entweder gar nicht oder nur rudimentär erfasst. Ohne systematisches DevOps Monitoring fehlt dem Team die Grundlage für datengestützte Verbesserungen.

Ebenso wichtig sind Feedback-Loops: Erkenntnisse aus dem Betrieb müssen zurück in die Entwicklung fließen, damit wiederkehrende Probleme an der Wurzel behoben werden, nicht immer wieder im Incident-Management.

Best Practice: Monitoring, Incident Response und Feedback-Loops als festen Bestandteil des DevOps Stacks behandeln. Das Ziel ist nicht nur die Auslieferung von Software, sondern ein geschlossener Kreislauf der kontinuierlichen Verbesserung.

7. Versteckte Kosten des DevOps Stacks unterschätzen

Die offensichtlichsten Kosten eines DevOps Stacks sind die Lizenzgebühren. Doch sie machen oft nur einen Bruchteil der Gesamtkosten aus. Integrationsaufwand, Betrieb und Wartung der Schnittstellen, Schulungen für verschiedene Tools, Produktivitätsverluste durch Kontextwechsel, Sicherheitsrisiken durch uneinheitliche Konfigurationen und der Aufwand für die Skalierung auf neue Teams – all das summiert sich.

Teams, die diese versteckten Kosten nicht systematisch erfassen, treffen Tool-Entscheidungen auf einer unvollständigen Datenbasis und unterschätzen den wahren Preis ihrer Fragmentierung.

Best Practice: Die Gesamtkosten des Stacks regelmäßig bewerten und somit die DevOps Kosten senken: nicht nur Lizenzkosten, sondern auch Integrationsaufwand, Betrieb, Schulungen, Produktivitätsverluste, Sicherheitsrisiken und Skalierungsaufwand. Ein konsolidierter Stack spart nicht nur Lizenzgebühren, sondern reduziert auch den operativen Overhead erheblich.

8. Skalierung, Governance und Team-Standards nicht mitdenken

Was für ein Team mit fünf Entwickler(inne)n funktioniert, skaliert selten auf zwanzig Teams mit unterschiedlichen Anforderungen. Ohne gemeinsame Standards für Tool-Auswahl, Pipeline-Vorlagen, Sicherheitsregeln und Rollenmodelle entsteht mit jedem neuen Team eine weitere Variante des DevOps Stacks, mit eigenen Konventionen, eigenen Workarounds und eigenen blinden Flecken.

Best Practice: Standards für den DevOps Stack zentral definieren: Pipeline-Templates, Sicherheitsrichtlinien, Rollenmodelle, Dokumentationsvorgaben und Governance-Regeln. Dabei genug Flexibilität für Teams erhalten, um spezifische Anforderungen zu erfüllen, aber zentrale Leitplanken setzen, die Konsistenz und Nachvollziehbarkeit sicherstellen.

Wie GitLab beim Aufbau moderner DevOps Stacks unterstützt

Die meisten der beschriebenen Fehler haben eine gemeinsame Ursache: Fragmentierung. Zu viele Einzeltools, zu viele Schnittstellen, zu wenig Durchgängigkeit. GitLab adressiert dieses Problem nicht als weiteres Tool im Stack, sondern als integrierte DevSecOps-Plattform, die zentrale Funktionen in einem gemeinsamen Workflow bündelt.

Von der Planung über Source Code Management, CI/CD, Security-Scanning und Compliance bis hin zu Deployment und Monitoring deckt GitLab den gesamten Software Delivery Lifecycle ab, auf einer einzigen Oberfläche, mit einheitlichen Berechtigungen, durchgängigen Datenflüssen und nativer Automatisierung. Teams arbeiten in derselben Umgebung, sprechen dieselbe Sprache und sehen denselben Stand ohne Kontextwechsel und ohne Integrationsaufwand zwischen verschiedenen Systemen.

Das bedeutet nicht, dass jedes Unternehmen ausschließlich GitLab nutzen muss. Aber eine Plattform, die den Kern des DevOps Stacks abdeckt, reduziert die Komplexität dort, wo sie am meisten schadet: an den Schnittstellen. Neue Teammitglieder arbeiten sich in eine Umgebung ein statt in zehn. Security-Findings, Build-Status und Deployment-Informationen sind an einem Ort verfügbar. Und Governance-Regeln lassen sich zentral definieren und durchsetzen, statt in jedem Tool einzeln konfiguriert zu werden.

Bereit für schnellere und sichere Releases ohne Tool-Wildwuchs?

DevOps-Tools gibt es viele – und genau das bremst dich. Sorge mit einer integrierten Plattform für effiziente Prozesse über den gesamten SDLC hinweg!

Jetzt kostenlos testen

Häufig gestellte Fragen zum Thema DevOps Stack aufbauen

Was ist der Unterschied zwischen DevOps Stack und DevOps Toolchain?

Die Begriffe werden oft synonym verwendet, beschreiben aber unterschiedliche Perspektiven. Eine DevOps Toolchain bezeichnet die Abfolge der Tools, die entlang des Software Delivery Lifecycle eingesetzt werden – typischerweise als lineare Kette von der Planung bis zum Monitoring. Der DevOps Stack ist der umfassendere Begriff: Er schließt neben den Tools auch die Plattformen, Infrastrukturkomponenten, Integrationen, Automatisierungen und Prozesse ein, die das Gesamtsystem bilden. Ein DevOps Stack beschreibt also nicht nur welche Tools im Einsatz sind, sondern auch wie sie zusammenwirken.

Wie kann man Tool-Sprawl vermeiden?

Tool-Sprawl entsteht, wenn Teams eigenständig und ohne zentrale Koordination Tools einführen. Die wirksamste Gegenmaßnahme ist eine Kombination aus klaren Governance-Regeln für die Tool-Auswahl, regelmäßigen Audits der bestehenden Tool-Landschaft und der Konsolidierung auf möglichst wenige, gut integrierte Plattformen. Bevor ein neues Tool eingeführt wird, sollte geprüft werden, ob eine vorhandene Lösung dieselbe Funktion bereits abdeckt oder abdecken könnte.

Wann sollte ein DevOps Stack konsolidiert werden?

Typische Anzeichen dafür, dass eine Konsolidierung überfällig ist: steigende Integrationskosten, häufige Brüche in der Automatisierung, mangelnde Transparenz über den Gesamtstatus von Projekten, wiederkehrende Sicherheitslücken an Systemgrenzen, hoher Schulungsaufwand für neue Teammitglieder und das Gefühl, mehr Zeit mit der Pflege der Tools als mit der eigentlichen Entwicklung zu verbringen.

Wann ist eine DevOps-Plattform besser als einzelne Tools?

Eine integrierte Plattform bietet Vorteile, sobald die Kosten und der Aufwand für Integration, Wartung und Governance der Einzeltools den Nutzen ihrer spezifischen Stärken übersteigen. In der Praxis ist dieser Punkt oft früher erreicht als erwartet, insbesondere wenn Teams wachsen, Compliance-Anforderungen steigen oder die Release-Frequenz zunimmt. Eine Plattform eliminiert Schnittstellen, reduziert Kontextwechsel und schafft eine einheitliche Datenbasis für alle Beteiligten. Das heißt nicht, dass Spezialtools nie ihre Berechtigung haben, aber der Kern des Stacks profitiert fast immer von einer integrierten Lösung.

GitLab Secrets Manager unterstützt jetzt den External Secrets Operator (ESO) und Terraform und erweitert damit den sicheren Abruf von Secrets über CI/CD-Pipelines hinaus. Auf Basis von OpenBao bietet GitLab Secrets Manager eine einzige verlässliche Quelle für Secrets entlang der gesamten Software-Delivery-Kette. Derselbe Secret-Store bedient jetzt:

• Kubernetes-Workloads über ESO
• Terraform- oder OpenTofu-Runs
• OpenBao- oder Vault-CLI
• CI/CD-Jobs in GitLab (ab Version 19.0)
• jede externe Automatisierung über die Secrets Manager API

Kubernetes: External Secrets Operator

ESO synchronisiert Secrets aus GitLab Secrets Manager über den Vault-Provider. Ein Workload im Cluster hält ein kurzlebiges JSON Web Token (JWT). Damit authentifiziert sich ESO bei OpenBao und schreibt das Secret in ein Kubernetes Secret.

Ein SecretStore legt fest, woher ESO Secrets bezieht und wie authentifiziert wird. GitLab Secrets Manager stellt eine Vault-kompatible KV-v2-API bereit, die sich über den Vault-Provider konfigurieren lässt. Das Feld namespace bildet die GitLab-Hierarchie ab (Organisation, Gruppe, Projekt) und grenzt ein, welche Secrets dieser Store erreichen kann. Die Authentifizierung nutzt ein von GitLab ausgestelltes JWT, das in einem Kubernetes Secret liegt und über secretRef referenziert wird.

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gitlab-secrets-manager
  namespace: my-app
spec:
  provider:
    vault:
      server: https://secrets.gitlab.com      # provider.vault.server
      path: secrets/kv                        # provider.vault.path
      version: v2
      namespace: org_5/group_42/project_99    # provider.vault.namespace
      auth:
        jwt:
          path: api_jwt/cel                   # provider.vault.auth.jwt.path
          role: all_api                       # provider.vault.auth.jwt.role
          secretRef:
            name: gitlab-access-token         # Kubernetes secret holding the minted token
            key: token

Ein ExternalSecret definiert, welche Secrets geholt werden und wohin sie gehören. Es referenziert den zuvor angelegten SecretStore und bildet Remote-Secrets auf ein Kubernetes Secret ab, das Workloads einhängen oder als Umgebungsvariablen referenzieren können.

ESO erstellt und besitzt das Ziel-Secret (synced-secret) und holt es bei jedem refreshInterval erneut von GitLab, sodass rotierte Werte ohne erneutes Deployment ankommen. Jeder Eintrag unter data bildet ein Remote-Secret auf einen Schlüssel im Ziel ab: remoteRef.key ist der Pfad im GitLab Secrets Manager, property wählt ein Feld innerhalb dieses Secrets aus, und secretKey ist der Schlüssel, unter dem es in Kubernetes landet.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
  namespace: my-app
spec:
  refreshInterval: 45m
  secretStoreRef:
    name: gitlab-secrets-manager
    kind: SecretStore
  target:
    name: synced-secret
  data:
    - secretKey: value
      remoteRef:
        key: explicit/<secret_name>           # <secrets_path>/<secret_name>
        property: value

Das Tutorial zeigt GitLab Secrets Manager zusammen mit ESO.

Infrastructure as Code: Terraform und OpenTofu

Terraform-State und .tfvars-Dateien sind eine häufige Quelle geleakter Zugangsdaten, weil Secrets versehentlich auf der Festplatte landen oder in die Versionskontrolle eingecheckt werden. Terraform kann das vermeiden, indem es ein GitLab-Secret als Data Source liest und sich zum Zeitpunkt von plan oder apply mit einem ausgestellten JWT authentifiziert. Zugangsdaten lassen sich damit direkt in Terraform referenzieren, ohne dass etwas in .tfvars-Dateien oder CI/CD-Variablen gespeichert wird.

data "external" "gitlab_secrets_token" {
  program = ["bash", "${path.module}/scripts/mint_token.sh"]

  query = {
    project_id = var.gitlab_project_id
  }
}

provider "vault" {
  address   = data.external.gitlab_secrets_token.result.server
  namespace = data.external.gitlab_secrets_token.result.namespace

  auth_login_jwt {
    mount = data.external.gitlab_secrets_token.result.auth_path
    role  = data.external.gitlab_secrets_token.result.role
    jwt   = data.external.gitlab_secrets_token.result.jwt
  }
}

data "vault_kv_secret_v2" "my_secret" {
  mount = data.external.gitlab_secrets_token.result.mount
  name  = "${data.external.gitlab_secrets_token.result.secrets_path}/<secret_name>"
}

output "secret_value" {
  value     = data.vault_kv_secret_v2.my_secret.data["value"]
  sensitive = true
}

Wie sich Secrets in Terraform lesen lassen, zeigt die Dokumentation.

Kommandozeile: OpenBao- oder Vault-CLI

Nicht jeder Workflow läuft direkt über die API. Wer ohnehin schon Skripte gegen Vault-kompatible Werkzeuge schreibt, liest mit der OpenBao- oder Vault-CLI Secrets aus GitLab Secrets Manager genauso wie aus Vault.

export VAULT_ADDR="<server>"
export VAULT_NAMESPACE="<namespace>"

# Exchange the minted JWT for an OpenBao token, then export it.
vault write "auth/<auth_jwt_path>/login" role=<role> jwt=<token>
export VAULT_TOKEN="<client_token>"

# Read the secret value.
vault kv get -mount=<path> "<secrets_path>/<secret_name>"

Wann die Secrets Manager API sinnvoll ist

Für Automatisierung, die weder zu GitLab CI/CD noch zu Kubernetes oder Terraform passt, ermöglicht die Secrets Manager API beliebigen externen Systemen, Secrets aus dem Secrets Manager abzurufen, statt Zugangsdaten fest zu hinterlegen oder getrennte Variablendateien zu pflegen.

# Request JWT token using Service Account
RESPONSE=$(curl --silent --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/<project_id>/secrets_manager/access_token")

SERVER=$(echo "$RESPONSE" | jq --raw-output .provider.vault.server)
NAMESPACE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.namespace)
MOUNT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.path)
SECRETS_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.secrets_path)
AUTH_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.path)
ROLE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.role)
JWT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.token)

# Exchange the JWT for a short-lived OpenBao token.
VAULT_TOKEN=$(curl --silent --request POST \
  --header "X-Vault-Namespace: $NAMESPACE" \
  --data "{\"role\":\"$ROLE\",\"jwt\":\"$JWT\"}" \
  "$SERVER/v1/auth/$AUTH_PATH/login" | jq --raw-output .auth.client_token)

# Read the secret value.
curl --silent \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --header "X-Vault-Namespace: $NAMESPACE" \
  "$SERVER/v1/$MOUNT/data/$SECRETS_PATH/<secret_name>"

Erste Schritte

GitLab Secrets Manager ist in der Public Beta für Premium und Ultimate. Der Secret-Zugriff über ESO, Terraform oder die API steht derzeit auf GitLab.com und GitLab Self-Managed zur Verfügung, GitLab Dedicated folgt.

Während der Beta-Phase ist Secrets Manager kostenlos. Mit der allgemeinen Verfügbarkeit wird daraus eine kostenpflichtige Funktion, die über GitLab Credits abgerechnet wird. Vor einer Abrechnung ist eine ausdrückliche Zustimmung nötig, und wir kündigen das rechtzeitig an.

Die Dokumentation hilft beim Einstieg. Wer eine Lücke findet oder einen Wunsch hat, kommentiert in diesem Issue. Wir sammeln Feedback vor der allgemeinen Verfügbarkeit.

GitLab Duo Self-Hosted kann jetzt Privatemode AI als Modellanbieter nutzen. Privatemode betreibt aktuelle Modelle innerhalb von Confidential-Computing-Hardware, sodass Prompts, Quellcode und Completions durchgehend verschlüsselt bleiben, auch während der Inferenz. Das AI Gateway von GitLab Duo wird auf den Privatemode-Proxy gerichtet. Die Entwicklungsteams erhalten dann dieselben Duo-Funktionen wie mit jedem anderen Modell, mit einem Unterschied, der für eine regulierte Organisation zählt: Der Code verlässt nie eine verschlüsselte Grenze, und kein Dritter kann ihn lesen.

Die Unterstützung, die regulierten Teams bisher verwehrt bleibt

KI-Unterstützung beim Programmieren ist längst mehr als Autovervollständigung. Die GitLab Duo Agent Platform übernimmt mehrstufige Arbeit: Sie reviewt Merge Requests, refaktoriert über Dateien hinweg, erzeugt Tests und führt sie aus, steuert agentische Flows als CI-Jobs und einiges mehr. Das verändert die Art, wie Teams liefern, und die Wirkung summiert sich. Teams, die sie nutzen, wenden weniger Aufwand für Standardaufgaben auf und mehr für inhaltliche Reviews.

Der Haken: Jede einzelne dieser Funktionen sendet Prompts und Quellcode an einen Modellanbieter. Für ein Team, das an proprietärem Code, regulierter Software oder sensiblem geistigem Eigentum arbeitet, ist allein diese Tatsache ein Ausschlusskriterium.

Warum regulierte Organisationen selbst hosten

Für diese Organisationen ist Quellcode zentrales geistiges Eigentum, und wo er verarbeitet wird, ist eine vertragliche, branchenspezifische und regulatorische Frage, keine der Bequemlichkeit. Die Handelsalgorithmen einer Bank, die Firmware eines Medizingeräteherstellers, die Steuerungssoftware eines Rüstungsunternehmens: Dieses geistige Eigentum an einen externen KI-Dienst zu senden, kann IP-Schutz, Auftragsverarbeitungsverträge und Branchenregeln in einem einzigen Schritt verletzen.

Der Druck kommt aus mehreren Richtungen zugleich. NIS2 und der Digital Operational Resilience Act (DORA) heben die Anforderungen an operative Resilienz und Drittparteienrisiken in kritischer Infrastruktur und im Finanzsektor. Die DSGVO regelt, wie personenbezogene Daten in Code und Logs verarbeitet werden. Branchenregime wie die BaFin-Aufsicht im deutschen Finanzwesen, BSI C5 als Beschaffungsgrundlage und Vorgaben für Gesundheitsdaten setzen eigene Rahmen. Und viele europäische Organisationen behandeln Datensouveränität ohnehin als Anforderung erster Ordnung, unabhängig von einer einzelnen Regulierung.

Am deutlichsten spüren das Finanzdienstleister, Gesundheitswesen und Pharma, Verteidigung, der öffentliche Sektor und kritische Infrastruktur. GitLab Self-Hosted existiert genau dafür, dass dieser Code einen vertrauenswürdigen Perimeter nie verlassen muss. KI in den Workflow zu holen, sollte das nicht stillschweigend aushebeln.

Warum KI das Selbst-Hosten erschwert

Ein selbst hostendes Team, das KI-Unterstützung beim Programmieren möchte, hat drei herkömmliche Optionen, und jede hat Kosten, die eine regulierte Organisation kaum tragen kann.

Die Tabelle zeigt: Öffentliche KI-SaaS und VPC-Optionen legen Code offen und stützen sich auf vertragliche Zusicherungen, während ein eigener Stack den Code zwar privat hält, aber erheblichen Aufwand für GPUs und Modellbetrieb mit sich bringt.

Nüchtern zusammengefasst: Öffentliche SaaS scheidet aus, weil der Code das Haus verlässt. Ein VPC-isolierter oder Private-Cloud-Dienst verringert die Offenlegung, übergibt den Klartext aber weiterhin an den Betreiber und den darunterliegenden Cloud-Anbieter. Ein Vertrag ist zudem ein Versprechen, keine kryptografische Zusicherung. Eigene Modelle zu betreiben, hält den Code privat, ist aber teuer in der Beschaffung, teuer im Personal und strukturell hinter den besten verfügbaren Modellen. Vor dieser Wahl führen die meisten regulierten Organisationen KI nur eng begrenzt oder gar nicht ein.

Damit stellt sich die Frage: Wie erhalten Entwicklungsteams moderne KI-Coding-Agenten, ohne dass Quellcode den Perimeter verlässt und ohne selbst einen LLM-Stack zu betreiben? Die Antwort verlangt eine andere Art von Zusicherung, als ein Vertrag sie geben kann, nämlich eine, die Hardware durchsetzt.

Confidential Computing: die architektonische Antwort

Confidential Computing hält Daten im Arbeitsspeicher verschlüsselt, also während der Verarbeitung, mithilfe eines hardwarebasierten Trusted Execution Environment (TEE), eines isolierten Bereichs einer CPU oder GPU, in den weder Betriebssystem noch Hypervisor noch der Betreiber der Maschine hineinlesen können. Die relevante Hardware ist hier AMD SEV oder Intel TDX auf CPU-Seite, kombiniert mit NVIDIA Confidential Computing auf der GPU. Daten sind bei der Übertragung und im Ruhezustand mit AES-256 verschlüsselt und werden ausschließlich innerhalb des TEE entschlüsselt.

Was daraus statt eines Versprechens eine Zusicherung macht, ist die Remote Attestation. Bevor ein Client Daten sendet, fordert er das TEE auf nachzuweisen, was es ist: Die Hardware erzeugt signierte, kryptografische Belege darüber, welcher Code genau innerhalb der Enclave läuft. Der Client prüft diese Belege gegen bekannte Sollwerte und baut erst danach den verschlüsselten Kanal auf und sendet seine Anfrage. Erst prüfen, dann senden.

Das Datenflussdiagramm zeigt Prompts, die auf dem Client verschlüsselt, als Chiffrat übertragen und erst innerhalb eines Hardware-TEE entschlüsselt werden, in das weder der Betreiber des Dienstes noch der Cloud-Anbieter hineinsehen kann.

Die daraus folgende Sicherheitseigenschaft ist der eigentliche Punkt: Weder der Betreiber des KI-Dienstes noch der darunterliegende Cloud-Anbieter sieht Prompts, Completions oder Kontext. Nicht, weil sie versprechen, nicht hinzusehen, sondern weil die Hardware es nicht zulässt.

Privatemode AI

Privatemode AI stammt von Edgeless Systems, einem auf Confidential-Computing-Software spezialisierten Unternehmen aus Deutschland. Laut NVIDIA ist Privatemode das "first generative AI framework that keeps prompts encrypted at all times".

Für die Entwicklungsarbeit bleibt die Mechanik unsichtbar. Privatemode stellt eine OpenAI-kompatible API bereit, und ein clientseitiger Proxy übernimmt Attestation und Verschlüsselung transparent, sodass Werkzeuge und SDKs, die die Standard-/v1-API sprechen, unverändert funktionieren. Aktuelles Flaggschiffmodell fürs Programmieren ist Kimi K2.6 mit 256K Kontext, weitere wie Kimi K3 und GLM folgen.

Das ist kein Laborexperiment. Privatemode läuft bereits produktiv bei Organisationen mit genau den oben beschriebenen Rahmenbedingungen. Capgemini nutzt es für Kunden aus regulierten Branchen, einschließlich vertraulicher Programmierarbeit. Die Bundesagentur für Arbeit setzt es im öffentlichen Sektor ein. Und Banken, Versicherer und Verteidigungsorganisationen nutzen es dort, wo Quellcode und Daten eine vertrauenswürdige Grenze nicht verlassen dürfen. Die Kryptografie ist post-quantensicher, was auch gegen Angriffe nach dem Muster "harvest now, decrypt later" schützt. Wer heute Chiffrat abgreift, um es mit der Hardware von morgen zu entschlüsseln, erhält nichts Verwertbares.

So funktioniert die Integration

Mit GitLab Duo Self-Hosted lassen sich die KI-Funktionen von Duo aus einem selbst kontrollierten Modell bedienen statt aus einem von GitLab betriebenen Gateway. Privatemode tritt an diese Stelle.

Der Weg ist unkompliziert. GitLab Duo spricht mit einem selbst gehosteten AI Gateway, das die Inferenz an einen beliebigen OpenAI-kompatiblen Endpunkt weiterreicht. Der Privatemode-Proxy ist dieser Endpunkt: Er stellt eine Standard-/v1-API bereit und übernimmt Verschlüsselung und Attestation gegenüber dem Privatemode-Dienst. Trifft eine Anfrage ein, verschlüsselt der Proxy sie, bevor sie das eigene Netz verlässt, prüft das entfernte TEE per Attestation und leitet sie erst dann weiter. Entschlüsselt wird ausschließlich innerhalb der Confidential-Computing-Umgebung. Innerhalb von Duo, über Code Suggestions, Chat, Code Review und agentische Flows hinweg, bleibt die Arbeitsweise für Entwickelnde unverändert.

sequenceDiagram
    autonumber
    actor Dev as Entwickelnde /<br>Duo Agent Platform
    participant GW as Selbst gehostetes<br>GitLab AI Gateway
    participant Proxy as Privatemode<br>Proxy
    participant TEE as Entferntes TEE<br>(CPU + GPU)

    Dev->>GW: Inferenz-Anfrage (Code<br>Suggestions, Chat,<br>Code Review, Flows)
    GW->>Proxy: Anfrage an OpenAI-<br>kompatiblen Endpunkt<br>weiterleiten

    rect rgb(255, 244, 214)
        Note over Proxy,TEE: Attestation, bevor Code gesendet wird
        Proxy->>TEE: Attestation-Belege anfordern
        TEE-->>Proxy: Signierte Belege des Enclave-Codes
        Proxy->>Proxy: Belege gegen bekannte Sollwerte prüfen
        Proxy->>TEE: Verschlüsselten Kanal aufbauen (AES-256, post-quantensicher)
    end

    Proxy->>TEE: Verschlüsselte Anfrage weiterleiten
    Note over TEE: Entschlüsselung und Inferenz<br>nur innerhalb der Enclave
    TEE-->>Proxy: Verschlüsselte Antwort
    Proxy-->>GW: Verschlüsselte Antwort
    GW-->>Dev: Completion (Arbeitsweise<br>unverändert)

Im Sequenzdiagramm läuft eine Anfrage aus GitLab Duo über das selbst gehostete AI Gateway zum Privatemode-Proxy, der die entfernte Enclave attestiert und einen verschlüsselten Kanal aufbaut. Erst danach reicht er die Anfrage zur Inferenz innerhalb des TEE weiter. AI Gateway und Proxy werden selbst betrieben, und das Setup ist deployment-agnostisch (Linux-Paket, Docker oder Kubernetes). Die Schritte sind dokumentiert und versionsspezifisch, deshalb hier nicht wiederholt: siehe Privatemodes Integrationsanleitung für GitLab Duo.

Die Kompromisse

Keine Architektur ist umsonst, und ein technisches Publikum hat Anspruch darauf, die Kosten klar benannt zu bekommen.

Gateway und Proxy werden selbst betrieben. Das ist echte Infrastrukturarbeit: das AI Gateway unter einem passenden Hostnamen bereitstellen, seine Image-Version bei jedem Upgrade zur GitLab-Version passend halten, JWT-Schlüssel und Zertifikate konfigurieren und den Proxy erreichbar halten. Es ist allerdings gewöhnlicher Infrastrukturbetrieb, keine GPU-Beschaffung und kein Modellbetrieb. Genau darin liegt der Unterschied. Die Alternative, die den Code ebenfalls privat hält, nämlich ein eigener LLM-Stack, bedeutet knappe GPUs zu kaufen und ein Team für Betrieb und Modell-Updates zu stellen, während man den führenden Modellen hinterherläuft. Privatemode ist ein gehosteter SaaS-Dienst, der den Modellbetrieb übernimmt, und was bleibt, sind ein Proxy und ein Gateway.

Generische OpenAI-kompatible Modelle sind in GitLab Duo Self-Hosted noch nicht ausgereift. Sie laufen derzeit als Beta-Funktion, Support für modellspezifische Probleme ist also noch nicht zugesichert. Eine Härtung steht auf der Roadmap, doch wer jetzt eine vollständig unterstützte Konfiguration braucht, sollte diesen Zeithorizont im Rollout berücksichtigen.

Attestation und Verschlüsselung erzeugen zusätzlichen Aufwand. Der zusätzliche Roundtrip und die kryptografische Arbeit kosten pro Anfrage etwas. In unseren Tests war das praktisch kein Problem, die Integrationsanleitung empfiehlt allerdings, das Timeout des AI Gateway für langsamere selbst gehostete Backends heraufzusetzen, weshalb sich eine Messung am eigenen Latenzbudget lohnt.

Vertrauen bleibt nötig, aber es ist begrenzt. Die Zusicherung beruht darauf, dass das Hardware-TEE und die Kette der Attestation solide sind. Das ist eine kleinere, besser prüfbare Vertrauensannahme als "dem Betreiber vertrauen, dass er nicht hinsieht", und die Belege der Attestation lassen sich selbst nachprüfen, aber null ist sie nicht. Confidential Computing verengt das Vertrauen auf das Silizium. Es beseitigt es nicht.

Was das in der Praxis bedeutet

• Für regulierte Organisationen: Der Weg zu modernen KI-Coding-Agenten passt zur bestehenden Richtlinie für IP- und Datenschutz, weil der Code innerhalb einer hardwareverschlüsselten Grenze bleibt, und das ohne GPU-Kauf und ohne eigenen Modellbetrieb.
• Für Entwickelnde: Die GitLab-Duo-Erfahrung bleibt dieselbe, die Modelle sind dieselben oder besser, und neue Werkzeuge braucht es nicht. Da die Modellauswahl auf der Instanz liegt, übernehmen auch Chat und Code Suggestions im Editor über die GitLab Workflow Extension dasselbe vertrauliche Setup.
• Für Compliance- und Security-Teams: Die Architektur passt zur Richtung von BSI C5:2026 hin zu Confidential Computing und Remote Attestation, und sie liefert konkrete technische Belege, nämlich Verschlüsselung während der Verarbeitung und attestierte Ausführung, für Gespräche zu NIS2, DORA und DSGVO. Compliance stellt sie damit nicht allein her, denn Compliance ist organisatorisch und fortlaufend. Sie räumt aber den Einwand aus, der KI-Einführung überhaupt erst blockiert: "Unser Code würde den Perimeter verlassen."

Mit Privatemode starten

Für Privatemode als selbst gehosteten Modellanbieter braucht es GitLab Self-Managed mit Premium oder Ultimate, ab Version 17.9. Hinzu kommt das Add-on GitLab Duo Enterprise. Agentische Flows benötigen zusätzlich die GitLab Duo Agent Platform (allgemein verfügbar ab Version 18.8). Die Nutzung verbraucht GitLab Credits nach den Regeln und Multiplikatoren für Bring-your-own-Model, die in der Dokumentation zu GitLab Credits beschrieben sind.

Weiterlesen

• Privatemode-Dokumentation
• Integrationsanleitung für GitLab Duo
• Leitfaden für Coding-Assistenten
• Capgemini-Fallstudie
• NVIDIA-Lösungsbeschreibung

GitLab deckt den restlichen Weg in die Produktion ab. Im typischen Sicherheits-Workflow von Anthropics Claude zu GitLab gibt es fünf Übergaben. Dieser Artikel geht jede einzelne davon durch und zeigt, wie sich agentisches Coding im großen Maßstab steuern lässt.

Teams, die Claude security guidance und Claude Security bereits nutzen, können diesen Kontext über den GitLab-MCP-Server direkt in GitLab einspeisen und ihren bestehenden Workflow beibehalten. Claude übernimmt den Moment des Schreibens, GitLab alles von dort bis in die Produktion, auf einer Plattform.

Von markierten Findings zu durchgesetzten Kontrollen

Das Claude security guidance plugin prüft Code innerhalb der Session einer einzelnen entwickelnden Person und erkennt Probleme, während der Agent weiterarbeitet. Sobald dieser Code die Session verlässt, brauchen Security-Teams eine Aufzeichnung dessen, was darin geschah, und Kontrolle darüber, was als Nächstes passiert.

GitLab gibt Teams die Sichtbarkeit und die Kontrolle, um Guardrails für sicheres Coding zu definieren, bevor Code die Produktion erreicht, unabhängig davon, wo er entstanden ist.

• Kontrollen einmal definieren, überall durchsetzen: Security Configuration Profiles wenden die erforderlichen Scans über jedes Projekt und jede Pipeline hinweg an, von außerhalb des Repositorys, sodass die Abdeckung konsistent ist und sich nicht umgehen lässt.
• Funktionstrennung durchsetzen, auch für Agenten: Merge-Request-Approval-Policies stellen sicher, dass der Agent, der eine Änderung geschrieben hat, sie nicht selbst freigeben kann. Weder der Agent noch die Person, die ihn beauftragt hat, kann die eigene Arbeit ohne benannte freigebende Person mergen.
• Kritische Schwachstellen vor dem Ausliefern blockieren: Merge-Request-Approval-Policies halten jeden Merge mit ungelösten kritischen Findings zurück, bis eine benannte Person freigibt, sodass verworfene oder übersehene Schwachstellen nicht unbemerkt in die Produktion gelangen.
• Den Status jedes Findings dauerhaft verfolgen: Vulnerability Report und Security Dashboard zeigen, ob ein Finding erkannt, mit Begründung verworfen oder behoben wurde.

Vom Scan in der Session zum Audit-Nachweis

Audit-Anforderungen im Change-Management werden auf Agenten ausgeweitet. Compliance-Frameworks wie SOC 2, PCI DSS und FedRAMP verlangen dokumentierte Nachweise, dass jede Änderung getestet, reviewt und freigegeben wurde, bevor sie ausgeliefert wurde.

GitLab macht Compliance-Kontrollen durchsetzbar und die Sammlung von Nachweisen für Auditoren automatisch.

• Belegen, dass Scan und Review stattgefunden haben: Compliance Controls garantieren, dass bei jedem Merge Request ein Scan läuft und jedes Finding im Merge Request und im Vulnerability Report auftaucht, sichtbar für einen Menschen.
• Auditoren nachvollziehbar antworten: Pipeline-Logs, Freigabe-Nachweise und Audit-Events liefern eine reproduzierbare Historie darüber, was gescannt wurde und wer freigegeben hat, Änderung für Änderung, verknüpft mit den beteiligten Menschen und Agenten.
• Nachweise dem angefragten Framework zuordnen: Compliance Frameworks gruppieren Nachweise in benannte Anforderungen, etwa SOC 2 oder ein eigenes Framework, jeweils aus konkreten Kontrollen aufgebaut, und der Compliance-Status-Report zeigt pro Framework, welche Kontrollen bestanden haben, ausstehen oder fehlgeschlagen sind.

Steuern, welche sensiblen Daten gesendet werden

An ein Modell geht zur Prüfung vermutlich mehr Code samt dem Geschäftskontext darum herum als an einen Menschen. Regulierte Branchen, Behörden und Teams mit sensiblem geistigem Eigentum müssen entscheiden, was ihre Umgebung verlässt, etwa Zugangsdaten, proprietäre Logik und regulierte Daten. Diese Entscheidung muss fallen, bevor irgendein Scan läuft, und für jedes Werkzeug gelten, das den Code berührt.

Mit GitLab lässt sich festlegen, welche Daten ein Modell erreichen, noch bevor sie die eigene Umgebung verlassen.

• Secrets und sensiblen Code von Modellen fernhalten: Kontext-Ausschlüsse halten Secrets und sensible Dateien aus allem zurück, was ein Agent an Modelle sendet.
• Code und Inferenz innerhalb der eigenen Grenze halten, auf freigegebenen Modellen: Eine self-managed Umgebung mit self-hosted Modellen betreiben, damit nichts die eigene Umgebung verlässt. Das Modell pro Flow auswählen, einschränken, welche Modelle zulässig sind, und den eigenen Code aus dem Training halten.
• Filtern, was gesendet wird: Die Prompt-Guardrails von GitLab Duo prüfen Code-Vorschläge auf Secrets, bevor sie ein Modell erreichen, und isolieren die Inhalte, auf die ein Prompt wirken kann, um das Risiko von Prompt Injection zu senken, zusätzlich zu allem, was ohnehin schon ausgeschlossen ist.

Von einem Scan zu vollständiger Scan-Abdeckung über den Entwicklungszyklus

Anthropics Dokumentation stellt ausdrücklich klar, dass das Claude security guidance plugin ein unterstützendes Werkzeug nach dem Best-Effort-Prinzip ist, gedacht neben menschlichem Code-Review und verschiedenen Security-Scannern, nicht als Ersatz dafür. Diese Einordnung verdient Aufmerksamkeit, denn manche Schwachstellen existieren zum Zeitpunkt des Auslieferns noch nicht. Eine Abhängigkeit, die heute ausgeliefert wird, kann im nächsten Jahr eine kritische Schwachstelle gemeldet bekommen, ohne jede Änderung am eigenen Code. Log4Shell ist das deutlichste Beispiel: Anwendungen, die Jahre früher ausgeliefert worden waren, wurden in dem Moment angreifbar, in dem die Schwachstelle im Dezember 2021 öffentlich bekannt wurde.

Abhängigkeiten, Container-Images, Infrastrukturkonfiguration und Secrets, die längst in der Commit-Historie liegen, brauchen Scans, die unabhängig von einer einzelnen Session laufen.

GitLab sichert den gesamten Software-Delivery-Lebenszyklus ab.

• Die gesamte Angriffsfläche abdecken: Scans für Abhängigkeiten, Container, Infrastructure as Code, Secrets und dynamische Anwendungssicherheitstests (DAST) prüfen die Teile einer Anwendung, die ein sessionbasiertes Review nie erreicht: die eingebundenen Abhängigkeiten, die ausgelieferten Images, die bereitgestellte Infrastruktur, die in Commits geratenen Secrets und die laufende Anwendung.
• Die Fehler finden, die Scannern entgehen können: Deterministische Scanner können Fehler in der Geschäftslogik, fehlerhafte Autorisierung oder Race Conditions nicht erkennen. Security Review Flow schließt aus der Absicht auf genau diese Kategorie und hinterlässt Kommentare am betroffenen Code, auf die ein Mensch reagieren kann.
• Einen deterministischen Scan haben, dessen Ergebnisse nicht driften: Ein LLM-basiertes Review kann bei identischem Code von Durchlauf zu Durchlauf unterschiedliche Findings liefern. Ein deterministischer Scan wie advanced SAST verfolgt verunreinigte Daten mit einem festen Algorithmus über Funktionsgrenzen hinweg und liefert reproduzierbare, CWE-zugeordnete Ergebnisse, also die konsistenten Nachweise, die ein Compliance-Audit braucht.

Ein Satz Guardrails für jeden Agenten und jede entwickelnde Person

Das Claude security guidance plugin prüft den Code, den Claude innerhalb einer Session schreibt und committet. Commits aus der eigenen Shell, einschließlich des Shell-Escapes "!" innerhalb einer Session, liegen außerhalb dessen, was das Plugin prüft. Claude Security erweitert das auf Anfrage auf eine vollständige Codebasis oder auf von Menschen geschriebenen Code, wenn eine entwickelnde oder administrierende Person es ausführt.

GitLabs Scan-Execution- und Merge-Request-Approval-Policies laufen in der Pipeline für jede Änderung. Die Abdeckung hängt damit nicht davon ab, ob ein Mensch oder ein Agent den Code geschrieben hat oder ob daran gedacht wurde, einen Scan zu starten.

Steuern, was ausgeliefert wird

Claude security guidance und Claude Security helfen Entwickelnden, Probleme im Moment des Schreibens zu erkennen und zu beheben. Sobald dieser Code die Session verlässt, sind Security- und Platform-Teams im Unternehmen dafür verantwortlich, ihn sicher in die Produktion zu bringen. Sie brauchen Sichtbarkeit darüber, was ein Agent getan hat, Nachweise, dass Sicherheitsverfahren eingehalten wurden, und die Möglichkeit, eine problematische Änderung vor dem Ausliefern zu stoppen.

GitLab schlägt die Brücke zum Claude-Workflow. Guardrails werden einmal in GitLab gesetzt, und jeder Agent und jede entwickelnde Person liefert innerhalb dieser Guardrails sicherer aus. Claude hilft dabei, sicheren Code zu schreiben. GitLab steuert alles von dort bis in die Produktion.

Jetzt eine kostenlose Testversion von GitLab Ultimate starten

Ultimate bereits im Einsatz? Scan-Execution- und Merge-Request-Approval-Policies einrichten und Guardrails ab heute durchsetzen.

Agentische KI durchbricht diese Schleife. Ein Agent öffnet einen Merge Request, ruft ein Tool auf, ändert eine CI/CD-Konfiguration und pusht eine Änderung, manchmal ohne dass jemand jeden einzelnen Schritt prüft. Hinzu kommt das Model Context Protocol (MCP), über das Agenten sich selbstständig mit externen Tools und Datenquellen verbinden. Damit verschiebt sich die Frage, die Engineering-Verantwortliche stellen: nicht mehr "Welches Modell schreibt den besten Code?", sondern "Was darf dieser Agent tun, und wie lässt sich belegen, was er getan hat?"

Eine eigene Untersuchung von GitLab unter mehr als 1.500 Entwickelnden und Technologieverantwortlichen zeigt, wie verbreitet diese Sorge ist: 73 % der Befragten sehen die langfristige Wartbarkeit von Code kritisch, und 86 % stimmen zu, dass KI-generierter Code ohne klare Governance technische Schulden schneller anhäufen kann als die klassische Entwicklungspraxis.

Dieser Artikel zeigt, wie sich einige der Herausforderungen, die Organisationen bei der Governance agentischer KI zu sehen beginnen, vorausschauend angehen lassen. Er stellt ein Governance-Framework für agentische KI in der Softwareentwicklung vor und behandelt, was zu steuern ist, wo menschliches Review weiterhin hingehört, wie sich eine Einführung messen lässt und welche Checkliste Teams hilft, die auf die GitLab Duo Agent Platform standardisieren.

Warum agentische KI eine andere Governance braucht

Bei einem interaktiven Coding-Assistenten bleibt das Sicherheitsmodell überschaubar, weil an jedem Schritt ein Mensch beteiligt ist: Eine Frage wird gestellt, ein Vorschlag geprüft, angenommen oder verworfen.

Anders liegt der Fall bei agentischer KI in automatisierten Workflows. Kann ein Agent Tests ausführen, Konfigurationen ändern und mehrstufige Aktionen über den Software-Lebenszyklus hinweg vornehmen, ohne dass ein Mensch jeden Schritt prüft, verschieben sich die relevanten Fragen:

• Worauf kann dieser Agent zugreifen?
• Wozu ist er berechtigt?
• Welche Aktionen hat er ausgeführt, und lässt sich das im Nachhinein belegen?

Die meisten Teams spüren das bereits. 92 % der DevSecOps-Fachleute berichten von mindestens einer Governance-Herausforderung bei KI-generiertem Code, und die konkreten Sorgen zielen genau auf die Fragen oben.

Zu den größten Sorgen zählen:

• Code-Zuordnung: überhaupt unterscheiden zu können, welcher Code von einer KI und welcher von Menschen stammt.
• Rückverfolgbarkeit zur Absicht: KI-generierten Code mit der Geschäftsanforderung verbinden, die er erfüllen soll.
• Dokumentation, die mitwächst: Manuelle Dokumentation hält nicht stand, sobald Agenten einen wachsenden Teil der Codebasis erzeugen.

Ist ein Agent für ein Projekt freigegeben, kann er in der Regel schreiben, löschen und pushen, ohne dass die einzelne Aktion vorab geprüft wird. An der Verantwortung für das, was in der Codebasis landet, ändert das nichts, ganz gleich ob Mensch oder Agent die Änderung vorgenommen hat.

Governance für agentische KI ist kein Aufsatz auf die Governance der Code-Vervollständigung. Sie ist ein eigener Ansatz, aufgebaut auf Identität, Berechtigungen und Nachvollziehbarkeit.

Kontrollen für MCPs, Agenten, Modellzugriff und Tool-Berechtigungen setzen

Sobald Agenten Tools aufrufen und sich über Protokolle wie MCP mit externen Systemen verbinden, entscheidet die Rechtevergabe. Ein brauchbares Governance-Modell beantwortet drei Fragen, bevor ein Agent überhaupt läuft:

1. Welche Agenten und Flows sind erlaubt?
2. Wo dürfen sie tätig werden?
3. Welche Modelle dürfen sie nutzen?

In der Praxis greifen dafür mehrere Ebenen ineinander:

• Ein zentraler Katalog für Agenten und Flows: Statt dass jedes Team eigene Agenten-Integrationen aufsetzt, bestimmt ein gemeinsamer AI Catalog, was veröffentlicht wird, abgestimmt auf die bestehenden Rollen und die Gruppenstruktur der Organisation.
• Composite Identity: Die Identität jedes KI-Agenten bleibt mit dem Menschen verknüpft, der die Aktion angefragt hat, damit Aktivität nie allein dem Agenten zugerechnet wird. Beim Zugriff auf eine Ressource müssen beide authentifiziert und autorisiert sein, der Agent und der Mensch hinter ihm.
• Tool-Approval-Guardrails: Einzelne Agenten-Tools laufen autonom, pausieren für ein menschliches Review oder bleiben ganz blockiert. Eine sensible Aktion wie das Schreiben einer Datei oder das Löschen einer Ressource wartet damit auf eine Freigabe, bevor sie ausgeführt wird.
• Prompt-Guardrails: Agenten verarbeiten auch nicht vertrauenswürdige Eingaben, etwa eine Webseite, einen Issue-Kommentar oder eine von Angreifenden kontrollierte Datei. Deshalb muss die Plattform Versuche erkennen, das Agentenverhalten mitten im Workflow zu kapern, und nicht erst im Nachhinein protokollieren.

Ziel ist eine Kontrollebene, die Agenten-Berechtigungen genauso behandelt wie längst die menschlichen: rollenbasiert, nachvollziehbar und über alle Projekte hinweg konsistent.

Drei Fragen zum Datenumgang, die vorab geklärt sein sollten

Quellcode zählt zu den sensibelsten Werten eines Unternehmens, und jede KI-Funktion, die ihn liest, wirft eine Frage zum Datenumgang auf. Vor einer breiten Einführung agentischer KI wollen Technik- und Sicherheitsverantwortliche deshalb meist drei Punkte geklärt haben:

• Trainiert der Anbieter Modelle mit unserem Code?
• Wem gehören Eingaben und Ausgaben?
• Wo sitzen die Subprozessoren, und gibt es eine Benachrichtigung, wenn sich diese Liste ändert?

In regulierten Branchen lautet die Antwort auf die dritte Frage oft: nirgends außerhalb der eigenen Infrastruktur. Damit wird Self-Hosting zum Governance-Hebel und nicht bloß zur Deployment-Vorliebe. Self-Hosting-Optionen erlauben es, KI-Agenten vollständig auf selbst kontrollierter Infrastruktur zu betreiben, die Nutzung im Team weiterhin genau zu erfassen und regulatorische Anforderungen zu erfüllen.

Bring-your-own-Model geht einen Schritt weiter. Intern bereits validierte Modelle lassen sich anbinden und einzelnen Agenten-Flows zuordnen. Ein sensibler Workflow bleibt so an ein Modell gebunden, dem die Organisation vertraut, während weniger sensible Abläufe eine verwaltete Option nutzen.

Wo Autonomie endet und Review beginnt

Governance heißt nicht, Agenten das autonome Handeln zu verwehren. Sie heißt, bewusst festzulegen, wo Autonomie endet und Review beginnt. Eine praktikable Richtlinie unterscheidet dazu zwei Modi:

• Interaktive Arbeit, bei der ein Mensch anwesend ist, jeden Vorschlag sieht und direkt entscheidet. Diesen Modus kennen die meisten Teams bereits aus der KI-Code-Vervollständigung.
• Automatisierte Arbeit im Hintergrund, etwa Agenten in CI/CD-Pipelines, die niemand in Echtzeit beobachtet. Hier findet das Review entweder vor der Aktion statt, über Tool-Approval-Guardrails, oder unmittelbar danach, über einen Audit-Trail, den ein Mensch prüfen kann.

Entscheidungspunkte, die es zu definieren gilt

Code-Review, Tests und Validierung sowie Deployment-Freigabe lassen sich über zwei Fragen bestimmen:

• Was davon kann ein Agent eigenständig erledigen?
• Was verlangt eine namentliche menschliche Freigabe, bevor die Änderung weitergeht?

Jeder Checkpoint braucht in der Praxis seinen eigenen Durchsetzungsmechanismus. Das kann so aussehen:

• Merge-Request-Approval-Policies legen fest, wer freigeben muss, bevor ein Merge Request landet, unabhängig davon, ob ein Agent oder ein Mensch ihn geöffnet hat.
• Tool-Approval-Guardrails entscheiden Tool für Tool, ob die Aktion eines Agenten autonom läuft, für ein Review pausiert oder blockiert bleibt.
• Scanner-Durchsetzung hält eine Änderung auf Pipeline-Ebene zurück, bis sie die geforderten Sicherheits- und Qualitätsprüfungen besteht.

Wir empfehlen eine organisationsweite KI-Governance-Richtlinie, statt die Regeln den Normen einzelner Teams zu überlassen. Das schafft konsistente Nutzung und erleichtert Auditoren die Prüfung des KI-Einsatzes.

Zusätzlicher Kontext aus der Entscheidungsebene

Diese Freigaben als strukturierte Datensätze festzuhalten, zahlt sich langfristig aus, denn in einem Chat-Thread oder im Gedächtnis einer prüfenden Person gehen sie verloren. Eine im letzten Quartal gewährte Ausnahme, die Richtlinienversion, unter der sie erteilt wurde, und wer sie freigegeben hat: Genau diese organisatorische Einschätzung müssen Auditoren wie künftige Agenten nachschlagen können.

Wer Entscheidungen als dauerhafte, abfragbare Ereignisse behandelt, gewinnt zusätzlich, dass die nächste Prüfung mit Kontext beginnt statt bei null, ob sie von einem Menschen oder einem Agenten kommt.

Mehr über die Entscheidungsebene und darüber, wie festgehaltene Entscheidungsereignisse die Softwareentwicklung prägen.

Fünf Metriken, die eine KI-Einführung messen

Fünf Kategorien lohnen sich von Anfang an, und zwar zusammen betrachtet statt isoliert: Ein Anstieg der Adoption ohne begleitenden Blick auf die Risiko-Metriken ist selbst schon ein Warnsignal.

1. Adoption: aktive Nutzende von KI-Funktionen Woche für Woche, Zahl der ausgeführten Flows oder Agenten und welche Teams agentische Funktionen aktiviert haben und welche nicht.
2. Akzeptanz und Qualität: nachgelagerte Signale wie die Revert-Rate bei KI-unterstützten Änderungen und wie oft KI-erstellte Merge Requests das Review ohne Nacharbeit bestehen. Eine einzelne Akzeptanzrate ist für sich ein schwacher Näherungswert, weil sie nichts darüber sagt, was mit dem Code nach der Annahme geschieht.
3. Risiko: wie oft Tool-Approval-Guardrails eine Aktion für ein Review pausieren, wie oft daraus eine blockierte oder geänderte Aktion wird und ob eine Agenten-Aktivität einen Policy-Verstoß auslöst.
4. Remediation: die Scanner-Abdeckung über Projekte hinweg, der Anteil automatisch behobener Schwachstellen gegenüber manuell triagierten und die Dauer bis zur Behebung markierter Findings.
5. ROI: Sobald die Daten eines vollen Quartals vorliegen, lohnt der Blick auf den ROI der KI-Investition. Dazu erfassen, wie viel Aufwand Entwickelnde bei Aufgaben sparen, die Agenten nun übernehmen, und das gegen die Kosten pro behobenem Issue oder gemergter Änderung abwägen, in Credits oder Compute. Ein ausführlicher Blick auf den KI-ROI zeigt, wie sich Rohdaten zur Nutzung in belastbare Geschäftserkenntnisse und ROI-Berechnungen überführen lassen.

Werden alle fünf Metriken gemeinsam verfolgt, fallen Probleme der Einführung früh auf. Eine Einführung kann bei Adoption und Akzeptanz erfolgreich aussehen und dabei Risiko anhäufen, das erst ein Audit ein halbes Jahr später zutage fördert. Erst zusammen ergeben die Metriken ein belastbares Bild vom Wert der KI für die Organisation.

Governance-Checkliste für die GitLab Duo Agent Platform

Für Teams, die auf die GitLab Duo Agent Platform standardisieren, dient diese Checkliste als Ausgangspunkt, bevor agentische KI über einen Pilotbetrieb hinaus ausgeweitet wird:

• Das AI Transparency Center durchgehen und das eigene Verständnis von Datennutzung, Modellanbietern und Subprozessor-Zusagen bestätigen.
• Auf Plattformebene entscheiden, welche Agenten und Flows freigegeben sind, und sie über GitLabs AI Catalog veröffentlichen, statt Teams eigene konfigurieren zu lassen.
• Tool-Approval-Guardrails je nach Sensibilität des Tools auf "immer erlauben", "immer nachfragen" oder "immer verweigern" setzen.
• Composite Identity einrichten, damit jede Agenten-Aktion mit dem Menschen verknüpft ist, der sie angefragt hat, und der Zugriff die Autorisierung beider verlangt.
• Für regulierte Workloads Self-Hosting-Deployment und Bring-your-own-Model-Optionen gegen die eigenen Anforderungen an den Datenstandort abwägen.
• Explizite Human-in-the-Loop-Checkpoints für Code-Review, Tests und Validierung sowie Deployment-Freigabe dokumentieren.
• Audit-Event-Streaming für Agenten-Aktivität aktivieren, sodass jede Aktion in demselben Audit-Trail landet, den die Organisation bereits prüft.
• Die Metriken der Einführung (Adoption, Akzeptanz, Risiko, Remediation, ROI) festlegen, bevor der Pilotbetrieb ausgeweitet wird, und sie gemeinsam in wiederkehrendem Rhythmus prüfen.

Die Checkliste in jedem Release-Zyklus erneut durchgehen: Governance für agentische KI ist keine einmalige Einrichtung. Neue Agenten, neue Tools und neue Modelle werfen die Fragen oft neu auf.

Wo agentische KI auf Enterprise-Kontrolle trifft

Agentische KI verändert, was zu steuern ist. Die Code-Vervollständigung fragte einen Menschen, ob ein Vorschlag gut ist. Agentische KI fragt, was ein Agent anfassen darf, wer es freigegeben hat und ob sich das später belegen lässt.

Diese Fragen vollständig zu beantworten verlangt Governance, die in der Plattform selbst steckt und nicht nachträglich darübergelegt wird. Die GitLab Duo Agent Platform stellt AI Catalog, Approval-Guardrails und Audit-Event-Streaming direkt dort bereit, wo die Arbeit stattfindet. Teams erhalten damit KI-Unterstützung und Enterprise-Kontrolle zugleich, weil die Guardrails Teil des Workflows sind und kein separater Prozess daneben.

Jetzt eine kostenlose Testversion der GitLab Duo Agent Platform starten. Im Free-Tier lässt sich in wenigen Schritten anmelden. Wer bereits GitLab Premium oder Ultimate nutzt, kann die Duo Agent Platform aktivieren und die im Abonnement enthaltenen GitLab Credits nutzen.

Der Brief vertritt die Auffassung, dass offene Modellgewichte Innovation fördern, Kunden mehr Kontrolle geben und einen wichtigen Weg zu Sicherheit und Schutz von KI eröffnen. Das ist nicht nur eine politische Position, die wir teilen, sondern zugleich zentral für unser Verständnis von agentischem Engineering: Teams leisten ihre beste Arbeit, wenn sie das für die Aufgabe passende Modell wählen können.

Als intelligente Orchestrierungsplattform für DevSecOps, die Tempo und Kontrolle im agentischen Software-Engineering verbindet, stellt GitLab die Wahlfreiheit der Kunden in den Vordergrund, orchestriert den Software-Lebenszyklus und unterstützt mehrere Modelle über den Workflow eines Teams hinweg.

Kunden befähigen, ihre KI-Modelle selbst zu wählen

In vielen Organisationen wächst das Interesse an einem geregelten Zugang zu erstklassigen Foundation- und Open-Weight-Modellen. GitLab unterstützt beide.

Foundation-Modelle führen oft bei der allgemeinen Leistungsfähigkeit, während Open-Weight-Modelle Vorteile bei der Kontrolle über Kosten, Deployment und Datenstandort bieten können. Unser Ziel ist es, Kunden dabei zu helfen, beide nach Bedarf zu kombinieren.

Eine der kritischsten Entscheidungen, die Führungskräfte treffen, ist der Schutz von Software und strategischem geistigem Eigentum vor Bedrohungen für Sicherheit, Vertraulichkeit und Wettbewerbsfähigkeit. Organisationen sollten nicht an eine einzige Cloud oder einen einzigen KI-Modellanbieter gebunden sein.

GitLab ist die einzige Plattform, die zugleich Cloud-neutral und KI-Modell-neutral ist. Diese Wahlfreiheit hält jedoch nur, solange der Modellmarkt offen bleibt. Open-Weight-Modelle geben Entwicklungsteams die Wahl, wo sie ihre KI-Modelle ausführen, bei Bedarf in air-gapped Umgebungen, und behalten dabei die Kontrolle über ihren Code.

Unsere Position

Wie die politischen Entscheidungsträger wollen auch wir ein sicheres, geschütztes KI-Ökosystem und sehen Offenheit als einen wichtigen Teil des Wegs dorthin. Wir unterstützen eine Politik, die die Fähigkeit erhält, Open-Weight-Modelle zu entwickeln, zu verbreiten und zu nutzen, unter der Voraussetzung fokussierter, risikobasierter Schutzmaßnahmen und gezielter Werkzeuge gegen tatsächlichen Missbrauch. Solche Eingriffe können einen wesentlichen Beitrag zu einem robusten Ökosystem leisten, in dem mehrere Modellanbieter, offene wie proprietäre, im Wettbewerb um die beste Lösung antreten, zum Nutzen von Innovation, Sicherheit und Wahlfreiheit der Kunden.

Weiterführende Links

• GitLab AI Transparency Center
• Gemeinsam KI absichern: GitLabs Partnerschaft mit Sicherheitsforschenden
• Warum Unabhängigkeit für Unternehmen im DevSecOps wichtiger ist denn je

Anthropics neuestes KI-Modell Claude Opus 5, jetzt auf der GitLab Duo Agent Platform verfügbar, ist für die Aufgaben gebaut, die einem Agenten am meisten abverlangen. Mit Opus 5 kann das Entwicklungsteam Agenten auch komplexere, kritische Arbeit anvertrauen. In GitLabs interner Evaluierung löste Opus 5 93,3 % der Benchmark-Aufgaben, eine Verbesserung um 20,3 Punkte gegenüber der Lösungsrate von 73,0 % bei Opus 4.8.

"Die Teams, die den größten Nutzen aus KI-Agenten ziehen, können ihre schwierigste, folgenreichste Arbeit übergeben und darauf vertrauen, dass das Reasoning vom ersten bis zum letzten Schritt trägt."

– Stuart Moncada, VP, AI Product Management, GitLab

Reasoning – auch bei Komplexität

Manche Teams zögern, ihre anspruchsvollste Arbeit an einen Agenten zu delegieren, weil sich Fehler nur aufwendig zurücknehmen lassen. Bei langlaufenden, hochkomplexen Aufgaben muss das Reasoning eines Agenten von Anfang bis Ende tragen. Mit dem tieferen Reasoning von Opus 5 werden mehr komplexe Aufgaben, etwa Features über mehrere Dateien und größere Refactorings, gleich beim ersten Mal korrekt gelöst, was das Diagnostizieren und erneute Prompten fehlgeschlagener Durchläufe reduziert. Teams, die die GitLab Duo Agent Platform mit Opus 5 nutzen, können mit weniger unvollständigen Patches rechnen und damit, dass mehr Arbeit merge-fertig zurückkommt.

Diese Verlässlichkeit erstreckt sich auch auf die Vollständigkeit. In GitLabs internen Tests schloss Opus 5 100 % der begonnenen Aufgaben ab und erreichte damit dieselbe Abschlussrate wie Opus 4.8. Der Unterschied liegt im Ergebnis: Mehr Lösungen von Opus 5 sind verifiziert korrekt, was die Lösungsrate von Opus 5 auf 93,3 % bringt, gegenüber 73,0 % bei Opus 4.8.

Eine Aufgabe in GitLabs Evaluierung verlangte mockbare SSO-Login-Unterstützung in einem CLI-Authentifizierungsablauf, eine Änderung über fünf Dateien hinweg, samt neuer exportierter Typen und Konfigurationsfelder. Mehrere andere getestete Modelle lieferten nicht einmal einen Lösungsversuch. Opus 5 baute die vollständige Implementierung, committete sie und öffnete einen Merge Request.

Dieselbe Präzision ist auch beim Code-Review zu erwarten. Opus 5 markiert echte Bugs und produziert wenige False Positives, sodass sich das Team auf echte Schwachstellen konzentrieren kann und weniger Rauschen filtern muss.

Laufen in einem Workload mehrere Agenten gleichzeitig, gibt es weniger Konflikte zwischen ihnen zu entwirren. Opus 5 hält Subagenten koordiniert und sorgt dafür, dass sie sich nicht in die Arbeit der anderen einmischen. Writer-Verifier-Muster fangen Probleme zwischen Agenten ab, bevor sie beim Team ankommen: Ein Agent prüft die Ausgabe eines anderen, bevor sie akzeptiert wird. Teams, die längere, autonomere Sessions mit mehr parallelen Agenten fahren, sehen die stärksten Ergebnisse.

Für kostensensible Workloads mit mehreren parallelen Agenten lassen sich mit Obergrenzen für den Verbrauch von GitLab Credits harte Ausgabenlimits setzen, sodass parallele Arbeit nie über das Budget hinausläuft.

Tempo auch bei den anspruchsvollsten Aufgaben

Bei den anspruchsvollsten Benchmark-Aufgaben von GitLab verbindet Opus 5 Verlässlichkeit mit Tempo. Im 95. Perzentil, dem langsameren Ende seiner Läufe, war Opus 5 2,2 % schneller als Opus 4.8 (768 Sekunden gegenüber 784,98 Sekunden) und 21,9 % schneller als Sonnet 4.6 (768 Sekunden gegenüber 982,57 Sekunden). Für das Team bedeutet das planbarere Durchlaufzeiten, auch bei den längsten Läufen.

Das passende Modell für die jeweilige Aufgabe

Das passende Modell hängt von der Aufgabe ab, die gerade ansteht, nicht von einer einzigen organisationsweiten Vorgabe. Sonnet-Modelle übernehmen den Großteil der täglichen Entwicklungsarbeit: schnell, günstig und verlässlich für das, was die meisten Teams ständig einsetzen. Zu Opus 5 greift man, wenn die Arbeit tieferes Reasoning verlangt: das schwierigste Debugging, die größten Refactorings, die Entscheidungen, die man nicht noch einmal überarbeiten möchte.

Diese Wahl lässt sich direkt in der eigenen GitLab-Instanz über die Modellauswahl treffen. Welches Modell auch gewählt wird, es läuft in derselben Infrastruktur: dem Kontext-Layer, den Policy-Checks und dem Audit-Trail, die jedes Modell auf der GitLab Duo Agent Platform abdecken.

Erste Schritte mit Opus 5

Claude Opus 5 ist ab sofort auf der GitLab Duo Agent Platform verfügbar und läuft wie andere Modelle über GitLab Credits. Neu bei der Duo Agent Platform? Jetzt eine kostenlose Testversion starten. Bereits GitLab Premium oder Ultimate abonniert? Die Duo Agent Platform aktivieren und die im Abonnement enthaltenen GitLab Credits nutzen.

"Java 8 auf Java 21 modernisieren" klingt nach einer einzigen Aufgabe, ist es aber nicht. Es betrifft den Build, die Runtime, Abhängigkeiten, APIs, Nebenläufigkeit, Tests, Container und das Produktionsverhalten, oft alles gleichzeitig. Wer einen Agenten bittet, das alles in einem einzigen Prompt zu erledigen, bekommt einen riesigen Merge Request, den niemand sicher reviewen kann.

Cursor, ein KI-Coding-Agent, ist im fokussierten Teil dieses Problems stark. Bekommt er einen einzelnen fehlschlagenden Test oder ein abgegrenztes Issue, kann er die Implementierung untersuchen, erklären, was schiefging, einen Fix vorschlagen und die Tests ausführen, ohne aus dem Entwicklungsfluss zu reißen. Was er nicht allein entscheiden kann, ist, was "sicher" über eine mehrstufige Migration hinweg bedeutet.

Genau hier kommt GitLab ins Spiel: Die Duo Agent Platform orchestriert KI-Workflows im übrigen Software-Lebenszyklus und ist darauf ausgelegt, die Arbeit von Coding-Agenten zu zertifizieren. Die Issue-Hierarchie mit Epics macht den Plan dauerhaft und reviewbar. Der GitLab-Model-Context-Protocol-Server (MCP) bringt den Kontext aus dem Entwicklungszyklus nach Cursor. CI/CD, Security-Scanning, Code-Review, Impact-Analyse und ein serviceübergreifender Test liefern die Belege, die es braucht, bevor sich das Produktionsverhalten ändert.

Der Nutzen steht damit fest: eine Migration, der ein Team vertrauen kann. Jede Änderung ist abgegrenzt, reviewt, gegen Java 8 und Java 21 getestet und bis zu einem Work Item mit den zugehörigen Entscheidungen und Belegen zurückverfolgbar. Cursor übernimmt die Implementierung, GitLab liefert den Nachweis. Eine bestehende Java-8-Codebasis wird nicht dadurch sicherer zu modernisieren, dass ein Agent den Code schreibt, sondern dadurch, dass jede Änderung abgegrenzt, reviewt, gegen beide Java-Versionen getestet und nachvollziehbar ist.

Angesprochen sind damit Teams, die auf einer bestehenden Java-8-Codebasis sitzen und agentisches Tempo nutzen wollen, ohne Governance, Review und Nachvollziehbarkeit aufzugeben. Cursor arbeitet schnell innerhalb einer abgegrenzten Aufgabe. Code Review Flow, Developer Flow, CI/CD, Code-Owner-Freigaben und Impact-Analyse sind das, was dieses Tempo sicher macht. Sie sind keine optionalen Kontrollpunkte, sondern der Mechanismus, der jeden von einem Agenten erzeugten Merge Request an denselben Maßstab hält wie jeden anderen.

Das Folgende ist die praktische Umsetzung: drei aufeinander aufbauende Use Cases, die zeigen, wie sich das Schritt für Schritt in Cursor und GitLab durchführen lässt.

1. Einen fehlschlagenden End-to-End-Test mit Cursor beheben
2. Quality-Gates zur Java-21-Modernisierung vorbereiten
3. Das HTTP-Connection-Handling mit Java 21 modernisieren

Die Reihenfolge hat einen Grund: klein anfangen, Projektkontext ergänzen, dann eine Grenze modernisieren.

Die Demo-Umgebung aus Java-Collector und Rust-Backend

Für alle drei Use Cases nutzen wir den Java HTTP Metrics Collector aus der Tanuki IoT Platform. Er prüft HTTP-Endpunkte, erfasst Metriken wie Antwortstatus und Timing und schickt die Messwerte an sein Rust-Metrics-Backend. Das gibt uns eine sichtbare Anwendungsgrenze zum Modernisieren und einen echten Backend-Vertrag zum Verifizieren. Das Rust-Backend haben wir vor einiger Zeit im Tutorial zu Codex und GitLab entwickelt, und es fügt sich nun in die Produktionsarchitektur ein:

flowchart LR
  subgraph sources["HTTP metric sources"]
    direction TB
    health["Health endpoint"]
    maintenance["Maintenance endpoint"]
  end

  java["Java HTTP metrics collector"]
  rust[("Rust metrics-store backend")]

  java -->|"GET"| health
  java -->|"GET"| maintenance
  java -->|"POST /api/metrics"| rust
  rust -->|"HTTP response"| java

  classDef source fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#0f172a
  classDef focus fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#0f172a
  classDef backend fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0f172a

  class health,maintenance source
  class java focus
  class rust backend

Voraussetzungen

1. Cursor installiert und konfiguriert. In diesem Tutorial nutzen wir die Cursor-IDE.
2. Ein GitLab-Projekt mit dem Quellcode des Java-Collectors, Issues und Modernisierungs-Work-Items. Nutzen lässt sich der Java HTTP Metrics Collector der Tanuki IoT Platform.
3. Java 8 für den ersten Use Case und Java 21 für die Modernisierungsarbeit
4. Maven, Docker und Docker Compose für lokale Builds und funktionale Tests
5. Der GitLab-MCP-Server, aktiviert auf der GitLab-Instanz oder der Top-Level-Gruppe
6. GitLab Duo Code Review Flow, Developer Flow und ein Custom Flow für die Impact-Analyse bei Breaking Changes (siehe Abschnitt "Tipps für Cursor und GitLab"), aktiviert für das Java-Collector-Projekt. Diese Flows wenden die Projekt-Guardrails auf jeden Merge Request an, den der Agent erstellt.

Das GitLab-Projekt vorbereiten

Um den Workflow in der eigenen Umgebung nachzuvollziehen, zunächst das Projekt importieren, klonen und in Cursor öffnen:

1. Den Java HTTP Metrics Collector der Tanuki IoT Platform in die eigene GitLab-Umgebung importieren, samt aller offenen Issues.
2. Das Projekt in die lokale Umgebung klonen und hineinwechseln.
3. Das Projekt in Cursor öffnen.

git clone https://gitlab.com/gitlab-da/demo-environments/tanuki-iot-platform/sensors/java-http-metrics-collector.git
cd java-http-metrics-collector

cursor .

Das Projekt enthält eine AGENTS.md-Datei mit Repository-Anweisungen und Maven-Befehlen. Cursor kann diese lokalen Anweisungen nutzen, um zu verstehen, wie das Projekt organisiert ist und wie Änderungen getestet werden sollen.

Einen fehlschlagenden End-to-End-Test mit Cursor beheben

Der Collector erlaubt es, den von einem Endpunkt erwarteten HTTP-Statuscode zu konfigurieren. Die Implementierung behandelt jedoch jede 2xx-Antwort als erfolgreich, und 503-Fehler schlugen immer fehl, selbst wenn sie als erwartet konfiguriert waren.

Der End-to-End-Test legt diese Diskrepanz bereits offen, aber der CI/CD-Job darf fehlschlagen. Das hat aus einem nützlichen Signal hingenommenes Hintergrundrauschen gemacht.

Mit Cursor reproduzieren und beheben

Das Problem lässt sich lokal reproduzieren. Die Cursor-IDE mit einem neuen Chat öffnen und damit beginnen, das beobachtbare Problem direkt im Prompt zu beschreiben:

Can you help me fix the end-to-end tests in this project? Please create an analysis first, then fix it, and run the tests again.

Cursor beginnt damit, die Endpunkt-Konfiguration in den HttpCollector und den fehlschlagenden End-to-End-Test zurückzuverfolgen, und identifiziert die Ursache.

Nachdem die fokussierten Tests und die vollständige Maven-Testsuite durchlaufen, einen Branch und Merge Request erstellen. Der zuvor auf "allowed to fail" gesetzte End-to-End-Job kann verpflichtend werden, sobald er deterministisch und grün ist.

Can you create a git branch and merge request?

Reviewen und mergen

Der Merge Request stößt automatisch CI/CD-Build und -Tests sowie Security-Scanning an.

GitLab Duo Code Review reviewt die fokussierte Änderung anschließend anhand der Java-spezifischen Review-Anweisungen des Projekts.

Wenn das Review ein konkretes Problem findet, adressieren wir es über den Developer Flow, bevor wir mergen. Das ist der Punkt: Der Code Review Flow stellt sicher, dass jeder von einem Agenten erzeugte Merge Request denselben Maßstab erfüllt wie jeder andere, unabhängig davon, wie schnell Cursor ihn erzeugt hat. Der Merge Request bleibt die Fläche für Zusammenarbeit und Entscheidung.

Der Fix gibt uns eine Verhaltens-Baseline. Wir haben einen echten Bug korrigiert, ohne ihn mit einer Runtime-Migration zu vermischen, und die Tests schützen jetzt den Vertrag über den erwarteten Status während der folgenden Modernisierungsarbeit.

In diesem Video wird gezeigt, wie Cursor die erwarteten End-to-End-Tests untersucht und behebt:

Quality-Gates zur Java-21-Modernisierung vorbereiten

Der erste Fix kam allein mit Repository-Kontext aus. Die nächste Anforderung ist deutlich größer: den Collector von Java 8 auf Java 21 modernisieren.

Diese Arbeit hat bereits Planungskontext im Epic zur Java-Modernisierung: untergeordnete Work Items, Team-Diskussionen, Recherche mit Merge Requests, Pipeline-Historie, Abhängigkeiten und Security-Findings. Diese Details liegen nicht im lokalen Checkout. Statt sie alle in einen riesigen Prompt zu kopieren, lässt sich der GitLab-Kontext mit MCP nach Cursor bringen.

Den GitLab-MCP-Server in Cursor konfigurieren

Zunächst sicherstellen, dass der GitLab-MCP-Server auf der Instanz oder der Top-Level-Gruppe aktiviert ist. Cursor nutzt HTTP-Transport, um sich ohne zusätzliche Abhängigkeiten direkt zu verbinden.

Um Cursor mit dem GitLab-MCP-Server zu verbinden:

1. In Cursor zu Settings > Cursor Settings > Tools & MCP gehen.
2. Unter Installed MCP Servers die Option New MCP Server wählen.
3. Die folgende Definition zum mcpServers-Schlüssel in der geöffneten mcp.json-Datei hinzufügen. Für GitLab.com <gitlab.example.com> durch gitlab.com ersetzen. Für GitLab Self-Managed oder Dedicated die eigene Instanz-URL verwenden.

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://<gitlab.example.com>/api/v4/mcp"
    }
  }
}

4. Die Datei speichern und warten, bis sich die OAuth-Autorisierungsseite im Browser öffnet. Öffnet sie sich nicht, Cursor schließen und neu starten.
5. Die Autorisierungsanfrage im Browser prüfen und bestätigen.
6. Zurück in Cursor die aufgelisteten Tools inspizieren.

Jetzt lässt sich ein neuer Chat starten und eine Frage auf Basis der verfügbaren GitLab-MCP-Tools stellen.

Wenn Cursor sich bei GitLab MCP authentifiziert, handelt es mit der bestehenden GitLab-Identität. Es kann nur auf Projekte und Ressourcen zugreifen, auf die man ohnehin schon Zugriff hat. MCP bringt freigegebenen Kontext in die IDE. Es umgeht keine GitLab-Berechtigungen.

Die Umgebung für die Java-21-Modernisierung vorbereiten

Das Epic zur Modernisierung von Java 8 auf 21 bricht den nötigen Plan in kleinere Iterationen herunter, wobei jedes Artefakt und jede Änderung für sich testbar ist.

Der erste Schritt ist sicherzustellen, dass die CI/CD-Infrastruktur sowohl Java 8 als auch 21 parallel testet. Auch die Testabdeckung von Beginn an in jede Modernisierungsaufgabe hinein zu erhöhen, ist verpflichtend.

Die Cursor-IDE öffnen und den folgenden Prompt nutzen, um den Planungskontext abzurufen:

Please help me modernize this sensor from Java 8 to 21. We want to start with the base line for CI/CD builds in work item 14, and then also look into test coverage from 21. Start the implementation in a new Git branch called `maint-java-21` so we can continue testing different scenarios.

Nach dem Abschluss der Arbeit am Issue zur Sichtbarkeit des CI-Builds kann Cursor mit dem MCP-Tool create_workitem_note zusätzlich einen zusammenfassenden Kommentar in das Issue einfügen.

Der neue Merge Request stößt CI/CD-Pipelines an sowie den Code Review Flow, der Kommentare zum Development-Style-Guide hinterlässt, in denen Dokumentation eingefordert wird.

Das Feedback lässt sich unmittelbar in der GitLab-Oberfläche adressieren, indem man den Service-Account des Developer Flow erwähnt.

@duo-developer-<group-name> Can you help address the review feedback?

Dieser Prompt startet eine neue Hintergrund-Session, und wir können uns währenddessen auf andere Aufgaben konzentrieren. Alternativ lässt sich zurück in die Cursor-IDE wechseln und deren Chat bitten, das Review-Feedback im Merge Request zu adressieren.

Cursor setzt die Änderungen um und fügt mit dem MCP-Tool create_merge_request_note Kommentare in die Merge-Request-Threads ein.

Die Änderung behält die temporäre Java-8-Baseline und ergänzt eine eigene Java-21-Build- und -Testvalidierung. Damit wird die Kompatibilität in der Pipeline sichtbar, bevor der Quellcode beginnt, Java-21-only-APIs zu nutzen. Sobald diese Quality-Gates existieren, ist jede weitere agentengetriebene Änderung reviewt, getestet und nachvollziehbar. Das ist derselbe Maßstab, den wir auf jeden anderen Merge Request anwenden, und er ist es, der es sicher macht, Cursor schnell arbeiten zu lassen.

In diesem Video wird gezeigt, wie Cursor GitLab MCP nutzt, um Quality-Gates vorzubereiten und Code-Review-Feedback zu adressieren:

Das HTTP-Connection-Handling mit Java 21 modernisieren

Der Java HTTP Metrics Collector nutzt derzeit die veraltete HttpURLConnection-API aus Java 8. Java 21 hat die HTTP-Bibliothek mit java.net.http.HttpClient modernisiert, aber das ist nicht bloß ein mechanisches Umbenennen. Redirects, eingeschränkte Header, Timeout-Geltungsbereich, Response-Bodies, Unterbrechung und Verbindungswiederverwendung können sich alle unterschiedlich verhalten. Deshalb liegt die Umsetzung in einem einzigen abgegrenzten Work Item: Replace HttpURLConnection with java.net.http.HttpClient. Setzen wir das in die Praxis um.

Die Cursor-IDE mit einem neuen Chat öffnen und um die Umsetzung der Änderungen bitten.

Hinweis: Für diesen Use Case wollen wir ein lokales Docker-Compose-Setup nutzen, um die Änderungen zu verifizieren. Wer das Verhalten nachvollziehen möchte, installiert Docker und Docker Compose, andernfalls den zweiten Prompt weglassen.

We want to continue modernizing the app to Java 21 - use the same maint-java-21 branch, and start implementing issue 16.

Verify the changes locally using the docker compose setup, after making the changes.

Der GitLab-MCP-Server liefert den Issue-Kontext, die Akzeptanzkriterien, Abhängigkeiten und zugehörigen Diskussionen. Das erste Code-Modernisierungs-Issue bleibt bewusst synchron und begrenzt. Es ersetzt HttpURLConnection durch einen einzigen wiederverwendbaren HttpClient und fügt keine Virtual Threads hinzu, ändert nicht das Zeitmodell und behebt keine unabhängigen Abhängigkeiten. Das sind wertvolle Folgeschritte, aber sie zu kombinieren würde es erschweren, Verhaltensänderungen zu isolieren, zu reviewen und zurückzurollen.

Lokal umsetzen und verifizieren

Fokussierte lokale HTTP-Server-Tests decken Methoden, Header, erwartete und unerwartete Statuscodes, Redirects, Timeouts, Response-Metadaten, Verbindungsfehler und Unterbrechung ab.

Der funktionale Test mit Docker Compose belegt anschließend, dass authentifizierte Messwerte weiterhin im rust-metrics-store-Backend ankommen.

Falls die CI/CD-Pipelines nach den Änderungen fehlschlagen, lassen sich die GitLab-MCP-Server-Tools nutzen, um direkt in der Cursor-IDE zu inspizieren und zu beheben, ohne den Kontext zu wechseln.

In der GitLab-Oberfläche lässt sich der Fix CI/CD Pipeline Flow nutzen oder der CI Expert Agent um Hilfe bitten.

CI/CD- und Review-Belege

GitLab CI/CD, GitLab Duo Code Review, Security-Scanning und KI-gestützte Impact-Analyse liefern die abschließenden Belege im Merge Request. Menschliches Review zählt an den subtilen Grenzen weiterhin am meisten: Jeder beabsichtigte Verhaltensunterschied sollte im Merge Request explizit sein, nicht erst nach dem Deployment entdeckt werden.

In diesem Video wird gezeigt, wie Cursor und GitLab die HTTP-Bibliothek des Collectors auf Java 21 modernisieren:

Tipps für Cursor und GitLab

Hier einige Tipps, um Cursor und GitLab zusammen zu nutzen.

Impact-Analyse für Breaking Changes bei der Modernisierung automatisieren

Der dritte Use Case zeigt den Developer Flow bei einer Impact-Analyse für Breaking Changes. Dieser Workflow lässt sich in einen automatisierten Custom Flow überführen, der ausgelöst wird, sobald ein Merge Request bereit ist oder die Pipeline in Ordnung ist. Zusätzlicher Kontext lässt sich aus GitLab Orbit abrufen, das einen Kontextgraphen über Code, Work Items, Merge Requests, Schwachstellen und mehr bereitstellt.

Der Beispiel-Flow lässt sich im AI Catalog inspizieren: MR Impact analysis (Orbit). Dank an meine Kollegin Fatima Sarah Kalid für die Inspiration. Custom Flows sind allgemein verfügbar in GitLab 19.2.

Richtlinien und Grenzen für Agenten dokumentieren

AGENTS.md für Java

Eine AGENTS.md-Datei hilft Cursor und anderen Coding-Agenten, die Projektarchitektur, Befehle, den Code-Stil, Testerwartungen und Grenzen zu verstehen. Diese Anweisungen nah am Code halten und konkret genug, um sie zu verifizieren.

Beispiel aus der AGENTS.md im Java-HTTP-Metrics-Collector-Projekt.

# Java HTTP Metrics Collector - Agent Instructions

## Overview

The Java HTTP Metrics Collector is a REST API metrics collection sensor for the Tanuki IoT Platform. It monitors HTTP endpoints, collects performance metrics (response time, status codes, content length), and exports them in Prometheus text format. The application runs continuously with configurable collection intervals and supports concurrent endpoint monitoring.

## Code Style and Standards

### Java 8 Compatibility

- Do not modernize Java 8 code to Java 11+ features unless there is a GitLab issue or task specifically requesting modernization
- Target Java 8 for source and compilation: `maven.compiler.source=1.8` and `maven.compiler.target=1.8`
- Use Java 8 compatible patterns (e.g., anonymous inner classes instead of lambdas where appropriate)

### Documentation

- All public classes must have Javadoc describing purpose and usage
- All public methods must have Javadoc with `@param` and `@return` tags
- Include code examples in main class Javadoc

### Class Organization

- **Main entry point**: `HttpMetricsCollector` - orchestrates configuration loading, metric collection, and export
- **Collector**: `HttpCollector` - performs HTTP requests and collects metrics
- **Exporter**: `PrometheusExporter` - exports metrics in Prometheus text format
- **Models**: `CollectorConfig`, `EndpointConfig`, `HttpMetric` - data transfer objects

### Dependency Management

- Always use Maven for dependency management
- Use property-based version management for dependencies (e.g., `${jackson.version}`)
- Keep dependencies up-to-date in `pom.xml`

### Error Handling

- Use try-catch blocks with proper resource management (try-with-resources where applicable)
- Log errors using SLF4J Logger
- Gracefully handle configuration loading failures
- Implement proper shutdown hooks for resource cleanup

### Concurrency

- Use `ExecutorService` for concurrent HTTP requests
- Thread pool size is limited to the minimum of endpoint count and 10
- Properly shutdown executor service with timeout handling
- Use `Future` objects to collect results from concurrent tasks

Code-Review-Anweisungen für Java

Der GitLab Duo Code Review Flow hilft, Style-Guides und Grenzen einzuhalten. Er erwartet spezifische Anweisungen in der Datei .gitlab/duo/mr-review-instructions.yaml, zum Beispiel für Java:

# Custom instructions for GitLab Duo Code Review

instructions:
  # General guidelines

  - name: Code Review
    instructions: |
      1. Focus on correctness and performance
      2. Ensure code comments and documentation are clear and concise
      3. Be respectful and constructive in comments

  - name: CI/CD Configuration
    fileFilters:
      - ".gitlab-ci.yml"
    instructions: |
      1. Do not use YAML anchors
      2. Always use rules in jobs, avoid using `only`

  # Java style guide

  - name: Java Style Guide
    fileFilters:
      - "**/*.java"
    instructions: |
      1. Do not modernize Java 8 code to Java 11+ features, unless there is a GitLab issue or task specifically requesting modernization
      2. All public classes must have Javadoc describing purpose and usage
      3. All public methods must have Javadoc with @param and @return tags
      4. Include code examples in main class Javadoc
      5. All public methods must have at least one test case
      6. Use httpbun.com for test endpoints (status codes, delays, JSON responses)

Im Zuge der Code-Modernisierung wird die erste Richtlinie mit der Java-8-Durchsetzung aktualisiert werden müssen.

Einen bewährten Workflow in eine agentische Skill überführen

Wenn ein spezialisierter Workflow wiederholbar wird, lässt er sich in einer agentischen Skill festhalten. Skills werden bei Bedarf geladen und belegen das Kontextfenster nicht standardmäßig.

Mit funktionierendem CI/CD, Tests und reviewten Entscheidungen beginnen, damit die agentische Skill bewährte Praxis widerspiegelt und keinen ungetesteten Plan. Issue 24 im Modernisierungs-Epic hält den Ansatz in einer fokussierten agentischen Skill für die Java-21+-Modernisierung fest. Das schafft Mehrwert über den aktuellen Merge Request hinaus: Künftige Agenten-Sessions können dieselben Sicherheitsgrenzen wiederverwenden, statt sie aus früheren Diskussionen zu rekonstruieren.

Diese Beispiel-Implementierung einer Skill lässt sich ausprobieren, inspiriert von der bestehenden Java-8-Maven-Maintenance-Skill:

---
name: java21-modernization
description: >-
  Guide incremental Java 8 to Java 21+ modernization for the HTTP metrics
  collector. Use when a GitLab work item asks for Java 21 CI visibility,
  runtime/image upgrades, HttpClient migration, dependency or source API
  modernization, or review of maint-java-21 style merge requests. Do not use
  for routine Java 8 maintenance; prefer java8-maven-maintenance instead.
compatibility: Requires Maven, Docker Compose, and access to the owning GitLab work item.
---

# Java 21 Modernization

## Overview

Modernize in small, reviewable steps. The owning work item is authoritative.
Preserve collector → Rust metrics-store behavior unless the issue says otherwise.

Companion skill: `skills/java8-maven-maintenance/` for the Java 8 default path.

## Before editing

1. Read the owning issue/epic, `AGENTS.md`, `.gitlab-ci.yml`, `pom.xml`,
   `Dockerfile`, and affected tests.
2. Record the current baseline:
   - `maven.compiler.source` / `target`
   - default CI image vs any `*:java-21` jobs
   - container base image
   - observable CLI/Compose behavior
3. Classify the change into **one** lane:
   - CI visibility only
   - runtime / image switch
   - source / API modernization
   - dependency upgrade
   - tests / contract checks

Do not combine lanes in one MR unless the work item explicitly requires it.

## Workflow

Copy and track:

```text
Modernization progress:
- [ ] Baseline recorded
- [ ] Scoped to owning work item
- [ ] Target-JDK CI evidence available before JDK-only APIs
- [ ] Java 8 lane preserved until exit criteria say otherwise
- [ ] Unit / IT / Compose checks run
- [ ] MR documents risks, rollback, human decisions
```

## Guardrails

- Do not remove Java 8 compatibility unless the work item authorizes it.
- Do not introduce Java 21-only APIs before target-JDK CI evidence exists.
- Do not mix runtime upgrades with unrelated refactors.
- Do not claim performance wins without measurements.
- Preserve the Java → Rust API and authentication contract.
- Stop for a human decision when support policy, rollback, data format, or downstream compatibility is unclear.

## Validation

```bash
mvn -Dmaven.repo.local=.m2/repository test
mvn -Dmaven.repo.local=.m2/repository clean package
```

If Compose or container files change:

```bash
docker compose config --quiet
TANUKI_INGESTION_TOKEN=replace-me docker compose up -d --build
# confirm metric_sample logs and authenticated ingest still work
docker compose down -v
```

## Completion report

In the MR description, include:

1. Baseline before the change
2. Lane changed (CI / runtime / source / deps / tests)
3. Evidence run (commands + CI jobs)
4. Remaining risks and rollback
5. Human decisions still open

## Out of scope

- Broad "modernize everything to Java 21" prompts
- HTTP endpoint semantics unrelated to the JDK migration
  (use `skills/http-endpoint-collector-behavior/`)
- Security triage unrelated to the migration slice
  (use `skills/security-triage-java-sensor/`)

Fazit

Die drei Use Cases in diesem Tutorial bauen aufeinander auf. Cursor hat allein mit Repository-Kontext einen hingenommenen End-to-End-Testfehler behoben. Dann brachte der GitLab-MCP-Server den Modernisierungsplan herein, sodass Cursor Quality-Gates einziehen und die Schleife beim Duo-Review-Feedback direkt aus der IDE schließen konnte. Schließlich nahm Cursor eine einzige abgegrenzte Java-21-Änderung vor und ersetzte HttpURLConnection durch einen wiederverwendbaren HttpClient, abgesichert durch fokussierte Tests, serviceübergreifende Ingestion-Läufe, Pipeline, Security-Scans, eine Software Bill of Materials, Review-Belege und Impact-Analyse.

Eine Legacy-Java-8-Codebasis wird nicht dadurch sicherer zu modernisieren, dass ein Agent den Code schreibt. Sie wird sicherer, weil jede Änderung abgegrenzt, reviewt, gegen Java 8 und Java 21 getestet und bis zu einem Work Item mit den Entscheidungen und Belegen dahinter nachvollziehbar ist. Cursor übernimmt die Implementierung. GitLab liefert den Nachweis. Zusammen machen sie die Migration zu etwas, dem ein Team vertrauen kann.

Wer diesen Workflow ausprobieren möchte, beginnt mit einem Test, der einen hingenommenen Fehler in einer Legacy-Anwendung offenlegt. Diesen Test verlässlich machen, den größeren Modernisierungsplan in GitLab festhalten und eine Grenze wählen, die sich unabhängig ändern und belegen lässt. Das gibt dem Agenten eine fokussierte Aufgabe und dem Team Belege, die es reviewen kann.

Wer die GitLab Duo Agent Platform heute noch nicht nutzt, kann mit einer kostenlosen Testversion beginnen.

Wer GitLab bereits im Free-Tier nutzt, kann sich für die GitLab Duo Agent Platform anmelden, indem er einigen wenigen Schritten folgt.

Und wer bereits GitLab Premium oder Ultimate abonniert hat, kann direkt loslegen, indem er die Duo Agent Platform aktiviert und die enthaltenen GitLab Credits aus dem Abonnement nutzt.

Gleichzeitig eröffnen sich durch Automatisierung, künstliche Intelligenz und moderne Services neue Möglichkeiten, die vor wenigen Jahren noch undenkbar waren. Unternehmen sollten zunächst ihre bestehenden Strukturen analysieren, um geeignete Lösungen gezielt in ihre DevOps-Prozesse zu integrieren. Wer diese Hebel strategisch einsetzt, kann messbare Produktivitätssteigerungen und Kostensenkungen erzielen.

Die gute Nachricht: DevOps-Kosten zu senken und gleichzeitig die Innovationskraft zu stärken, schließt sich nicht aus. In diesem Beitrag zeigen wir dir sechs konkrete Hebel, mit denen du dein DevOps-Budget entlastest und langfristig sparen kannst: von einer besseren Auslastung über die Konsolidierung der Toolchain bis hin zu agentischer KI.

Wie lassen sich DevOps Kosten effizient senken?

DevOps-Kosten nachhaltig zu senken erfordert das Zusammenspiel technischer, organisatorischer und strategischer Maßnahmen. Entscheidend ist, Ressourcen bedarfsgerecht einzusetzen, unnötige Redundanzen zu vermeiden, wiederkehrende Aufgaben zu automatisieren und die richtigen Tools intelligent zu bündeln. Die folgenden sechs Bereiche bieten das größte Potenzial für mehr Effizienz und langfristige Kosteneinsparungen.

Schone deinen Geldbeutel und deine Nerven!

Eine All-in-One-Plattform vermindert Reibungsverluste, administrativen Overhead und sorgt für mehr Produktivität!

Jetzt kostenlos testen

1. Cloud-Nutzung optimieren

Die Flexibilität der Cloud hat einen Preis: Ohne aktive Steuerung wachsen die Kosten schnell unkontrolliert. Wildwuchs entsteht, wenn Instanzen eingerichtet und vergessen werden, Speicherressourcen ungenutzt mitlaufen oder SaaS-Lizenzen bezahlt, aber nicht verwendet werden. Denn die entsprechenden Kosten umfassen weit mehr als reine Rechenleistung: Speicher, Netzwerkverkehr, Überwachung und Backups summieren sich oft unbemerkt.

Drei Maßnahmen helfen dabei, die Nutzung kontinuierlich zu überprüfen und unmittelbar Kosten einsparen zu können:

• Rightsizing bedeutet, die tatsächlich benötigten Kapazitäten regelmäßig mit den gebuchten Umgebungen abzugleichen. Überdimensionierte Instanzen, die dauerhaft nur einen Bruchteil ihrer Leistung nutzen, sind ein häufiger Kostentreiber.
• Autoscaling passt die verfügbare Rechenleistung dynamisch an die aktuelle Nachfrage an. So können Unternehmen Lastspitzen abfangen, ohne in ruhigen Zeiten unnötige Kapazitäten bereitzuhalten.
• Reservierte Instanzen lohnen sich für planbare Workloads: Wer sich langfristig bindet, zahlt deutlich weniger als im On-Demand-Modell.

2. CI/CD Pipelines automatisieren

Manuelle Schritte in einer CI/CD-Pipeline sind nicht nur fehleranfällig und kosten vor allem Zeit. Jedes händische Deployment, jeder separat gestartete Test und jede manuell vorgenommene Konfigurationsanpassung führt zu einer Verzögerung im Entwicklungszyklus und bindet wertvolle Kompetenz.

Hier setzt KI-gestützte Automatisierung an. Der DevSecOps Report zeigt: 68 % der befragten DevSecOps-Fachkräfte in Deutschland setzen KI bereits im Software Development Lifecycle ein. Bei weiteren 17 % steht die Einführung im Jahr 2026 an. Die größten Effizienzgewinne entstehen dabei durch die Automatisierung repetitiver Aufgaben (41 %), die KI-gestützte Unterstützung bei Tests und Qualitätssicherung (39 %) sowie die automatische Erkennung von Bugs (38 %).

Dabei beschleunigt sich die Entwicklung rasant: 98 % der befragten DevSecOps-Fachkräfte geben an, dass ihnen KI-Tools bereits Effizienzgewinne gebracht haben. Wer CI/CD Pipelines heute noch vollständig manuell betreibt, verschenkt damit nicht nur Zeit, sondern auch einen zunehmend relevanten Wettbewerbsvorteil.

Neben der Automatisierung aktiver Prozesse lohnt sich auch ein Blick auf passive Kosten: Ungenutzte Testumgebungen, die dauerhaft laufen, verursachen erhebliche Leerlaufkosten. Automatisches Herunterfahren nach definierten Inaktivitätszeiträumen oder zeitbasierte Löschregeln schaffen hier schnell Abhilfe – oft mit überraschend großem Effekt auf das Gesamtbudget. Entscheidend ist, dass die gesamte DevOps Pipeline von Anfang an auf Automatisierung ausgelegt ist, damit manuelle Eingriffe gar nicht erst zur Gewohnheit werden.

3. Toolchain konsolidieren

Tool-Fragmentierung gehört zu den größten versteckten Kostentreibern im DevOps-Umfeld. Wenn Teams für Planung, Versionierung, CI/CD, Security-Scans und Monitoring jeweils eigene Lösungen einsetzen, entstehen Lizenzkosten, Integrationsaufwand und Reibungsverluste an jeder Schnittstelle. Laut dem globalen DevSecOps Report nutzen 60 % der Unternehmen mehr als fünf verschiedene Tools in der Softwareentwicklung. Bei KI-Tools sind es sogar 49 %, die mehr als fünf im Einsatz haben.

Redundanzen lassen sich am einfachsten identifizieren, indem du den gesamten Tool-Stack einmal systematisch erfasst und gezielt auf DevOps Automation setzt, um wiederkehrende Integrations- und Wartungsaufgaben zu eliminieren. Der GitLab Toolchain-Rechner bietet eine schnelle Möglichkeit, die tatsächlichen Kosten deiner aktuellen Toolchain sichtbar zu machen.

Die konsequenteste Form der Konsolidierung ist die Umstellung auf eine All-in-One-Plattform, die den gesamten DevSecOps-Lebenszyklus abdeckt: von der Planung über die Entwicklung und das Testen bis zum Deployment und Monitoring. Statt mehrere Einzellösungen zu verwalten, zu lizenzieren und über Schnittstellen miteinander zu verbinden, arbeiten alle Teams auf einer gemeinsamen Basis. Das reduziert nicht nur die direkten Lizenzkosten, sondern eliminiert auch den erheblichen Integrationsaufwand, der bei jeder Toolchain mit mehreren Anbietern anfällt.

DevOps zentralisieren und effizienter entwickeln!

Starte jetzt deine 30-tägige Testversion und entfessle das volle Potenzial deiner Entwickler(innen) mit einer zentralen Plattform für die gesamte Softwareentwicklung!

Jetzt kostenlos testen

4. Architektur modernisieren

Eine alternde Infrastruktur verschlingt Budget: nicht nur für den direkten Unterhalt, sondern auch für die zunehmend schwierige Wartung. Legacy-Systeme erfordern spezialisiertes Know-how, das auf dem Arbeitsmarkt immer knapper wird, und verhindern gleichzeitig die Integration moderner DevOps-Praktiken. Im Laufe der Zeit wachsen diese versteckten Kosten enorm: von zusätzlichen Ressourcen für die Pflege bis hin zu Produktivitätsverlusten, die Investitionen in langfristiges Wachstum blockieren.

Cloud-native Konzepte wie Container-Orchestrierung, Microservices und Infrastructure as Code senken den internen Wartungsaufwand erheblich. Sie ermöglichen schnellere Deployments, eine bessere Skalierbarkeit und weniger Abhängigkeit von einzelnen Expert(inn)en.

Die Transformation einer gewachsenen Systemlandschaft muss dabei nicht auf einmal erfolgen. Eine schrittweise Implementierung reduziert technische Risiken und ermöglicht es, zunächst einzelne Komponenten oder eine besonders wartungsintensive Anwendung zu modernisieren.

Ein zukunftssicher aufgestellter DevOps-Stack schafft gleichzeitig die technische Basis, um Automation und KI-gestützte Workflows effektiv zu implementieren. Die Modernisierung der Architektur ist damit kein Selbstzweck, sondern eine Voraussetzung für nachhaltige Kostenreduktion in allen anderen Bereichen.

Erfahre, wie Siemens mit GitLab eine Open-Source-DevOps-Kultur geschaffen hat, die über 6,4 Mio. Builds pro Monat umsetzt.

"Wir bemühen uns sehr, eine Open-Source-Kultur einzuführen, und bisher waren wir wirklich erfolgreich. Mit CI/CD haben wir jeden Monat 1,5 Millionen Builds erstellt. Die ganze Kultur hat sich völlig verändert." — Fabio Huser, Softwarearchitekt bei Siemens Smart Infrastructure

5. Prozesse konsolidieren

Technik allein löst das Kostenproblem nicht. Oft sind es organisatorische Ineffizienzen, die den größten Anteil am verschwendeten Budget ausmachen. Der DevSecOps Report zeichnet ein deutliches Bild: DevSecOps-Fachkräfte in Deutschland verbringen im Schnitt nur 16 % ihrer Arbeitszeit mit dem Schreiben von neuem Code. Meetings und administrative Aufgaben machen mit 18 % den größten Einzelposten aus, gefolgt von Security-Arbeit (13 %), der Verbesserung bestehenden Codes (12 %) und Tests (12 %).

Als wichtigste Faktoren, die die Zusammenarbeit im Software Development Lifecycle einschränken, nennen 32 % der Befragten organisatorische Silos und veraltete Dokumentationen. Fehlender Wissensaustausch (30 %) und unklare Prozesse oder Tool-Fragmentierung (jeweils 29 %) verschärfen das Problem zusätzlich.

Kostenreduktion beginnt hier mit dem konsequenten Aufbrechen von Silos: gemeinsame Plattformen statt isolierter Teamwerkzeuge, standardisierte Review-Prozesse statt Ad-hoc-Abstimmungen, automatisierte Compliance statt manueller Audits. Gerade im Bereich Compliance investieren DevSecOps-Teams laut der Studie durchschnittlich elf Stunden pro Monat. Dazu kommen weitere zehn Stunden für die Behebung von Sicherheitsproblemen nach dem Release. Hier liegt enormes Einsparpotenzial: 77 % der Befragten erwarten, dass sich bis 2027 "Compliance as Code" etabliert, bei dem Vorgaben automatisiert im Entwicklungsprozess verankert sind.

Jede Stunde, die nicht in Abstimmungsschleifen oder manuelle Prüfungen fließt, steht für produktive Entwicklungsarbeit zur Verfügung und das wirkt sich unmittelbar auf die DevOps-Kosten aus.

6. Agentic AI etablieren

Auf Automatisierung, Konsolidierung und optimierten Prozessen kann agentische KI gezielt aufbauen und die Weiterentwicklung vorantreiben. Sie erweitert klassische Automatisierungsansätze, indem sie nicht nur einzelne Aufgaben ausführt, sondern komplexe, mehrstufige Workflows eigenständig übernimmt: von der Code-Generierung über automatisierte Reviews bis hin zur Sicherheitsanalyse.

Die Zahlen unterstreichen das Potenzial: Laut der Software Innovation Study von GitLab berichten Unternehmen, die KI in der Softwareentwicklung einsetzen, bereits von einem durchschnittlichen Umsatzwachstum von 43 % und einer Produktivitätssteigerung von 46 %. 89 % der deutschen Führungskräfte erwarten, dass agentische KI innerhalb von drei Jahren zum Standard in der Softwareentwicklung wird.

Entscheidend ist dabei nicht der bloße Einsatz einzelner KI-Tools, sondern ihre strategische Integration in den gesamten Entwicklungsprozess. Denn auch bei KI droht Tool-Wildwuchs: Bereits 49 % der Unternehmen nutzen mehr als fünf verschiedene KI-Tools parallel – mit den gleichen Integrations- und Wartungsproblemen, die auch bei klassischen DevOps-Tools auftreten.

Eine Plattform, die agentische KI nativ einbettet, vermeidet diesen Wildwuchs isolierter Insellösungen und schafft stattdessen durchgängige Effizienzgewinne über alle Phasen des Software Development Lifecycle: von der automatisierten Code-Generierung über intelligente Security-Scans bis hin zur vorausschauenden Fehlererkennung. Einen praxisnahen Einblick in die Möglichkeiten agentischer KI für DevOps bietet unser Webinar zu Agentic AI.

Nutze das volle Potenzial agentischer KI mit der GitLab Duo Agent Plattform!

Automatisiere komplexe DevOps-Workflows, steigere die Produktivität deiner Teams und beschleunige die Softwareentwicklung mit agentischer KI.

Jetzt kostenlos testen

Fazit: DevOps gezielt verbessern und nachhaltig sparen

Wer seine DevOps-Kosten reduzieren möchte, sollte nicht nur einzelne Lizenzpreise betrachten. Die größten Hebel liegen in einer besseren Ressourcennutzung, automatisierten Pipelines, einer konsolidierten Toolchain, moderner Architektur, klaren Zuständigkeiten und sinnvoll eingebundener KI.

Unternehmen, die ihre Entwicklungsstrukturen regelmäßig überprüfen und verbessern, können ihre Entwicklungszyklen verkürzen, Ausgaben minimieren und langfristig sparen. Entscheidend ist, technische und organisatorische Maßnahmen gemeinsam zu betrachten.

Das Video zeigt, wie der Flow startet, routet und zuweist – und was durchgängige, automatische Abläufe für eigene Projekte leisten können.

Warum manuelle Zuweisung nicht mitwächst

Arbeit manuell über Projekte hinweg zuzuweisen, ist anspruchsvoller, als es wirkt. Es ist nicht eine einzelne Entscheidung, sondern Dutzende, Tag für Tag. Für jedes neue Issue muss jemand innehalten, die Kapazität des Teams prüfen, die aktuelle Auslastung gegen eingehende Aufgaben abwägen und dann entscheiden, wohin das Item gehört. Kommen Meetings, Pausen oder Urlaub hinzu, zieht sich der Vorgang weiter. In kleinem Maßstab funktioniert das, mit wachsendem Volumen bricht es jedoch zusammen: verzögerte Triage, ungleich verteilte Arbeit und Team-Leads, die ihre Zeit ins Routing stecken statt in wertvollere Aufgaben.

Bislang war diese Reibung fest in der Funktionsweise der Flows verankert. Jeder GitLab Duo Flow benötigte eine Aktion im UI – etwa eine Mention, eine Zuweisung oder ein Assign-Reviewer-Event –, um zu starten. Flows programmatisch anzustoßen oder sie auszulösen, sobald etwas geschah, war ohne manuelles Eingreifen nicht möglich. Selbst ein gut gebauter Zuweisungs-Flow wartete also auf eine Person, die ihn in Gang setzte.

Was der Trigger "Work item created" verändert

Der Trigger "Work item created" schließt diese Lücke. Er löst automatisch aus, sobald ein neues Work Item in einem Projekt entsteht, ganz ohne manuelle Übergabe. Statt dass eine Person das Issue bemerkt, die Auslastung des Teams einschätzt und zuweist, wird ein Flow von selbst aktiv und übernimmt das Routing. Mit Triggern laufen Flows, sobald die von der jeweiligen Organisation definierten Bedingungen erfüllt sind – fortlaufend, im Hintergrund –, während die Entwicklungsteams sich auf die Arbeit konzentrieren, die tatsächlich Urteilsvermögen erfordert. Der Trigger "Work item created" ist dabei nur einer von vielen: Als Auslöser steht eine Reihe von Ereignistypen zur Auswahl, und jeder davon kann jeden im Projekt aktivierten Agenten oder Flow anstoßen – Spielraum genug, um Agenten schrittweise in die eigenen Abläufe einzubinden.

Was Teams davon haben

Triage ohne Handgriff. Zuweisung und Routing geschehen, sobald ein Work Item entsteht, nicht erst, wenn jemand dazu kommt.

Skaliert mit jedem Volumen. Ob ein einzelnes Issue oder Hunderte – der Trigger verarbeitet sie alle, ohne jemanden zusätzlich zu belasten.

Ausgewogene Zuweisung. Der Flow kann Auslastung und Verfügbarkeit jedes Teammitglieds abwägen, bevor er zuweist – dasselbe Urteilsvermögen, das eine Person anlegen würde, nur konsistent angewendet.

Befreit das Team von Fleißarbeit. Kein manuelles Durchsehen offener Work Items mehr, um zu entscheiden, wer Kapazität hat – ein Agent trifft die Entscheidung mit denselben Informationen, die auch eine Person hätte.

Automatische Zuweisung Schritt für Schritt

Ein konkretes Szenario im Projekt Intra-account-transfers macht das greifbar.

1. Der Flow "Work item assigner" ist angelegt und für neue Work Items im Projekt aktiviert

2. Wie der Flow aufgebaut ist

Der Flow "Work item assigner" nutzt zwei Agenten, jeder mit einem eigenen, detaillierten Prompt, der den Ablauf und die einzusetzenden Tools vorgibt. Der erste Agent ermittelt über GitLab Orbit die aktuelle Auslastung jeder Ressource in der Organisation. GitLab Orbit ist der Lifecycle-Kontextgraph für die Softwareentwicklung, der KI-Agenten in der Duo Agent Platform präziser macht.

Der zweite Agent ermittelt die Person mit den wenigsten offenen Work Items und weist ihr das neue Item zu.

Da die Zuweisungslogik im Flow selbst steckt, genügt der Trigger, um den gesamten Ablauf in Gang zu setzen.

3. Wie der Trigger auslöst

3.1. Ein brandneues Work Item wird erstellt.

3.2. Sobald das Issue entsteht, löst der Trigger aus, und der Flow "Work item assigner" startet von selbst. Das Aktivitätsprotokoll des Flows macht den Ablauf Schritt für Schritt nachvollziehbar: Der erste Agent ruft die Projektinformationen ab und zählt mit den GitLab-Orbit-Tools die offenen Work Items jeder Person in der obersten Gruppe.

Der zweite Agent ermittelt anschließend das am wenigsten ausgelastete Teammitglied – in der Demo ist das William – und führt die Zuweisung aus.

4. Prüfen, ob das Issue der am wenigsten ausgelasteten Person zugewiesen wurde

Ein Blick zurück auf das Issue bestätigt es: Das neue Work Item wurde automatisch William zugewiesen.

5. Der Nutzen über den gesamten Ablauf

Das Szenario führt vor allem eines vor Augen: die Verschiebung, wer die Arbeit erledigt. Statt dass eine Person offene Work Items durchsieht, um herauszufinden, wer Kapazität hat, und das Issue dann von Hand zuweist, übernimmt der Custom Flow der GitLab Duo Agent Platform, ausgelöst durch den Trigger "Work item created", all das von selbst. Es nimmt dem Team eine Routineentscheidung ab, die ein Agent mit genau denselben Informationen treffen kann wie ein Mensch – so bleibt die Aufmerksamkeit für das frei, worauf es ankommt.

6. Zum Weiterdenken

Mögliche Erweiterungen dieses Custom Flows:

• Eine Anbindung per Model Context Protocol (MCP) an das HR- oder Urlaubssystem, damit der Agent bei der Zuweisung die Urlaubszeiten der Ressourcen berücksichtigen kann.
• Eine MCP-Anbindung an die Kalender der Ressourcen, damit der Agent bei der Zuweisung die Verfügbarkeit berücksichtigen kann.

Loslegen

Eingehende Arbeit im großen Maßstab zuzuweisen, war immer eine stille Belastung: Dutzende kleiner Entscheidungen am Tag, jede mit der Prüfung von Auslastung und Verfügbarkeit, bevor ein Issue geroutet wird – ein Vorgang, der mit wachsendem Volumen zusammenbricht. Der Trigger "Work item created" in der GitLab Duo Agent Platform beseitigt diesen Engpass, indem er einen Flow auslöst, sobald ein Work Item entsteht, ganz ohne manuelle Übergabe. Wie die Anleitung oben zeigt, kann ein Flow aus zwei Agenten, gestützt auf GitLab Orbit, die tatsächliche Auslastung des Teams auslesen und jedes neue Item der Person zuweisen, die es am besten übernehmen kann. Das Ergebnis: Work Items werden zugewiesen, sobald sie entstehen, ausgewogenere Arbeitslasten und ein Team, das sich auf die Arbeit konzentrieren kann, die wirklich menschliches Urteilsvermögen braucht.

Jetzt eine kostenlose Testversion der GitLab Duo Agent Platform starten.

GitLab Orbit ist ein lebendiger, abfragbarer Graph des eigenen Codes samt Merge Requests, Pipelines, Deployments und Verantwortlichkeiten, in dem jede Beziehung zwischen diesen Elementen aktuell gehalten wird. Agenten schreiben zwar guten Code, tun sich aber schwer damit, das umgebende System zu verstehen. Die verbindenden Fragen – was hängt hiervon ab, welche Tests decken es ab, wer verantwortet die Folgen – bedeuteten früher, dass ein Agent Dateien durchsuchte oder eine Entwicklerin bzw. ein Entwickler sich durch vier Werkzeuge graben musste. Orbit macht daraus eine einzige Abfrage. Agenten erreichen Orbit über das Model Context Protocol (MCP), Menschen fragen ihn direkt ab, und die Antwort kommt aus dem Graphen selbst statt aus einer Recherche über mehrere Werkzeuge hinweg. Die Orbit-Startseite erzählt die ganze Geschichte. Uns interessierte, was Menschen bauen, sobald dieses Werkzeug ihnen gehört.

Am Hackathon nahmen 1.576 registrierte Entwickler(innen) teil, die 265 zugelassene Projekte im Showcase Track auf Basis von GitLab Orbit einreichten: Agenten, Flows und Skills. Unabhängig davon brachten 26 Mitwirkende 61 Verbesserungen direkt in die Orbit-Codebase ein – von zusätzlicher Sprachunterstützung über Bugfixes bis zu präziseren Docs. Die Community baute nicht nur auf Orbit auf, sie machte Orbit besser.

Welche Probleme die Community anging

Noch vor jeder Bewertung fiel eines auf: Sortiert man die Einreichungen danach, was sie tatsächlich leisten, ergibt sich ein deutliches Ungleichgewicht.

70 Teams bauten eine Variante desselben Werkzeugs: Zeig mir, was diese Änderung brechen könnte, bevor ich sie merge. Mehr als 30 entwickelten Hilfen für Onboarding und Codeverständnis – das Problem hilf mir, diese Codebase zu verstehen. Danach folgten Incident-Root-Cause-Analyse, Architecture Drift, die Diagnose instabiler Pipelines und das Verfolgen einer CVE über mehrere Repositories hinweg.

Das ist kein Zufall. Solche Fragen stellen sich ständig, und sie wurden bislang schlecht beantwortet, weil die Antworten über Git, CI, Deployment-Werkzeuge und einige wenig vertrauenswürdige Dashboards verstreut lagen. Liegen sie in einem einzigen Graphen, greifen die Teams gezielt darauf zu.

Das ist Orchestrierung mit Kontext und eingebauter Kontrolle, nicht Orchestrierung allein. Und wenn Dutzende unabhängige Teams von sich aus zur gleichen Abfrage greifen, ist das ein Signal, das Plattformverantwortliche lesen sollten: Der Kontext ist der Ort, an dem die Arbeit tatsächlich stattfindet. In den stark besetzten Kategorien war die Messlatte hoch. Projekte hoben sich ab, indem sie 68 andere Teams hinter sich ließen oder einen Weg gingen, den sonst niemand einschlug.

Am saubersten gebaut

Gewinner: Sankofa. Drei Agenten, jeder ausgelöst durch einen anderen Moment im Arbeitsalltag, alle lesen aus GitLab Orbit. Beim Öffnen einer Merge Request liefert Radar den Blast Radius: nachgelagerte Aufrufer, betroffene Pipelines und das Team, das die Folgen verantwortet. Bei der Zuweisung eines Issues erstellt Guide vorab eine kurze Einordnung. Taucht eine Schwachstelle auf, verfolgt Shield jeden Pfad dorthin. Der Kontext erscheint dort, wo bereits gearbeitet wird, und tritt dann in den Hintergrund.

„Wenn eine Sicherheitslücke gemeldet wird, verbringen Teams Tage damit, ihre Reichweite manuell nachzuvollziehen, weil nichts die Zusammenhänge automatisch herstellt."

Lester K, Sankofa

Shield erledigt das in einem einzigen Durchlauf über den Graphen.

Zweitplatziert: Stayed Shipped. Das Projekt stellt eine Frage, die gängige Dashboards nicht beantworten: Wie viele der Änderungen, die KI-Agenten im letzten Monat gemergt haben, sind noch in Produktion? Es verfolgt, ob eine gemergte Änderung Bestand hat oder still von einer erfahrenen Fachkraft nachgebessert wird – unsichtbar für jede Standardmetrik.

Am besten bedienbar

Gewinner: Carver. Carver beziffert eine Legacy-Migration, bevor man sich auf sie festlegt. Man gibt an, was migriert werden soll; Carver liest den Abhängigkeitsgraphen von GitLab Orbit und erstellt einen Kostenvoranschlag: wie viele Einheiten, wie aufwendig, in welcher Reihenfolge und wo die Risiken liegen. Überzeugt hat in dieser Kategorie das Ergebnis. Carver gibt eine Zeile pro Einheit aus, dimensioniert und mit Risikomarkierung, und zeigt Details erst auf Nachfrage. Die Migration von AngularJS zu Angular weist das Projekt in seiner Demo mit rund neun Wochen manuellem Aufwand gegenüber zehn Dollar Generierungskosten aus, wobei der ungetestete, tragende Service rot markiert ist.

„Es prüft Orbit, findet den Service nicht und fragt nach, wo der eigentliche Code liegt."

Anes Mulalic, Carver

Deshalb weigert sich der Agent, eine Zahl zu erfinden, die er nicht belegen kann.

Zweitplatziert: Marshal. Gleiches Gebiet, umgekehrter Ansatz: volle Autonomie. Man deklariert ein organisationsweites Ziel, und Marshal findet über GitLab Orbit jedes betroffene Repository, ordnet die Arbeit in eine Reihenfolge und reicht Merge Requests Welle für Welle ein, ohne dass ein Ziel verloren geht.

Größte Wirkung

Gewinner: CrossCut. CrossCut führt nur die Tests aus, die eine Änderung tatsächlich brechen könnte. Beim Öffnen einer Merge Request zieht es die geänderten Symbole heran, folgt dem Call Graph von GitLab Orbit bis zur echten transitiven Auswirkung und baut eine Pipeline, die genau diese Tests ausführt und keine weiteren. Kein Modell im Spiel, kein Raten, nur Traversierung. Bei einer großen oder repoübergreifenden Test-Suite reduziert das den CI-Umfang laut Projektangabe um 90 % oder mehr.

„Man braucht den Call Graph der gesamten Codebase, um zu wissen, welche Tests eine Änderung erreichen kann. Genau das baut GitLab Orbit – statt zu raten, fragen wir einfach den Graphen."

Pritesh Kumar, CrossCut

Zweitplatziert: OrbitWeaver. Es refaktoriert autonom und nutzt dafür den exakten Blast Radius von GitLab Orbit statt Vektorähnlichkeit. Es erfasst jede betroffene Datei und bearbeitet sie in Abhängigkeitsreihenfolge – das überzeugendste Argument dafür, warum ein echter Graph unscharfer Suche überlegen ist, wenn ein Fehler eine rote Pipeline bedeutet.

Beste Idee

Gewinner: Transcend. Die meisten Teams fragten GitLab Orbit direkt ab – für die meisten Fragen der richtige Weg. Transcend baute darauf eine zweite Reasoning-Engine auf, mit dem Semantic-Web-Stack aus OWL, SPARQL und RDF, um Fragen zu erreichen, die die native API nicht in einem einzigen Aufruf ausdrücken kann. Transitive Hülle. Joins, die die eigene Codebase verlassen und das strukturierte Wissen der Welt hinzuziehen. Die Demo fragt, welche Methoden zum Knowledge-Graph-Embedding eine Codebase implementiert, und erhält die Klassennamen samt den Papers, die sie inspiriert haben, deren Autor(inn)en und Jahreszahlen – live mit dem Code verknüpft. Orbit als Fundament zu begreifen, auf dem sich aufbauen lässt, statt als API, die man nur aufruft, war hier wirklich neu, und genau das zeichnet diese Kategorie aus.

Zweitplatziert: Universal Agent OS. Es baut die Governance-Schicht um Agenten herum, nicht den Agenten selbst: erst befragen, vor dem Coden planen, Belege sichern und Validierung erzwingen. Je größer der Anteil des Codes wird, den Agenten schreiben, desto mehr wird ihre Rechenschaft zum eigentlichen Problem. Es ist dasselbe Problem, das der Kontext von GitLab Orbit an jeder anderen Stelle dieser Liste sichtbar macht: Agenten produzieren in großem Umfang, und dennoch muss jemand für das Ergebnis geradestehen.

Contribute Track

Der Contribute Track lief parallel zum Showcase Track und war keine Nebensache. 26 Mitwirkende brachten 61 Merge Requests direkt in die Codebase von GitLab Orbit ein: Sprachunterstützung für C++20 Concepts, Go-Paketdeklarationen, Kotlin Coroutines und Ruby Lambdas; Ontologie-Korrekturen; einen SIGPIPE-Bug in der CI; das erste Tutorial für Orbit-Abfragen; und Aufräumarbeiten an der Dokumentation, damit die nächste Person nicht über max_depth versus max_hops stolpert. Neunzehn erhielten einen Geldpreis, alle 26 Swag-Credits.

Die Geldpreise gingen an die ersten 40 gemergten Beiträge; diese Liste spiegelt daher ebenso die Reihenfolge wie die Qualität wider. Es sind die Mitwirkenden, deren funktionierende Änderung als Erste geprüft und gemergt wurde. Glückwunsch den Preisträger(inne)n dieser Runde:

achalbajpai, aishahsofea, AlphaTheGoat27, anushkrishnav, bartekp854, bhandari.varun04, ChaitanyaManik17, fa220, fongse, gatlavishweshwarreddy26, gkepas, JonstonChan, koves, MattGaiser, MatthewOscar, nexpectArpit, priyansh3133, Vinayreddy765, zidanesalim.

Alle gemergten Beiträge im Überblick.

Was die Community uns gezeigt hat

Über ein Werkzeug lernt man etwas, indem man beobachtet, was Menschen damit bauen, bevor ihnen jemand sagt, wofür es gedacht ist. Niemand baute einen Chatbot. Die starken Einreichungen setzten im Kern alle beim Gleichen an: Sie nahmen eine Frage, die früher eine Recherche über vier Werkzeuge hinweg bedeutete, und beantworteten sie mit einer einzigen Abfrage.

• Was bricht, wenn ich das merge?
• Welche Tests sind wirklich relevant?
• Was kostet diese Migration am Ende?
• Ist die Änderung vom letzten Monat noch aktiv?

Diese Funktionen haben wir nicht ausgeliefert. Die Community fand sie, sobald der Graph in Reichweite war. Das sagt mehr über GitLab Orbit aus als jeder Benchmark.

Das komplette Teilnehmerfeld findet sich in der Projektgalerie. Viele gute Projekte passten nicht in acht Kategorien.

Was sich mit GitLab Orbit umsetzen lässt

Jedes der genannten Gewinnerprojekte ist eine Antwort auf dieselbe Frage: Was kann ein Agent leisten, wenn er aus First-Party-Kontext über das gesamte System hinweg schließt, statt aus Fragmenten zu raten? GitLab Orbit bildet Code, Work Items, Merge Requests, Pipelines, Deployments und Verantwortlichkeiten fortlaufend in einem Graphen ab, sodass Agenten und Entwicklungsteams aus einer einzigen Quelle der Wahrheit schöpfen. Für den Einstieg braucht es keinen Hackathon. Diese Muster hat die Community erprobt, jedes davon verankert in einem Anwendungsfall, für den Orbit gebaut wurde.

• Änderungen absichern, bevor gepusht wird. GitLab Orbit lässt sich in einer einzigen Abfrage nach jedem nachgelagerten Aufrufer einer Funktion, den davon gespeisten Pipelines und dem verantwortlichen Team fragen. Sankofas Radar tut dies an einer Merge Request; CrossCut nutzt denselben Call Graph und führt nur die Tests aus, die eine Änderung erreichen kann, was einen CI-Lauf laut Projektangabe um 90 % reduziert. So lassen sich verborgene Abhängigkeiten früh erkennen, statt sie erst am Ende der CI zu entdecken.
• Sicherere Migrationen mit vollem Systemkontext. Abfragen lässt sich, welche Services von dem abhängen, der migriert werden soll, in welcher Reihenfolge und wo das Risiko sitzt. Carver macht daraus einen bezifferten Kostenvoranschlag, Marshal treibt sie Repository für Repository voran. Beide ermitteln den Blast Radius aus dem realen Abhängigkeitsgraphen, sodass ein Plattformteam sich auf einen Migrationstermin festlegen kann, statt verborgene Abhängigkeiten erst nach drei Wochen zu entdecken.
• Blast-Radius-Analyse für Schwachstellen. Von einer verwundbaren Funktion aus folgt der Graph jedem erreichbaren Endpunkt, den Pipelines, die ihn bauen, und den verantwortlichen Teams. Sankofas Shield erledigt in einem einzigen Durchlauf, was früher eine Korrelationsarbeit Projekt für Projekt bedeutete.

Der rote Faden: Die Antwort lag nie im Code allein. Sie liegt darin, wie Code mit Pipelines, Deployments, Schwachstellen und Verantwortlichkeiten zusammenhängt, und GitLab Orbit hält diese Zusammenhänge aktuell, sodass sich alles in einer einzigen Abfrage klären lässt. Agenten auf der GitLab Duo Agent Platform fragen ihn nativ ab, externe Agenten verbinden sich über MCP, und Entwicklungsteams fragen denselben Graphen direkt über den Data Explorer ab. Ein Graph, eine Quelle der Wahrheit – für jeden Agenten und jede Person im Team.

GitLab Orbit ausprobieren

Allen Teilnehmenden ein Dankeschön. Wer selbst etwas bauen möchte, beginnt mit GitLab Orbit auf der GitLab Duo Agent Platform: Derselbe Kontext, den diese Teams genutzt haben, ist im eigenen Software-Lebenszyklus bereits verfügbar. Eine Neuauflage folgt. Wer zuerst davon erfahren möchte, meldet sich unter contributors.gitlab.com an.

Bereits Zugang zur GitLab Duo Agent Platform und zu GitLab Orbit – und neugierig, wie weit sich das treiben lässt? Für Co-Create bewerben.

GitLab 19.2 schließt diese Lücke, da Custom Flows die allgemeine Verfügbarkeit erreichen: KI-gestützte Workflows, die einmal definiert, durch native GitLab-Events ausgelöst und in der CI/CD-Pipeline ausgeführt werden. Ein selbstheilendes Pipeline-Muster wie fehlgeschlagenen Test analysieren → Fix generieren → committen → Team benachrichtigen wird zu etwas, das die Plattform durchgängig ausführen kann.

Zusätzlich starten Foundational Flows nicht mehr nur über einen Button, eine Mention oder eine Assignment. Passt eine Anfrage in GitLab Duo Agentic Chat jetzt zu spezialisierter Arbeit – eine Änderung umsetzen, eine Merge Request prüfen, eine fehlgeschlagene Pipeline reparieren –, empfiehlt Duo den passenden Flow, die Übergabe wird bestätigt, und die weitere Ausführung lässt sich aus der Konversation heraus verfolgen.

Damit kommt agentische Software-Delivery über Single-Turn-Chat hinaus. Teams kodieren die Abläufe, denen sie bereits vertrauen, starten sie über Events oder Chat und behalten den Menschen bei der Freigabe statt bei jedem einzelnen Zwischenschritt.

Warum mehrstufige Software-Delivery manuell bleibt

Agentische Demos bevorzugen einzelne Interaktionsschritte. Echte Delivery-Arbeit ist eine Kette: Kontext sammeln, Code ändern, eine Merge Request öffnen, auf CI warten und auf Review reagieren. Ohne Flows ist jedes Glied dieser Kette eine Person, die klickt, einfügt oder sich an ungeschriebene Abläufe erinnert.

Der Aufbau dieser Ketten fühlte sich lange provisorisch an, solange Custom Flows innerhalb der GitLab Duo Agent Platform noch nicht ausgereift waren. Teams schoben die Kodierung der Pfade, denen sie bereits vertrauen – etwa selbstheilende Pipelines, „Implementiere dieses Issue" oder ereignisgesteuerte Folgeaktionen – auf, weil Produktionsreife und Event-Abdeckung noch fehlten.

Was Agentic Flows für Engineering-Teams verändern

• Die Abläufe automatisieren, denen bereits vertraut wird. Custom Flows führen mehrstufige Aufgaben projektübergreifend aus, ausgelöst durch GitLab-Events, mit denen bereits gearbeitet wird: Mentions, Assignments, Pipelines, Änderungen im Merge-Request-Lifecycle, Work-Item-Änderungen und mehr. Sie laufen unter einer Composite Identity, sodass Zugriff begrenzt und Aktionen nachvollziehbar zuordenbar bleiben.
• Spezialisierte Arbeit direkt aus dem Chat starten. Agentic Chat lässt sich bitten, den Developer Flow zur Umsetzung von Arbeit, den Code Review Flow zur Prüfung einer Merge Request oder den Fix CI/CD Pipeline Flow zur Diagnose und Behebung einer fehlgeschlagenen Pipeline zu nutzen. Die Übergabe wird bestätigt, danach lässt sich weiterarbeiten, während der Fortschritt inline angezeigt wird.
• Automatisches Review gezielt steuern. In GitLab 19.2 lassen Exclusion Rules zu, Auto-Review für bot-erstellte oder nach Branch-Mustern gefilterte Merge Requests zu überspringen, bei denen keine Credits verbraucht werden sollen. Custom Review Instructions legen fest, worauf das Review achtet – damit lässt sich nicht nur bestimmen, welche Merge Requests geprüft werden, sondern auch wie.

Duo Agentic Flows in Aktion:

Wie funktionieren sie?

Custom Flows. Ein Custom Flow lässt sich aus einem Projekt oder dem AI Catalog erstellen, die Sichtbarkeit wählen, dort aktivieren, wo er gebraucht wird, und mit einem Trigger versehen, damit die passenden GitLab-Events ihn starten. An sensiblen Schritten lassen sich Human-in-the-Loop-Checkpoints hinzufügen. In 19.2 erhalten Custom Flows außerdem einen „Work Item Status Changed"-Trigger sowie eine Bulk-Aktivierung für öffentliche Flows über bis zu 100 Projekte hinweg. Für die Zukunft ist ein Flow Creation Agent auf der Roadmap, mit dem sich ein Flow in einfacher Sprache beschreiben lässt, um eine lauffähige Definition zu erhalten, ohne zunächst das komplette Schema von Hand zu schreiben.

Foundational Flows in Agentic Chat. Wenn eine Anfrage zu spezialisierter Arbeit passt, kann sie an einen Foundational Flow übergeben werden; die Ausführung wird vor dem Start bestätigt, und die Konversation bleibt währenddessen bestehen. Das ist der Unterschied zu Chat, der nur antwortet: Der mehrstufige Teil verlässt die eigenen Hände, ohne GitLab zu verlassen.

Aktualisierte Automatisierung für den Code Review Flow. Exclusion Rules verhindern, dass bot-gesteuerte oder nicht relevante Merge Requests Code-Review-Zyklen verbrauchen, die nicht eingeplant waren. Und Custom Review Instructions legen fest, wie „gut" für das jeweilige Team aussieht – so bedeutet mehr Automatisierung nicht, dass alles gleich geprüft wird.

Die bereits gelebten Pfade jetzt kodieren

Custom Flows sind jetzt allgemein verfügbar, und Foundational Flows lassen sich jetzt aus Agentic Chat heraus starten, das Anfragen anhand der Beschreibung des Bedarfs an den passenden Spezial-Flow weiterleitet – und übersetzt so die agentischen Software-Delivery-Abläufe, denen das eigene Team bereits vertraut, in vorhersehbare Automatisierung, jenseits von ungeschriebenem Wissen.

Mehr erfahren? Der Einstieg gelingt über die Dokumentation zu Custom Flows und Foundational Flows. Ein Punkt zur Planung: Event-gesteuerte Flows verbrauchen Credits abhängig von der geleisteten Arbeit. Ein Test in wenigen Projekten empfiehlt sich, bevor sie über eine große Gruppe hinweg freigegeben werden.

Wie bei anderen Fähigkeiten der Duo Agent Platform lässt sich der Zugang zu Agentic Flows über eine kostenlose Testversion der GitLab Duo Agent Platform erhalten. Im Free-Tier ist die Anmeldung in wenigen Schritten möglich.

Bereits auf GitLab Premium oder Ultimate? Der Einstieg gelingt durch das Aktivieren der Duo Agent Platform und die Nutzung der im Abonnement enthaltenen GitLab Credits.

Security Review Flow, jetzt in der Public Beta, prüft Code-Änderungen so, wie es ein Security Engineer tun würde. Anstatt Signaturen abzugleichen, verfolgt der Flow die Absicht hinter dem Code, um Logikfehler vor der Produktion zu erkennen. Das ist ein wichtiger Schritt, um gefährliche Fehler aufzudecken, die Scanner meist übersehen.

Wo musterbasierte Scanner blind bleiben

Die schädlichsten Schwachstellen wirken Zeile für Zeile oft korrekt, verletzen aber einen Kontext, der im Code selbst nicht enthalten ist – etwa das Autorisierungsmodell, Regeln zur Sensibilität von Daten oder die vorgesehenen Workflows. Drei der häufigsten Schwachstellenklassen im Überblick:

Zugriff und Autorisierung: Ob Nutzende eine Ressource lesen oder ändern dürfen, legt das Autorisierungsmodell fest, nicht ein Sprachkonstrukt. Broken Object Level Authorization (der Zugriff auf die Daten anderer Nutzender durch das Ändern einer ID) führt die OWASP API Security Top 10 seit 2019 an.

Data Exposure: Ein Objekt zu serialisieren und zurückzugeben, ist gewöhnlicher, korrekt wirkender Code. Ob dabei Daten offengelegt werden, hängt davon ab, welche Felder sensibel sind und wer sie erhält – Fakten der jeweiligen Domäne, nicht der Syntax.

Kontrollfluss und Workflow: Business-Logic- und Race-Condition-Fehler entstehen, wenn valide Operationen in falscher Reihenfolge ablaufen, unerwartet wiederholt werden oder manipuliert werden. Beispiele sind ein Checkout, der ohne Zahlung erreichbar ist, ein Status, der durch eine Race Condition erneut betreten wird, oder ein Parameter, der zur Preisänderung manipuliert wird.

Solche Fehler zu erkennen, erforderte bisher entweder manuelles Security Review, das sich über jede Merge Request (MR) hinweg nur teuer skalieren lässt, oder Penetration Testing und Bug Bounties, die zu spät greifen. Die Folge ist eine wachsende Lücke zwischen dem Tempo der Entwicklung und dem Umfang, in dem Security-Expertise angewendet werden kann.

Security-Expertise in jede MR einbringen

Security Review Flow, ein Foundational Flow auf der GitLab Duo Agent Platform, schließt diese Lücke, indem er nachvollzieht, was der Code eigentlich leisten soll. Er erkennt genau die oben beschriebenen Fehlerklassen: Broken Object Level Authorization und Broken Function Level Authorization, fehlende Autorisierung bei zustandsändernden Operationen, Information Disclosure, Mass Assignment, Business-Logic-Fehler und Race Conditions in zustandsbehafteten Workflows.

Er ergänzt klassische Scanner und menschliche Analyse, statt sie zu ersetzen, und prüft Code genau zum Zeitpunkt der Änderung, wenn eine Korrektur am günstigsten ist. GitLabs eigenes Application-Security-Team hat Security Review Flow während der gesamten Entwicklung über interne MRs hinweg eingesetzt.

Security Review Flow in Aktion:

So funktioniert es

Ist eine MR bereit, lässt sich ein Review von Duo Security Review anfordern – genau wie von einer Person. Der Flow analysiert den Diff im Kontext: die Originaldateien, geänderte Zeilen, die MR-Diskussion und verwandten Code. Seine Reasoning-Logik ist auf Präzision optimiert, und ein unabhängiger Validierungsschritt prüft jeden Finding, um wahrscheinliche False Positives herauszufiltern.

Findings erscheinen als Diff-Threads an den relevanten Zeilen, ergänzt durch eine Zusammenfassung in einer internen Notiz. Bei öffentlichen Projekten bleiben sie auf die interne Notiz beschränkt, sodass keine Security-Details offengelegt werden.

Jedes Finding liefert den Kontext, der für das Review nötig ist:

• Vulnerability Type mit CWE-Referenz
• Severity: Critical, High, Medium oder Low
• Tier: Tier 1 (Exploitable), Tier 2 (Logic Flaw) oder Tier 3 (Design Issue)
• Eine verständliche Erklärung des Problems
• Ein Fix-Vorschlag, sofern verfügbar

Die Severity bestimmt den Review-Status: Ein Critical- oder High-Finding setzt ihn auf Request changes, während Medium- oder Low-Findings zu Comment führen. Der Flow genehmigt nie – auch dann nicht, wenn er nichts findet –, die finale Entscheidung liegt immer bei einem Menschen.

Von dort aus lässt sich der Duo-Security-Review-Service-Account der jeweiligen Organisation in einem Kommentar-Thread erwähnen, um eine Frage zu stellen, die Behebung zu diskutieren oder ein Finding infrage zu stellen. Jedes Finding lässt sich auflösen, indem der Fix als Standard-MR-Suggestion übernommen, als False Positive verworfen oder das Risiko akzeptiert wird. Nach dem Commit der Fixes lässt sich ein neues Review anfordern, um die Änderungen zu prüfen.

Den ersten Security Review Flow ausführen

Security Review Flow befindet sich für die GitLab-Ultimate-Kundschaft in der Public Beta. Verfügbar ist der Flow auf GitLab.com, GitLab Self-Managed und GitLab Dedicated.

Der Einstieg gelingt über die Security-Review-Flow-Dokumentation.

Der Zugang zu Security Review Flow 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.

Die Kosten variieren je nach Komplexität des Diffs und dem gewählten Modell – ein Test an wenigen MRs empfiehlt sich, bevor der Flow breiter eingesetzt wird. Die Preisgestaltung kann zur allgemeinen Verfügbarkeit angepasst werden.

Feedback lässt sich im Feature-Feedback-Issue teilen – so fließt es direkt in die Weiterentwicklung ein.

Agentische KI im Terminal, die nur Code versteht, hilft bei alldem nicht weiter. Ein eigenständiger Assistent kennt weder die Agents über den gesamten Software-Lifecycle hinweg, noch die Berechtigungen über die vielen Projekte einer Organisation, noch einen spezifischen Projektkontext, der in GitLab bereits eingerichtet ist.

Genau das ändert sich mit GitLab 19.2. GitLab Duo CLI ist jetzt allgemein verfügbar und bringt GitLab Duo Agentic Chat direkt ins Terminal. Anders als von außen angeflanschte Tools kennt es das jeweilige Projekt, die Pipelines und das Agent-Setup bereits. Es lässt sich interaktiv nutzen, während erkundet und gebaut wird, oder headless, wenn es in einem Job oder Skript laufen soll.

Dadurch bleiben Entwicklungsteams in der Shell, in der der Fehler aufgetreten ist, und die Arbeit setzt sich über Terminal, UI und Editor hinweg fort. Platform-Teams steuern den Rollout wie alles andere in GitLab, und agentische Unterstützung deckt endlich mehr vom Delivery-Lifecycle ab als nur „Schreib diese Funktion."

Warum agentische KI im Terminal bei Code stehen blieb

Agentische Tools reiften zuerst dort, wo Demos am besten aussehen: beim Bearbeiten von Dateien. Der Lifecycle nach dem Commit ist unübersichtlicher und operativer. Liegt der Fehler in einer Pipeline, einer Dependency oder einer CI-Konfiguration, steckt der Kontext in GitLab – nicht im Trainingsdatensatz eines Coding Agents oder im lokalen Kontext.

Teams, die diese Lücke mit generischen CLI-Assistenten schließen wollten, zahlten einen weiteren Preis: keine gemeinsame Admin-Kontrolle, keine auf die Plattform abgestimmte MCP-/Setup-Diagnose und kein einheitliches Identitätsmodell mit dem Rest des agentischen Software-Lifecycles. Agentische Arbeit im Terminal blieb so auf Coding beschränkt, statt im übrigen Delivery-Prozess zu unterstützen.

Was Teams mit der allgemeinen Verfügbarkeit von Duo CLI bekommen

• Im Terminal bleiben für die Arbeit, die dort ohnehin stattfindet. Nachvollziehen, wie die Codebase zusammenspielt, bauen und refactoren, Pipeline-Fehlern nachgehen, CI/CD aufräumen und mehrstufige Aufgaben erledigen – ohne für jede Antwort in den Browser zu wechseln.
• Genau dort weitermachen, wo aufgehört wurde – auf jeder Oberfläche. Sessions werden zwischen GitLab Duo CLI, der GitLab-UI und den Editor-Extensions geteilt. Start im Browser. Weiter in der Shell. Dieselbe Konversation.
• Erst planen, dann bauen. Der Interactive Mode funktioniert wie Agentic Chat: Der Plan Mode schaut sich alles an, ohne etwas zu verändern, der Build Mode nimmt die Änderungen vor. Soll es unbeaufsichtigt laufen? Der Headless Mode klinkt sich in CI-Jobs und Skripte ein.
• Aktivieren, sobald der Zeitpunkt passt. Duo CLI funktioniert auf GitLab.com, GitLab Self-Managed und GitLab Dedicated. Auf Self-Managed und Dedicated können Admins den Instanzzugriff ein- oder ausschalten. Überall, wo es genutzt wird, lässt sich mit /doctor das eigene Setup prüfen und mit /mcp die MCP-Konfiguration einsehen.

GitLab Duo CLI in Aktion:

So funktioniert Duo CLI

Der einfachste Weg führt über die GitLab CLI: glab duo cli ausführen, und glab übernimmt die Authentifizierung. duo lässt sich auch als eigenständiges Tool mit einem Personal Access Token installieren und ausführen. Beide Varianten unterstützen dieselben Modi und Funktionen.

• Interactive Mode — Chat im Terminal, Tools werden vor der Ausführung bestätigt. Codebase erkunden, einen Fix planen und dann in den Build Mode wechseln, sobald Änderungen vorgenommen werden sollen.
• Headless Mode — nicht-interaktive Ausführung für Runner, Skripte und Automatisierung. Dafür glab duo cli run --goal oder duo run --goal verwenden.

Schlägt zum Beispiel eine Pipeline fehl, lässt sich direkt aus derselben Shell fragen:

$ glab duo cli
> Die Pipelines in MR 23 schlagen fehl. Bitte hilf mir, sie zu beheben.

Duo CLI analysiert die Lage, ermittelt die Fehlerursache und schlägt Änderungen vor, die sich vor dem Anwenden prüfen lassen. Beim Skalieren folgt es den eigenen Custom Instructions (chat-rules.md, AGENTS.md, SKILL.md), und interaktive Sessions lassen sich mit Custom Slash Commands erweitern.

Duo CLI schon heute nutzen

Installation und Authentifizierung gelingen über die GitLab-Duo-CLI-Dokumentation – wer die GitLab CLI bereits nutzt, startet direkt mit glab duo cli.

Neu bei GitLab? Kostenlose Testversion der GitLab Duo Agent Platform starten. Bereits auf Premium oder Ultimate? Duo Agent Platform aktivieren und die im Abonnement enthaltenen GitLab Credits nutzen.

Agentische Programmierung beschleunigt die Arbeit der Entwicklungsteams. Die schwierigere Frage ist, wie Unternehmen aus diesem Tempo einen messbaren Ertrag gewinnen, denn schnellere Commits sind nur ein Teil dessen, was produktionsreife Software ausmacht. Ein Systems Engineer aus dem Versicherungs- und Finanzsektor beschreibt es so: Die Plattform übernehme 80 bis 90 % der Code-Generierung, und der Code-Review beanspruche einen Bruchteil der früheren Zeit.

Um den erzielbaren Nutzen einzuordnen, befragte Forrester vier Entscheidungsträger aus den Branchen Finanzdienstleistung, Softwareentwicklung, Unterhaltung und Versicherung, die die GitLab Duo Agent Platform produktiv einsetzen. Aus ihren Angaben formte Forrester eine einzige zusammengesetzte Musterorganisation: ein global tätiges Unternehmen mit 3 Mrd. USD Jahresumsatz und 3.000 Mitarbeitenden, das die Zahl der Plattform-Nutzenden über drei Jahre von 150 auf 250 erhöht.

Kosten und Nutzen im Verhältnis

Die Studie legt den erforderlichen Aufwand offen: risikobereinigte Kosten über drei Jahre von 1,3 Mio. USD für Verbrauchs-Credits sowie 589.000 USD für Implementierung und laufenden Betrieb, einschließlich interner Personalkosten für Pilotprogramm, Schulung und Support. Diesen Kosten stehen 9,4 Mio. USD an Nutzen gegenüber. Daraus ergeben sich der ROI von 400 % und der Kapitalwert von 7,5 Mio. USD.

Ausgangslage vor der Einführung

Vor der Einführung der GitLab Duo Agent Platform schilderten die Befragten bekannte Engpässe. Teams waren auf manuelle Prozesse, das Wissen einzelner Senior-Engineers und informellen Wissensaustausch angewiesen, um Software zu erstellen, zu prüfen und abzusichern. Neue Teammitglieder kamen nicht weiter, ohne einen Senior-Engineer von der eigenen Arbeit abzuziehen. Sicherheitskorrekturen blieben liegen, bis eine der wenigen Personen mit dem nötigen Kontext Zeit fand. Und nicht das Schreiben von Code, sondern der Review hielt die Auslieferung häufig auf. Genau diese Abhängigkeiten bildete Forrester in der Musterorganisation ab und maß ihre Auflösung.

Ergebnisse nach der Einführung

Forrester quantifiziert vier Nutzenbereiche für die Musterorganisation, die sich auf 9,4 Mio. USD risikobereinigten Nutzen gegenüber 1,9 Mio. USD Kosten summieren.

Neue Entwickelnde benötigten 80 % weniger Einarbeitungszeit. Statt Kolleginnen und Kollegen von der eigenen Arbeit abzuziehen, nutzten neue Teammitglieder den in IDE und Repository eingebetteten agentischen Chat, um sich eigenständig in unbekannte Codebasen und Konventionen einzuarbeiten. Forrester beziffert die Einsparung auf 582.000 USD.

Eine auf acht Monate veranschlagte Migration war nach zwei Monaten abgeschlossen. Die Musterorganisation nutzte die Plattform, um während einer umfangreichen Migration von einer On-Premises-Umgebung zu GitLab SaaS Pipeline-Fehler zu diagnostizieren und Probleme unmittelbar zu beheben. Das entspricht einer um 75 % kürzeren Laufzeit und 157.000 USD eingesparten Personalkosten.

Sicherheits- und QA-Engineers gewannen 40 % ihrer Arbeitszeit zurück. Mithilfe kontextbezogener Erklärungen und Korrekturvorschläge der Plattform verringerten sie den Aufwand für die Behebung von Schwachstellen und waren weniger auf Senior-Engineers angewiesen. Forrester rechnet dies mit 1,3 Mio. USD Personaleinsparung über drei Jahre.

Jede entwickelnde Person gewann 20 % der Wochenarbeitszeit für Feature-Arbeit zurück. Agentischer Chat und KI-Agenten übernahmen Code-Review, Tests und Fehlersuche, die zuvor Entwicklungszeit banden. Über alle Entwickelnden summiert Forrester dies auf 7,4 Mio. USD, mit wachsender Nutzung über den Dreijahreszeitraum.

Forrester nennt zudem nicht quantifizierte Nutzen: Einsparungen durch die Konsolidierung sich überschneidender KI-Entwicklungswerkzeuge, höhere Zufriedenheit in den Entwicklungsteams und besseren Wissensaustausch zwischen Teams.

Zusammenspiel über den gesamten Lebenszyklus

Das Muster, das die Studie festhält: Agentische Programmierung steigert die Ausgabe einzelner Entwickelnder, doch der Ertrag summiert sich erst, wenn dieses Tempo über eine Infrastruktur läuft, die den gesamten Software-Lebenszyklus abdeckt.

Wer den Business Case für agentische Infrastruktur im eigenen Unternehmen aufbaut, findet in der Studie einen Rahmen, der auf den dokumentierten Erfahrungen von vier Unternehmen beruht.

Die vollständige Forrester-Total-Economic-Impact™-Studie zur GitLab Duo Agent Platform lesen – mit Methodik, Finanzmodell und Interview-Ergebnissen.

Diese Studie wurde von GitLab in Auftrag gegeben und von Forrester Consulting durchgeführt. Sie ist nicht als Wettbewerbsanalyse gedacht. Forrester trifft keine Annahmen über den möglichen ROI anderer Organisationen; die Ergebnisse geben die Erfahrungen der befragten Organisationen und der daraus gebildeten Musterorganisation wieder. GitLab stellte die Namen der Kundinnen und Kunden für die Interviews bereit, nahm an diesen jedoch nicht teil, und Forrester behält die redaktionelle Kontrolle über die Ergebnisse der Studie.

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.