Warum wird diese Änderung vorgenommen?

Diese Änderung ist notwendig, weil curl 8.18.0 die Kompilierung gegen OpenSSL 1.x als veraltet markiert hat. Das verhindert die Fortführung des bisherigen Ansatzes auf Amazon Linux 2 und AlmaLinux 8 (betrifft RHEL-8-Kunden). GitLab stellt die meisten Abhängigkeiten für Omnibus-GitLab selbst bereit, verknüpft in FIPS-Paketen jedoch mit den kryptografischen Bibliotheken der Distribution statt eigene zu bündeln – dieses Modell wird nun auf curl ausgeweitet.

Aus Gründen der Wartbarkeit und Sicherheit wird diese Änderung auf alle FIPS-Pakete angewendet, einschließlich Distributionen mit OpenSSL 3.0 oder höher. Alle FIPS-Kunden sind betroffen.

Was ist zu tun?

GitLab Self-Managed

GitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.

Weitere Informationen zum Release-Zeitplan.

Ab dem 19.0 Omnibus-GitLab FIPS-Paket wird das gebündelte curl entfernt und durch das curl der Linux-Distribution des Kunden ersetzt. Die GitLab-Instanz des Kunden funktioniert weiterhin wie erwartet. Diese Änderung hat keine weiteren Auswirkungen und erfordert keine sofortigen Maßnahmen.

Wichtiger Hinweis

GitLab ist künftig nicht mehr für die Bereitstellung von Sicherheitsupdates für curl in FIPS-Paketen verantwortlich. Es obliegt dem Kunden, das curl des eigenen Betriebssystems aktuell zu halten, um Fixes und Sicherheits-Patches zu erhalten. Scanner-Findings für curl spiegeln künftig das Host-OS-Paket wider und nicht mehr eine von GitLab gebündelte Version. Dies entspricht der bestehenden Handhabung von OpenSSL in FIPS-Umgebungen.

Probleme nach der Umstellung?

Bei Bedarf bitte ein Issue im Omnibus-GitLab Issue Tracker öffnen.

Deshalb haben wir GitLab Duo Agent Platform geöffnet und Entwickler(innen) weltweit eingeladen, KI-Agenten zu bauen, die Teams dabei helfen, sichere Software schneller zu liefern. Keine Chatbots, die Fragen beantworten – sondern Agenten, die in Workflows einspringen, auf Ereignisse reagieren und in deinem Auftrag handeln. Der GitLab AI Hackathon lief vom 9. Februar bis zum 25. März 2026 auf Devpost. Google Cloud und Anthropic waren Co-Sponsoren.

Als mein Team diesen Hackathon mit Google Cloud und Anthropic plante, bat ich die Juroren, vier Dinge zu bewerten: technische Umsetzung, Design, potenzielle Wirkung und Ideenqualität. Wir hatten auf starke Beteiligung gehofft. Was wir bekamen, hat uns alle überrascht. Neunzehn Juroren verbrachten 18 Tage damit, jeden Beitrag zu prüfen. Google Cloud und Anthropic stellten Juroren, Preise und Cloud-Zugang bereit. Die Community baute Hunderte von Agenten und Flows – weil sie diese Probleme lösen wollten.

Fast 7.000 Entwickler(innen) nahmen teil. Sie bauten in wenigen Wochen über 600 Agenten und Flows. Die Preise über alle Kategorien summierten sich auf 65.000 US-Dollar – bereitgestellt von GitLab, Google Cloud und Anthropic.

Wer schon einmal erlebt hat, wie ein erfahrener Engineer das Unternehmen verlässt und die Hälfte des Team-Wissens mitnimmt, weiß, warum das Gewinnerprojekt so eingeschlagen hat.

Lies weiter und erfahre, was die Community gebaut hat.

Gesamtsieger: LORE

LORE, die Living Organizational Record Engine, nutzt acht Agenten mit einem Router, der jede Frage an den richtigen Agenten weiterleitet, Logik zur Vermeidung zirkulärer Schleifen im Wissensgraphen, ein visuelles Dashboard und Carbon-Tracking. Das Kommandozeilen-Werkzeug kommt mit 43 Tests – ja, 43 Tests in einem Hackathon-Projekt.

LORE löst ein reales Problem: das Wissen, das in den Köpfen von Engineers lebt und mit ihnen geht, wenn sie das Unternehmen verlassen. In meiner Erfahrung ist ein Hackathon-Projekt mit 43 Tests eine Seltenheit. So viele Tests in einem Hackathon-Projekt sagen etwas über das Team dahinter aus.

Jurorin April Guo (Anthropic) schrieb: „Das fühlt sich wie ein Produkt an, nicht wie ein Hackathon-Projekt."

Google Cloud-Gewinner

Gitdefender gewann den Google Cloud Grand Prize. Es arbeitet innerhalb von Code-Review-Workflows, findet und behebt Sicherheitsprobleme. Es erkennt den Fehler, schreibt den Fix und öffnet den Code-Review. Kein Mensch muss eingreifen.

Aegis gewann den Google Cloud Runner Up. Es liefert KI-gestützte Erklärungen für jede Entscheidung, die es trifft – auf Google Cloud gehostet und bereit für den Produktionseinsatz.

Anthropic-Gewinner

GraphDev gewann den Anthropic Grand Prize. Es kartiert Code-Verbindungen und zeigt, wie sich Systeme im Laufe der Zeit verändern. Juror Aboobacker MK (GitLab) merkte an, es sei „synchron mit unserer Arbeit am GitLab Knowledge Graph." Juror Ayush Billore (GitLab) schrieb: „Demo und UX haben mich begeistert – extrem nützlich, um zu verstehen, wie das System sich entwickelt hat und was von Änderungen betroffen ist." Man sieht die vollständige Auswirkung einer Änderung, bevor man sie vornimmt.

DocSync gewann den Anthropic Runner Up. Es nutzt drei Agenten: Detector, Writer und Reviewer. Ist DocSync vom Fix überzeugt, öffnet es einen Code-Review. Ist es das nicht, erstellt es ein Issue für eine manuelle Prüfung.

Kategorie-Gewinner

Technisch beeindruckendste Lösung

Datenbank-Migrationen brechen Dinge. Time-Traveler erstellt eine sichere Kopie des Produktions-Setups, führt die Migration gegen diese Kopie durch und meldet das Ergebnis. Es betreibt fünf Agenten, die über eine Bridge verbunden sind – mit echtem Google Cloud-Deployment, echten PostgreSQL-Migrationen und echten Daten.

Wirkungsvollste Lösung

RedAgent prüft KI-generierte Security-Reports und schließt die Vertrauenslücke zwischen KI-Findings und Entwickleraktion. Wer KI für Security Scanning einsetzt, kennt dieses Problem. Ich habe Teams erlebt, die KI-Findings ignorierten, weil sie sie nicht verifizieren konnten. RedAgent gibt Teams eine Möglichkeit, KI-Output zu prüfen, bevor er Entwickler(innen) erreicht.

Einfachste Bedienung

Launch Control liefert ausgefeilte UX und solide Infrastruktur – und schnitt auch beim Thema Nachhaltigkeit gut ab.

Das Nachhaltigkeitssignal

Fünf Projekte gewannen Preise oder Boni für ökologische Wirkung. Software-Auslieferung hat einen Carbon-Fußabdruck durch CI/CD-Pipelines – und nun verarbeiten auch LLMs Rechenleistung im großen Maßstab. Wir haben die Green Agent-Kategorie ins Leben gerufen, um Entwickler(innen) herauszufordern, diesen Fußabdruck zu messen und zu reduzieren. Stacy Cline und Kim Buncle aus GitLabs Nachhaltigkeitsteam halfen bei der Beurteilung der Green Agent-Kategorie.

Green Agent-Preis

GreenPipe scannt CI/CD-Pipelines auf Umweltwirkung und erstellt Carbon-Footprint-Berichte. Juroren Kim Buncle und Rajesh Agadi (Google) unterstützten das Projekt.

Sustainable Design-Bonus

Sustainable Design-Boni wurden an Projekte vergeben, die außergewöhnliche Nachhaltigkeitspraktiken in ihrem Design zeigten – von Modell-Optimierungstechniken bis hin zu energieeffizienten Architekturentscheidungen.

• BugFlow verwandelte einen Bug-Report in 10 Fixes in 20 Minuten.
• DELTA Cyber Reasoning ist automatisiertes Fuzz-Testing für Security.
• CarbonLint wandte Code-Analyse auf den Energieverbrauch an.
• TFGuardian enthält unter anderem einen Carbon-Footprint-Analyser.

Herzlichen Glückwunsch an alle Gewinner des Sustainable Design-Bonus!

Juror Jens-Joris Decorte (TechWolf) zitierte das Ergebnis: Die Kosten sanken von 556 auf 18 US-Dollar pro Monat – ein Carbon-Rückgang von 96 % (das sind 538 US-Dollar monatliche Einsparung mit einem Nachhaltigkeitslabel).

Sechs Projekte wurden lobend erwähnt

Sechs Projekte erhielten Ehrenmeldungen:

• SecurityMonkey injiziert bekannte Schwachstellen in einen Test-Branch und bewertet, wie gut die Security-Scanner sie erkennen.
• stregent überwacht CI/CD-Pipelines und lässt Entwickler(innen) Fixes aus WhatsApp heraus untersuchen und mergen – ohne einen Laptop zu öffnen.
• Compliance Sentinel bewertet jeden Merge Request auf Compliance-Risiko und blockiert den Merge bei kritischen Verstößen.
• Carbon Tracker berechnet den Carbon-Fußabdruck jedes CI/CD-Pipeline-Jobs und veröffentlicht Optimierungstipps im Merge Request.
• RepoWarden ist die erste Living Specification Engine – ein KI-System, das festhält, warum Code geschrieben wurde, nicht nur was er tut.
• MR Compliance Auditor sammelt Nachweise über Merge Requests, ordnet sie SOC-2-Kontrollen zu und streamt Compliance-Scores auf ein Live-Dashboard.

Mein liebstes Zitat aus dem Judging stammte von Luca Chun Lun Lit (Anthropic), der stregents Mobile-First-Ansatz beschrieb: „Im Wesentlichen vom Handy aus programmieren zu können ist das nächste Level in der Engineering-Erfahrung."

Entdecke die über 600 Einreichungen in der Projektgalerie.

Was als Nächstes kommt

Jeder Agent in diesem Hackathon arbeitete innerhalb eines einzelnen Projekts. Die Ergebnisse waren trotzdem beeindruckend. Einige Teilnehmer betrieben einen lokalen Wissensgraphen parallel zu ihren Agenten, um Code-Beziehungen und Abhängigkeiten im Repo sichtbar zu machen. LORE erfasst Projekthistorie. Gitdefender findet Schwachstellen. Agenten mit reichhaltigerem lokalem Kontext zu kombinieren hilft Contributors bereits heute, schärfere Werkzeuge zu bauen. Der nächste Hackathon baut darauf auf. Melde dich auf contributors.gitlab.com an, um als Erster zu erfahren, wann Details bekannt gegeben werden.

Loslegen

Ein besonderer Dank gilt Lee Tickett (GitLab) und Mattias Michaux (GitLab) für die Orchestrierung der Orchestratoren und Innovatoren hinter diesem Hackathon!

Danke an alle, die ein Projekt eingereicht haben. Fast 7.000 von euch haben gezeigt, was GitLab Duo Agent Platform kann, wenn eine Community beschließt zu bauen. Ich bin stolz auf das, was ihr hier gebaut habt – und ich kann es kaum erwarten zu sehen, was ihr als Nächstes baut.

Baue deinen eigenen Agenten auf GitLab Duo Agent Platform. Entdecke Community-gebaute Agenten im AI Catalog. Du orchestrierst. KI beschleunigt.

GitLab Duo Agent Platform ermöglicht Planung, Merge-Pipelines, Security Scanning, Vulnerability Remediation und mehr als Teil bestehender GitLab-Workflows. Der GitLab AI Gateway leitet Modell-Anfragen an Bedrock weiter – oder an GitLab-verwaltete, Bedrock-gestützte Endpunkte, je nach Deployment-Konfiguration. Damit lässt sich auf den IAM-Richtlinien, VPC-Grenzen, regionalen Kontrollen und Cloud-Commitments aufbauen, die bereits in AWS bestehen.

Wer Amazon Bedrock bereits nutzt und KI-Unterstützung innerhalb der bestehenden GitLab-Workflows sucht – nicht in einem weiteren eigenständigen Chat-Werkzeug – findet in dieser Kombination die passende Architektur.

Dieser Artikel beleuchtet zunächst das Problem, mit dem viele Teams heute konfrontiert sind: KI ist fragmentiert, Datenpfade sind unklar, und Bedrock-Investitionen werden zu wenig genutzt, wenn KI außerhalb des Software-Lifecycles operiert. Anschließend werden die Deployment-Optionen für GitLab Duo Agent Platform erläutert:

• Integriert mit selbst gehosteten Modellen auf Amazon Bedrock für GitLab Self-Managed-Deployments und selbst gehosteten AI Gateway
• Integriert mit GitLab-betriebenen Modellen auf Amazon Bedrock (mit GitLab-eigenen Keys) für GitLab Self-Managed-Deployments und GitLab-gehosteten AI Gateway
• Integriert mit GitLab-betriebenen Modellen auf Amazon Bedrock (mit GitLab-eigenen Keys) für GitLab.com-Instanzen und GitLab-gehosteten AI Gateway

Abschließend wird zusammengefasst, wie dieser Ansatz nicht freigegebene KI-Werkzeuge (Shadow AI) und Point-Tool-Sprawl vermeidet, ohne einen parallelen Tech-Stack für KI-Werkzeuge aufzubauen.

KI überall, Kontrolle nirgends

Irgendwo im Unternehmen nutzen Softwareteams gerade ein KI-Werkzeug, das die Sicherheitsabteilung nicht freigegeben hat. Prompt-Daten verlassen möglicherweise die eigene Umgebung über einen Pfad, den niemand vollständig nachverfolgt hat. Und die Bedrock-Investition des Unternehmens wird zu wenig genutzt, während einzelne Teams separate KI-Werkzeuge auf eigene Rechnung betreiben – Workloads und Cloud-Ausgaben fließen so an Plattformen ab, auf die bereits Commitments bestehen.

Das ist kein Personalproblem – es ist ein Architekturproblem. Und es manifestiert sich in nahezu jedem Unternehmen in denselben drei Einschränkungen:

Operative Fragmentierung. Jedes Team – manchmal jede einzelne Person – wählt das eigene Entwicklungs-Toolset, einschließlich KI-Werkzeuge und Modellauswahl. Diese Fragmentierung macht eine durchgängige Governance innerhalb des Software-Lifecycles nahezu unmöglich.

Sicherheit und Datensouveränität. Wo fließen Prompt- und Code-Daten tatsächlich hin? Wer ist Eigentümer der Protokolle?

Cloud-Ausgabenoptimierung. Commitments gegenüber zentralen Cloud-Anbietern wie AWS werden verwässert, wenn Workloads und KI-Nutzung zu Point-Tools außerhalb bestehender Vereinbarungen abwandern.

GitLab Duo Agent Platform und Amazon Bedrock adressieren diese Probleme gemeinsam. Die Aufgabenteilung ist eindeutig: Duo Agent Platform verantwortet die Workflow-Orchestrierung mit agentischer KI für die Softwareentwicklung, Bedrock verantwortet die Inferenzschicht und hostet freigegebene Foundation-Modelle, und das Unternehmen behält die vollständige Kontrolle über die Daten- und Richtliniengrenzen, die bereits in AWS definiert wurden. Drei Aufgaben, drei Verantwortliche, keine Fragmentierung.

GitLab Duo Agent Platform: Die agentische Steuerungsebene

GitLab Duo Agent Platform ist GitLabs agentische KI-Schicht: ein Framework aus spezialisierten Agenten und Abläufen, die gleichzeitig und parallel operieren – über traditionelle stufenbasierte Übergaben hinaus – und Arbeit über den gesamten Software-Lifecycle hinweg automatisieren. Statt eines einzelnen Assistenten, der auf Prompts reagiert, ermöglicht Duo Agent Platform Teams die asynchrone Orchestrierung vieler KI-Agenten auf Basis einheitlicher Daten und Projektkontexte. Dazu gehören Issues, Merge Requests, Pipelines und Security Findings. Lineare Workflows werden so zu koordinierter, kontinuierlicher Zusammenarbeit zwischen Softwareteams und ihren KI-Agenten – im erforderlichen Umfang.

Mit dieser Steuerungsebene stellt sich die nächste Frage: Welches KI-Fundament soll diese Agenten antreiben? Für Unternehmen, die GitLab Self-Managed auf AWS betreiben und sicherstellen müssen, dass Inferenz-Traffic, Prompt-Daten und Protokolle ebenfalls in der AWS-Umgebung verbleiben – gemeinsam mit den Software-Lifecycle-Daten – ist Amazon Bedrock als KI-Inferenzschicht die naheliegende Wahl.

Amazon Bedrock: Das vertrauenswürdige KI-Fundament

Amazon Bedrock ist eine vollständig verwaltete, serverlose Foundation-Model-Schicht, die vollständig in der AWS-Umgebung des Kunden läuft. Kundendaten verbleiben im AWS-Account des Kunden. Eingaben und Ausgaben sind während der Übertragung und im Ruhezustand verschlüsselt, werden nie mit Modellanbietern geteilt und nie zum Training von Basismodellen verwendet. Bedrock verfügt über Compliance-Zertifizierungen für DSGVO und BSI C5, die viele Anforderungen regulierter Branchen abdecken. Teams können außerdem eigene feinabgestimmte Modelle über Custom Model Import einbinden und gemeinsam mit nativen Bedrock-Modellen über dieselbe Infrastruktur betreiben – ohne separate Deployment-Pipelines. Bedrock Guardrails ergänzt konfigurierbare Schutzmaßnahmen über alle Modelle hinweg: Content-Filterung, Halluzinationserkennung und Schutz sensibler Daten.

Gemeinsam konsolidieren GitLab Duo Agent Platform und Bedrock DevSecOps-Orchestrierung und KI-Modell-Governance – und helfen dabei, die Fragmentierung zu vermeiden, die entsteht, wenn Teams KI-Werkzeuge eigenständig einführen.

Die passende Deployment-Variante wählen

Die Integration liefert dieselben Kernfunktionen von GitLab Duo Agent Platform, unabhängig von der gewählten Deployment-Variante. Was variiert, ist: Wer betreibt GitLab, wer betreibt den AI Gateway, und in welchem Bedrock-Account läuft die Inferenz? Die passende Variante hängt davon ab, wo das Unternehmen bereits operiert.

Die Integration umfasst drei Hauptkomponenten:

• GitLab Duo Agent Platform: Agentische Workflows, eingebettet in den gesamten Software-Lifecycle
• AI Gateway (GitLab-verwaltet oder selbst gehostet): Die Abstraktionsschicht zwischen Duo Agent Platform und dem Foundation-Model-Backend
• Amazon Bedrock: KI-Modell- und Inferenzsubstrat

Die Wahl der Deployment-Variante richtet sich danach, wo das Unternehmen die Steuerungshebel platzieren möchte. Die folgenden Varianten sind so konzipiert, dass sie Teams dort abholen, wo sie bereits stehen – ob SaaS-first, Self-Managed aus Compliance-Gründen oder vollständig auf AWS mit bestehenden Bedrock-Investitionen.

Praxiseinsatz von GitLab Duo Agent Platform mit Amazon Bedrock

Plattformteams können GitLab Duo Agent Platform mit Amazon Bedrock nutzen, um zentral festzulegen, welche Modelle Code-Vorschläge, Sicherheitsanalysen und Pipeline-Remediation übernehmen. So lassen sich Schutzmaßnahmen und Protokollierung zentral durchsetzen, statt einzelnen Teams die eigenständige Einführung separater Werkzeuge zu überlassen.

Security-Workflows profitieren besonders. GitLab Duo Agent Platform-Agenten können Fixes für Security Findings innerhalb von GitLab vorschlagen und validieren – und so den manuellen Triage-Aufwand reduzieren, den Entwicklungsteams sonst außerhalb der Plattform leisten müssten.

Für Unternehmen mit bestehenden AWS-Commitments lässt sich die KI-Nutzung so mit bestehenden Cloud-Vereinbarungen in Einklang halten. Separate, ungeplante Ausgaben entfallen.

Der Kreislauf schließt sich

Die Hindernisse, die Enterprise-KI-Adoption verlangsamen, sind oft nicht technischer Natur. Sie sind organisatorischer Natur: fragmentiertes Tooling, nicht nachverfolgbare Datenflüsse und Cloud-Ausgaben, die sich nie konsolidieren. Diese Probleme können KI-Programme zum Stillstand bringen, selbst nachdem Pilotprojekte erfolgreich waren.

GitLab Duo Agent Platform und Amazon Bedrock adressieren jeden dieser Punkte direkt. Plattformteams erhalten konsistente Governance, Auditierbarkeit und standardisierte Pfade für die KI-Nutzung über den gesamten Software-Lifecycle. Entwicklungsteams erhalten optimierte, agentische Workflows, die sich nativ in GitLab anfühlen. Und AWS-zentrierte Unternehmen können ihre bestehende Bedrock-Investition erweitern, statt parallel dazu eine separate KI-Infrastruktur aufzubauen.

Das Ergebnis ist ein KI-Programm, das skaliert, ohne zu fragmentieren. Governance und Entwicklungsgeschwindigkeit auf demselben Stack, für dieselben Teams, unter Richtlinien, die das Unternehmen bereits besitzt.

Um die passende Deployment-Variante zu identifizieren und GitLab Duo Agent Platform und Amazon Bedrock mit der bestehenden AWS-Strategie in Einklang zu bringen, steht das GitLab Sales-Team zur Verfügung – für Architekturberatung und Implementierungsunterstützung. Weitere Informationen bietet auch die AWS-Partnerseite.

Pluggable Object Databases

Git bietet bereits die Möglichkeit, Referenzen entweder mit dem "files"-Backend oder dem "reftable"-Backend zu speichern. Dies wird durch geeignete Abstraktionen in Git ermöglicht, die verschiedene Backends zulassen.

Referenzen sind aber nur einer der beiden wichtigen Datentypen, die in Repositories gespeichert werden – der andere sind Objekte. Objekte werden in der Object Database gespeichert, und jede Object Database wiederum besteht aus mehreren Objektquellen, aus denen Objekte gelesen oder in die geschrieben werden kann. Jede Objektquelle speichert einzelne Objekte entweder als sogenannte "Loose"-Objekte oder komprimiert mehrere Objekte in ein "Packfile" im Verzeichnis .git/objects.

Bisher hatten diese Quellen jedoch keine echte Abstraktionsschicht, sodass das Speicherformat für Objekte komplett in Git fest verdrahtet war. Das ändert sich nun endlich mit Pluggable Object Databases! Das Konzept ist unkompliziert und ähnlich wie bei Referenzen: Statt fest verdrahteter Codepfade für die Objektspeicherung wird eine Abstraktionsschicht eingeführt, die verschiedene Backends für die Objektspeicherung ermöglicht.

Obwohl die Idee einfach ist, ist die Umsetzung komplex, da es überall in Git fest verdrahtete Annahmen über die verwendeten Speicherformate gibt. Die Arbeit an diesem Thema begann bereits mit Git 2.48, das im Januar 2025 veröffentlicht wurde. Der anfängliche Fokus lag darauf, objektbezogene Subsysteme eigenständig zu machen und geeignete Subsysteme für die bestehenden Backends in Git zu erstellen.

Mit Git 2.54 wurde nun ein Meilenstein erreicht: Das Object-Database-Backend ist jetzt pluggable. Noch wird nicht die gesamte Funktionalität von Git abgedeckt, aber die Einführung eines alternativen Backends, das eine sinnvolle Teilmenge der Operationen verarbeitet, ist jetzt ein realistisches Unterfangen.

Derzeit funktionieren nur lokale Workflows wie das Erstellen von Commits, das Anzeigen von Commit-Graphen oder das Durchführen von Merges mit einer solchen alternativen Implementierung. Ausgenommen ist insbesondere alles, was mit einem Remote interagiert, zum Beispiel beim Fetchen oder Pushen von Änderungen. Dennoch ist dies das Ergebnis von fast zwei Jahren Arbeit über fast 400 Commits, die Upstream gemergt wurden, und die Arbeit daran wird natürlich fortgesetzt.

Warum ist das relevant? Die Idee ist, dass es praktikabel wird, neue Speicherformate in Git einzuführen. Beispiele könnten sein:

• Ein Speicherformat, das große Binärdateien effizienter speichern kann als es Packfiles heute tun
• Ein Speicherformat, das speziell auf GitLab zugeschnitten ist, um Repositories noch effizienter bereitstellen zu können

Dies ist ein groß angelegtes Vorhaben, das die Zukunft von Git und GitLab maßgeblich prägen dürfte.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Einfachere Bearbeitung der Commit-Historie

In vielen Softwareentwicklungsprojekten ist es gängige Praxis, nicht nur den Code zu verfeinern, sondern auch die Commit-Historie zu bereinigen, damit sie leicht überprüfbar ist. Das Ergebnis ist eine Reihe kleiner, atomarer Commits, die jeweils eine Sache tun, mit einer guten Commit-Nachricht, die die Intention des Commits sowie spezifische Nuancen beschreibt.

Natürlich entstehen diese atomaren Commits meist nicht einfach von selbst während des Entwicklungsprozesses. Stattdessen gewinnt die Person, die die Änderungen erstellt, durch Iteration ein besseres Verständnis dafür, und die Art und Weise, die Commits aufzuteilen, wird mit der Zeit klarer. Darüber hinaus kann der anschließende Review-Prozess zu Feedback führen, das Änderungen an den erstellten Commits erfordert.

Die Konsequenz dieses Prozesses ist, dass die Commit-Historie im Laufe der Entwicklung viele Male umgeschrieben werden muss. Historisch hat Git dafür interaktive Rebases vorgesehen. Diese interaktiven Rebases sind ein extrem leistungsfähiges Werkzeug: Sie ermöglichen es, Commits umzuordnen, Commit-Nachrichten umzuschreiben, mehrere Commits zusammenzufassen oder beliebige Bearbeitungen an jedem Commit vorzunehmen.

Allerdings sind sie auch etwas kryptisch und schwer zu verstehen. Man muss den Basis-Commit für den Rebase bestimmen, verstehen, wie ein etwas obskures "Instruction Sheet" zu bearbeiten ist, und sich mit dem zustandsbehafteten Rebase-Prozess auskennen. Zum Beispiel wird beim Rebase eines Topic-Branch ein Instruction Sheet wie das folgende angezeigt:

pick b60623f382 # t: detect errors outside of test cases # empty
pick b80cb55882 # t: prepare `test_match_signal ()` calls for `set -e`
pick 5ffe397f30 # t: prepare `test_must_fail ()` for `set -e`
pick 5e9b0cf5e1 # t: prepare `stop_git_daemon ()` for `set -e`
pick 299561e7a2 # t: prepare `git config --unset` calls for `set -e`
pick ed0e7ca2b5 # t: detect errors outside of test cases

Interaktive Rebases sind also zwar leistungsfähig, aber auch ziemlich einschüchternd für durchschnittliche Nutzende.

Das muss aber nicht so sein. Tools wie Jujutsu bieten Interfaces, die im Vergleich zu Git deutlich einfacher zu benutzen sind – zum Beispiel kann man einfach jj split ausführen, um einen Commit in zwei aufzuteilen. Bei Git mit interaktiven Rebases erfordert dieser Anwendungsfall viele verschiedene Schritte mit verwirrenden Befehlszeilenargumenten.

Inspiriert von Jujutsu wurde daher ein neuer Befehl git-history(1) in Git eingeführt, der die Grundlage für eine bessere Bearbeitung der Historie bildet. Derzeit hat dieser Befehl zwei Unterbefehle:

• git history reword ermöglicht das einfache Umschreiben einer Commit-Nachricht. Man gibt den Commit an, dessen Nachricht umformuliert werden soll, Git fragt nach der neuen Commit-Nachricht, und das war's.
• git history split ermöglicht das Aufteilen eines Commits in zwei, inspiriert von jj split. Man gibt einen Commit an, Git fragt, welche Änderungen in welchen Commit aufgenommen werden sollen und nach den beiden Commit-Nachrichten, und dann ist man fertig.

Das ist natürlich erst der Anfang, und im Laufe der Zeit sollen weitere Unterbefehle hinzukommen. Zum Beispiel:

• git history fixup um gestagete Änderungen automatisch in einen bestimmten Commit einzufügen
• git history drop um einen Commit zu entfernen
• git history reorder um die Reihenfolge von Commits zu ändern
• git history squash um eine Reihe von Commits zusammenzufassen

Aber das ist noch nicht alles! Zusätzlich zur einfachen Bearbeitung der Historie kann dieser neue Befehl auch automatisch alle lokalen Branches rebasen, die den bearbeiteten Commit zuvor enthielten. Das bedeutet, man kann sogar einen Commit bearbeiten, der nicht auf dem aktuellen Branch liegt, und alle Branches, die den Commit enthalten, werden umgeschrieben.

Es mag zunächst überraschend erscheinen, dass Git automatisch abhängige Branches rebast, da dies eine deutliche Abweichung von der Funktionsweise von git-rebase(1) darstellt. Dies ist aber Teil eines größeren Vorhabens, um bessere Unterstützung für Stacked Diffs in Git zu bringen – eine Methode, eine Reihe mehrerer abhängiger Branches zu erstellen, die unabhängig voneinander überprüft werden können, aber gemeinsam auf ein größeres Ziel hinarbeiten.

Dieses Projekt wurde von Patrick Steinhardt mit Unterstützung von Elijah Newren geleitet.

Ein nativer Ersatz für git-sizer(1)

Die Größe eines Git-Repositorys ist ein wichtiger Faktor, der bestimmt, wie gut Git und GitLab damit umgehen können. Aber die Größe allein ist nicht der einzige Faktor, da die Performance eines Repositorys letztlich eine Kombination aus mehreren verschiedenen Dimensionen ist:

• Die Tiefe der Commit-Historie
• Die Struktur des Verzeichnisbaums
• Die Größe der im Repository gespeicherten Dateien
• Die Anzahl der Referenzen

Das sind nur einige der Dimensionen, die berücksichtigt werden müssen, wenn man vorhersagen will, ob Git ein Repository gut verarbeiten kann.

Obwohl klar ist, dass die reine Repository-Größe nicht ausreicht, bietet Git selbst keine Tools, die einen einfachen Überblick über diese Metriken geben. Stattdessen ist man auf Drittanbieter-Tools wie git-sizer(1) angewiesen, um diese Lücke zu füllen. Dieses Tool leistet hervorragende Arbeit bei der Darstellung dieser Informationen, ist aber kein Bestandteil von Git und muss daher separat installiert werden.

Observability von Repository-Interna ist bei GitLab entscheidend, daher wurde in Git 2.52 ein neuer git repo structure-Befehl eingeführt, um Repository-Metriken anzuzeigen, der in Git 2.53 erweitert wurde, um inflated und Disk-Sizes für Objekte nach Typ anzuzeigen.

In Git 2.54 wird dieser Befehl weiter ausgebaut, sodass nicht nur die Gesamtgröße angezeigt wird, sondern auch die größten Objekte nach Typ:

$ git clone https://gitlab.com/git-scm/git.git
$ cd git
$ git repo structure
Counting objects: 410445, done.
| Repository structure      | Value       |
| ------------------------- | ----------- |
| * References              |             |
|   * Count                 |    1.01 k   |
|     * Branches            |       1     |
|     * Tags                |    1.00 k   |
|     * Remotes             |       9     |
|     * Others              |       0     |
|                           |             |
| * Reachable objects       |             |
|   * Count                 |  410.45 k   |
|     * Commits             |   83.99 k   |
|     * Trees               |  164.46 k   |
|     * Blobs               |  161.00 k   |
|     * Tags                |    1.00 k   |
|   * Inflated size         |    7.46 GiB |
|     * Commits             |   57.53 MiB |
|     * Trees               |    2.33 GiB |
|     * Blobs               |    5.07 GiB |
|     * Tags                |  737.48 KiB |
|   * Disk size             |  181.37 MiB |
|     * Commits             |   33.11 MiB |
|     * Trees               |   40.58 MiB |
|     * Blobs               |  107.11 MiB |
|     * Tags                |  582.67 KiB |
|                           |             |
| * Largest objects         |             |
|   * Commits               |             |
|     * Maximum size    [1] |   17.23 KiB |
|     * Maximum parents [2] |      10     |
|   * Trees                 |             |
|     * Maximum size    [3] |   58.85 KiB |
|     * Maximum entries [4] |    1.18 k   |
|   * Blobs                 |             |
|     * Maximum size    [5] | 1019.51 KiB |
|   * Tags                  |             |
|     * Maximum size    [6] |    7.13 KiB |

[1] f6ecb603ff8af608a417d7724727d6bc3a9dbfdf
[2] 16d7601e176cd53f3c2f02367698d06b85e08879
[3] 203ee97047731b9fd3ad220faa607b6677861a0d
[4] 203ee97047731b9fd3ad220faa607b6677861a0d
[5] aa96f8bc361fd84a1459440f1e7de02ab0dc3543
[6] 07e38db6a5a03690034d27104401f6c8ea40f1fc

Mit diesen Informationen ist die Funktionsparität mit git-sizer(1) nahezu erreicht. Ganz fertig ist die Arbeit aber noch nicht – geplant sind weitere Features wie:

• Severity Levels wie sie in git-sizer(1) existieren
• Graphen, die die Verteilung der Objektgrößen visualisieren
• Die Möglichkeit, Objekte zu scannen, die über eine Teilmenge von Referenzen erreichbar sind

Dieses Projekt wurde von Justin Tobler geleitet.

Neue Infrastruktur für Repository-Wartung

Beim Schreiben von Daten in ein Git-Repository entstehen in der Regel weitere Loose-Objekte. Ohne Verwaltung führt dies zu einer großen Anzahl separater Dateien im Verzeichnis .git/objects/, was mehrere Operationen verlangsamt, die auf viele Objekte gleichzeitig zugreifen wollen. Git packt diese Objekte daher regelmäßig in "Packfiles", um eine gute Performance sicherzustellen.

Das ist aber nicht die einzige Datenstruktur, die im Laufe der Zeit ineffizient werden kann: Das Aktualisieren von Referenzen kann Loose-Referenzen erzeugen, Reflogs müssen getrimmt, Worktrees können veralten, und Caches wie Commit-Graphen müssen regelmäßig aktualisiert werden.

All diese Aufgaben wurden historisch von git-gc(1) verwaltet. Dieses Tool hat jedoch eine monolithische Architektur, in der es im Grunde alle erforderlichen Aufgaben sequenziell ausführt. Diese Grundlage ist schwer erweiterbar und bietet wenig Flexibilität, wenn die Wartung leicht angepasst werden soll.

Das Git-Projekt führte in Git 2.29 das neue Tool git-maintenance(1) ein. Im Gegensatz zu git-gc(1) ist git-maintenance(1) nicht monolithisch, sondern um Tasks herum strukturiert. Diese Tasks sind frei konfigurierbar, sodass kontrolliert werden kann, welche Tasks ausgeführt werden, was eine deutlich feinere Kontrolle über die Repository-Wartung ermöglicht.

Schließlich wurde Git standardmäßig auf git-maintenance(1) umgestellt. Zu Beginn war allerdings der einzige standardmäßig aktivierte Task der git-gc(1)-Task, der – wie der Name vermuten lässt – einfach git gc ausführt. Um die Wartung manuell mit dem neuen Befehl auszuführen, kann git maintenance run aufgerufen werden, aber Git führt dies auch automatisch nach verschiedenen anderen Befehlen aus.

In den letzten Releases wurden alle einzelnen Tasks implementiert, die von git-gc(1) unterstützt werden, auch in git-maintenance(1), um Funktionsparität zwischen den beiden Tools sicherzustellen.

Darüber hinaus wurde ein neuer Task implementiert, der Gits moderne Architektur für das Repacking von Objekten mit Geometric Compaction nutzt. Geometric Compaction eignet sich deutlich besser für große Monorepos, und mit den Arbeiten zur Kompatibilität mit Partial Clones, die in Git 2.53 eingeflossen sind, stellen sie jetzt einen vollständigen Ersatz für die bisherige Repacking-Strategie in Git dar.

Mit Git 2.54 wurde nun ein weiterer bedeutender Meilenstein erreicht: Statt der bisherigen git-gc(1)-basierten Strategie wird jetzt standardmäßig Geometric Repacking mit feingranularen individuellen Wartungs-Tasks verwendet! Neben der höheren Effizienz für große Monorepos stellt dies auch eine einfachere Grundlage für zukünftige Weiterentwicklungen sicher.

Die git-maintenance(1)-Infrastruktur wurde ursprünglich von Derrick Stolee implementiert, und Geometric Maintenance wurde von Taylor Blau eingeführt. Die Arbeit zur Einführung der neuen feingranularen Tasks und die Migration zur neuen Wartungsstrategie wurde von Patrick Steinhardt geleitet.

Weiterlesen

Dieser Artikel hat nur einige der Beiträge hervorgehoben, die von GitLab und der breiteren Git-Community zu diesem aktuellen Release geleistet wurden. Weitere Informationen dazu finden sich in der offiziellen Release-Ankündigung des Git-Projekts. Außerdem lohnt sich ein Blick in die früheren Git-Release-Blogposts, um weitere vergangene Highlights der Beiträge von GitLab-Teammitgliedern zu sehen.

Die Verteidigungsseite hat nicht Schritt gehalten. Ein Drittel der ausgenutzten CVEs im ersten Halbjahr 2025 zeigte Aktivität vor oder am Tag der Offenlegung – bevor die meisten Teams überhaupt wissen, dass es etwas zu patchen gibt. KI komprimiert dieses Fenster weiter, beschleunigt Angreifer und überschwemmt Teams mit Whitehat-Meldungen schneller, als sie triagiert werden können. Defender-Werkzeuge haben sich verbessert, doch die meisten Unternehmen können sie nicht schnell genug operationalisieren, um die Lücke zwischen Entdeckung und Ausnutzung zu schließen.

Wenn das Fenster zwischen Offenlegung und Ausnutzung in Stunden gemessen wird, kann das Sicherheitsteam nicht die letzte Verteidigungslinie sein. Sicherheit muss dort greifen, wo Code in das System eintritt: in der Pipeline, bei jedem Merge Request, durch Richtlinien durchgesetzt. Was automatisiert werden kann, sollte automatisiert werden. Was es nicht kann, muss schneller als heute den richtigen Menschen erreichen.

Bekannte Schwachstellen übersteigen bereits die Remediation-Kapazitäten

Der Engpass ist nicht die Erkennung – sondern das Handeln im erforderlichen Umfang auf Basis bereits bekannter Informationen. 60 % der Sicherheitsverletzungen im Verizon DBIR 2025 betrafen die Ausnutzung bekannter Schwachstellen, für die bereits ein Patch verfügbar war. Teams konnten sie nicht rechtzeitig schließen.

Der Rückstand war bereits vor Mythos untragbar. Entwicklungsteams verbringen 11 Stunden pro Monat mit der Behebung von Schwachstellen nach dem Release – statt neue Funktionen zu liefern. Über die Hälfte der Unternehmen hat mindestens eine internetexponierte Schwachstelle offen, und der mediane Zeitraum zur Schließung der Hälfte dieser Schwachstellen beträgt 361 Tage. Ausnutzung dauert Stunden, Remediation dauert Monate.

KI-gestützte Entwicklung vergrößert die Lücke – und Verantwortliche sind sich dessen bewusst. Bis Juni 2025 fügte KI-generierter Code über 10.000 neue Security-Findings pro Monat in Fortune-50-Repositories hinzu – ein zehnfacher Anstieg gegenüber sechs Monaten zuvor. Georgia Tech identifizierte im März 2026 34 CVEs mit nachweisbarem KI-Ursprung, gegenüber 6 im Januar. Diese Zahl erfasst nur die Fälle, in denen die KI-Urheberschaft eindeutig nachweisbar ist. KI-Coding-Assistenten halluzinieren Paketnamen, greifen auf veraltete Muster zurück und kopieren unsichere Beispiele aus Trainingsdaten. Mehr Code, mehr Abhängigkeiten und mehr Schwachstellen pro Zeile werden schneller erzeugt, als Sicherheitsteams sie prüfen können.

Verteidiger müssen sich ebenfalls frontier KI-Modelle zunutze machen – nicht als externe Werkzeuge, die nachträglich an den SDLC angedockt werden, sondern als integrale Bestandteile derselben Richtlinien, Freigaben und Audit-Trails wie der Rest des Teams.

Sicherheit im Tempo von KI-gestützter Entwicklung

Wenn eine kritische CVE bekannt wird: Wie schnell kann das Team bestätigen, welche Projekte betroffen sind? Wie viele Werkzeugwechsel durchläuft ein Alert, bevor ein Entwickler mit der Behebung beginnen kann?

Teams, die am meisten von KI profitieren, haben Richtlinien, Durchsetzungsmechanismen und Kontrollen bereits in ihre Entwicklungs-Workflows eingebettet. KI verstärkt dieses Fundament. Sie ersetzt es nicht.

Durchsetzung am Punkt der Änderung. Wenn Ausnutzungsfenster schrumpfen, muss jede Codezeile, die in ein Repository eingeht, einen definierten Kontrollsatz durchlaufen – keine separate Prüfung, in einem anderen Werkzeug, durch ein anderes Team. Unternehmen benötigen die Möglichkeit, Sicherheitsrichtlinien über alle Gruppen und Projekte hinweg durchzusetzen, mit dem Merge Request als Durchsetzungspunkt. Richtlinien einmal definiert, überall angewendet, Ausnahmen geprüft, genehmigt und protokolliert.

Einfache Probleme vor dem Merge Request abfangen. Hardcodierte Secrets, bekannt-vulnerable Importe und veraltete API-Aufrufe können in der IDE markiert werden, bevor ein Commit gepusht wird. Das Abfangen zum Zeitpunkt der Erstellung bedeutet weniger Findings, die den MR blockieren – so dass Review-Zyklen für Findings reserviert bleiben, die komponentenübergreifenden Kontext erfordern: Erreichbarkeit, Ausnutzbarkeit und architektonisches Risiko.

Triage standardmäßig automatisiert. Sicherheit in jeden Merge Request einzubetten erzeugt ein Volumenproblem. Mehr Scans, mehr Findings, mehr Lärm erreicht Entwicklungsteams, die nicht geschult sind, eine erreichbare kritische Schwachstelle von einer theoretischen zu unterscheiden. KI muss False-Positive-Erkennung, Erreichbarkeit, Ausnutzbarkeitskontext und Schweregradbewertung übernehmen, bevor ein Entwickler das Finding sieht – damit die Findings, die ihn erreichen, tatsächlich seine Zeit rechtfertigen.

Remediation wie jede andere Änderung verwaltet. KI-gestützte Remediation komprimiert den Zeitrahmen zum Schließen von Schwachstellen, aber jeder generierte Fix muss denselben Governance-Prozess durchlaufen wie eine menschlich erstellte Änderung: Richtlinien erzwingen Scans, die richtigen Prüfer genehmigen, und Nachweise werden aufgezeichnet. GitLabs automatisierte Remediation schlägt jeden Fix in einem Merge Request mit einem Konfidenzwert vor. Der MR dokumentiert, welche Richtlinie angewendet wurde, welche Scans durchgeführt wurden, was sie gefunden haben und wer genehmigt hat. Menschlich erstellter Code und KI-generierter Code durchlaufen denselben Prozess – mit demselben Audit-Trail.

So sieht eine vorbereitete Pipeline aus

Ein Proof-of-Concept-Exploit für eine Schwachstelle in einem verbreiteten Open-Source-Paket erscheint auf einer Security-Mailingliste. Es gibt noch keine CVE, keinen NVD-Eintrag und keine Scanner-Signatur. Das Sicherheitsteam erfährt es auf dem üblichen Weg: jemand teilt es in Slack.

Ein Security-Engineer fragt den Security-Agenten, ob das Paket verwendet wird, welche Projekte betroffene Versionen haben und ob verwundbare Call-Pfade in der Produktion erreichbar sind. Der Agent prüft den Dependency-Graphen jedes Projekts, gleicht die betroffenen Versionen und Einstiegspunkte aus der Meldung ab und gibt eine priorisierte Liste exponierter Projekte mit Details zur Erreichbarkeit zurück. Eine manuelle Suche in Repositories oder das Warten auf ein Scanner-Update entfällt. Die Frage „Sind wir betroffen?" ist in Minuten beantwortet.

Der Engineer startet eine Remediation-Kampagne für alle exponierten Projekte. Der Remediation-Agent schlägt Fixes vor: Versions-Updates, wo ein gepatchtes Release verfügbar ist, und Patches für verwundbare Call-Pfade, wo es keines gibt. Scan-Execution-Policies sind bereits für Projekte mit ISO-27001-Zertifizierung aktiv. Der Engineer verschärft die Regeln, um Merges bei jedem Merge Request zu blockieren, der die betroffene Abhängigkeit einführt oder beibehält. Eine Approval-Policy erfordert nun Security-Freigabe für jeden Fix. Der erste vorgeschlagene Patch schlägt in der Pipeline fehl, weil ein Integrationstest eine Regression aufdeckt. Der Agent überarbeitet den Patch auf Basis des Testergebnisses, der zweite Versuch besteht. Das Entwicklungsteam prüft die Änderungen, Security gibt unter der verschärften Richtlinie frei, und Merges erfolgen über die gesamte Kampagne hinweg.

Beim nächsten Audit-Review legt das Sicherheitsteam einen Bericht vor, der zeigt, wie Richtlinien durchgesetzt und Risiken während der Kampagne reduziert wurden. Er enthält Scan-Ergebnisse, angewendete Richtlinien, Genehmiger und Merge-Zeitstempel für jeden MR in jedem betroffenen Projekt. Die Nachweise wurden automatisch während des Prozesses erzeugt – nicht im Nachhinein zusammengestellt.

Handlungsfelder jetzt identifizieren

Mythos existiert heute, und vergleichbare Modelle werden innerhalb eines Jahres in Angreiferhänden sein. Jeder Monat bis dahin ist eine Gelegenheit, die Software-Lieferkette zu stärken.

Diese Fragen zeigen, wo die Pipeline steht:

• Wie wird sichergestellt, dass Sicherheitsscans bei jedem Merge Request durchgeführt werden – nicht nur in Projekten, in denen Teams sie konfiguriert haben?
• Wenn ein kompromittiertes Paket heute in den Dependency-Tree eingeht – würde die Pipeline es vor dem Build abfangen?
• Wenn ein Scanner ein kritisches Finding meldet: Wie viele Werkzeugwechsel durchläuft es, bevor ein Entwickler mit der Behebung beginnt?
• Wenn ein KI-Agent einen Code-Fix für eine Schwachstelle vorschlägt – welchen Prozess durchläuft dieser Fix vor dem Erreichen der Produktion, und ist dieser Prozess auditierbar?
• Wenn Auditoren den Nachweis verlangen, dass eine bestimmte Richtlinie auf eine bestimmte Änderung angewendet wurde – wie lange dauert die Bereitstellung?

Wo diese Fragen Lücken aufzeigen, empfiehlt sich gezielte Maßnahmen. Mit einem GitLab Solutions Architect sprechen – zur Rolle von Security-Governance im Entwicklungs-Lifecycle.

Für Unternehmen in regulierten Branchen wirft diese Änderung Fragen auf, die über individuelle Entwicklerpräferenzen weit hinausgehen. Sie zwingt zu einer grundlegenden Prüfung, die Führungskräfte aus Engineering und IT-Sicherheit jedem KI-Anbieter in ihrem Stack stellen sollten: Werden unsere Daten für KI-Training verwendet?

GitLabs Antwort lautet: Nein. GitLab trainiert KI-Modelle nicht mit Kundendaten – auf keiner Preisstufe. KI-Anbieter sind vertraglich verpflichtet, Kundeneingaben und -ausgaben nicht für eigene Zwecke zu verwenden. Das GitLab AI Transparency Center macht diese Zusage prüfbar. Eine zentrale Dokumentation zeigt, welche Modelle welche Funktionen betreiben, wie Daten verarbeitet werden, welche Unterauftragsverarbeiter beteiligt sind und wie lange Daten gespeichert werden. Das AI Transparency Center dokumentiert außerdem den Compliance-Status jeder Funktion – einschließlich der Bestätigung, dass GitLabs aktuelle KI-Funktionen nicht als Hochrisikosysteme im Sinne des EU AI Act eingestuft werden. Diesen Standard hat GitLab-CEO Bill Staples wiederholt bekräftigt – er spiegelt GitLabs Unternehmensmission und das Trust Center wider.

Was die Richtlinienänderung tatsächlich bedeutet

GitHub gibt zudem an, dass die Daten mit verbundenen Unternehmen – darunter Microsoft – für KI-Entwicklungszwecke geteilt werden können.

Quellcode zählt häufig zum sensibelsten geistigen Eigentum eines Unternehmens. Er kann proprietäre Geschäftslogik abbilden, interne Systemarchitekturen offenlegen oder Datenflüsse berühren, die strengen Aufbewahrungs- und Zugriffsrichtlinien unterliegen. Wenn dieser Code einen KI-Assistenten durchläuft und zum Training von Modellen verwendet wird, die auch Wettbewerbern dienen, werden Anbieterdatenpraktiken zu einem konkreten IP-Risiko. Regulierte Branchen weltweit – von Finanzdienstleistungen über Gesundheitswesen bis zum öffentlichen Sektor – operieren unter Compliance-Anforderungen, die genau diesen Punkt adressieren: dokumentierte, prüfbare Kontrolle über den Umgang Dritter mit sensiblen Daten.

Eine Anbieterrichtlinie, die Datenstandardeinstellungen ändert, ein aktives Widerspruchsrecht erfordert und je nach Vertragsstufe unterschiedliche Schutzstandards bietet, erzeugt genau die Art unkontrollierbarer Variablen, die Compliance-Teams nicht akzeptieren können. Der Digital Operational Resilience Act (DORA) – seit Januar 2025 für europäische Finanzinstitute verbindlich – macht dies explizit: Wesentliche Änderungen an IT-Drittanbieterbeziehungen erfordern dokumentierte Bewertung und Nachverfolgung.

Was regulierte Unternehmen von KI-Anbietern tatsächlich benötigen

Regulierte Unternehmen diskutieren nicht mehr grundsätzlich, ob KI in Entwicklungs-Workflows eingesetzt werden soll. Der Fokus liegt darauf, dies so zu tun, dass es gegenüber Aufsichtsbehörden, Vorständen und Kunden vertretbar ist. Dabei sind branchenübergreifend konsistente Anforderungen sichtbar geworden.

Vertragliche Klarheit. Regulierte Unternehmen benötigen spezifische, dokumentierte und bedingungslose Zusagen darüber, was mit ihren Daten geschieht – nicht etwas, das je nach Vertragsstufe variiert oder eine Handlung vor einem Stichtag erfordert.

Prüfbarkeit. IT-Risikomanagement-Frameworks verlangen von Unternehmen, die eingesetzten KI-Systeme zu verstehen und zu validieren: die Trainingsdaten hinter diesen Modellen und die beteiligten Drittparteien. Anbieter, die diese Fragen nicht beantworten können, erzeugen Dokumentationsrisiken für die Organisationen, die sich auf sie stützen.

Trennung von Anbieterinteressen. Wenn ein KI-Anbieter Modelle auf Basis von Kundennutzungsdaten trainiert, werden Code und Workflows zu Eingaben für ein System, das auch Wettbewerbern dient. Für Institutionen mit proprietären Handelsalgorithmen, Underwriting-Modellen oder Betrugserkennungssystemen ist das ein konkretes IP-Risiko.

GitLabs Position zur KI-Datenverwaltung

GitLab verwendet Kundendaten nicht zum Training von KI-Modellen. Diese Zusage gilt auf jeder Preisstufe; KI-Anbieter sind vertraglich verpflichtet, Eingaben und Ausgaben, die mit GitLab-Kunden verbunden sind, nicht für eigene Zwecke zu verwenden.

Dies ist eine bewusste architektonische und richtlinienbezogene Entscheidung – kein Merkmal einer bestimmten Preisstufe. Wie GitLabs Beitrag zur Enterprise-Unabhängigkeit festhält, ist Datenverwaltung zu einem "zunehmend kritischen Faktor bei Unternehmensentscheidungen" geworden – getrieben durch nationale und regionale Datenschutzgesetze und wachsende Bedenken hinsichtlich der Kontrolle über sensibles geistiges Eigentum.

GitLab ist cloud-neutral und modell-neutral und unterstützt Self-Hosted-Deployments ohne kommerzielle Bindung an einen einzelnen Cloud-Anbieter oder ein Large Language Model. Diese Unabhängigkeit ist für regulierte Unternehmen relevant, die Risiken durch Anbieterkonzentration bewerten. Der AI Continuity Plan dokumentiert, wie Anbieterveränderungen gehandhabt werden – einschließlich wesentlicher Änderungen daran, wie KI-Anbieter Kundendaten behandeln. Er ist eine direkte Antwort auf die Governance-Anforderungen unter Frameworks wie DORA.

Die Governance-Lücke, die KI-Teams schließen müssen

GitHubs Richtlinienaktualisierung macht deutlich: Für Unternehmen in regulierten Branchen ist das genaue Verständnis des Datenumgangs eines KI-Werkzeugs eine Voraussetzung für dessen Einsatz. Das bedeutet, Anbietern klare, dokumentierte Antworten auf folgende Fragen abzuverlangen:

1. Werden unsere Daten zum Training von KI-Modellen verwendet?
2. Wer sind Ihre KI-Modell-Unterauftragsverarbeiter?
3. Was geschieht, wenn ein Anbieter seine Datenpraktiken ändert?
4. Lässt sich ein Deployment realisieren, das alle KI-Verarbeitung innerhalb der eigenen Infrastruktur hält?
5. Welche Haftungsübernahme wird für KI-generierte Ausgaben angeboten?

Anbieter, die diese Fragen klar beantworten und die Antworten in prüfbarer Form dokumentieren, sind Anbieter, auf die sich aufbauen lässt. Wer das nicht kann, schafft Compliance-Risiken bei jedem Policy-Update. Wenn ein Anbieter Datenpraktiken mit 30 Tagen Ankündigungsfrist ändern kann, ist das kein partnerschaftlicher Rahmen für regulierte Unternehmen – das ist ein strukturelles Compliance-Risiko.

Mehr zu GitLabs Ansatz für KI-Governance im GitLab AI Transparency Center.

Eine wesentliche Hürde bei der breiteren KI-Einführung ist nicht Skepsis gegenüber der Technologie. Es ist die Unsicherheit bei der Kostenkontrolle. Ohne Ausgabeobergrenzen kann ein arbeitsintensiver Monat zu unerwarteten Kosten führen. Ohne Nutzerlimits können wenige Intensivnutzende das Credit-Kontingent des gesamten Teams aufbrauchen, bevor der Monat endet. Und ohne beides müssen Engineering-Verantwortliche, die Agentic AI weiter ausrollen wollen, aufwändigere Budgetgenehmigungsprozesse durchlaufen.

Seit der allgemeinen Verfügbarkeit bietet GitLab Duo Agent Platform bereits Nutzungs-Governance und Transparenz. Mit GitLab 18.11 kommen Verbrauchssteuerung für GitLab Credits hinzu: Ausgabeobergrenzen und Budgetlimits, die Organisationen noch mehr Kontrolle und Transparenz über den Credit-Verbrauch geben.

GitLab Credits steuern

GitLab 18.11 führt drei Steuerungsebenen für den GitLab-Credits-Verbrauch ein: eine Ausgabenobergrenze auf Abonnementebene, Nutzerlimits auf individueller Ebene sowie Einblick in den Status und die Durchsetzung beider Limits.

Ausgabenobergrenze auf Abonnementebene

Billing Account Manager können ab sofort eine monatliche Höchstgrenze für den Verbrauch von On-Demand GitLab Credits des gesamten Abonnements festlegen.

Funktionsweise:

• Limit festlegen im Customers Portal unter den GitLab-Credits-Einstellungen des Abonnements.
• Ausgaben automatisch begrenzen. Erreicht der On-Demand-Verbrauch die Obergrenze, wird der DAP-Zugriff für alle Nutzenden des Abonnements pausiert – bis die nächste monatliche Periode beginnt.
• Anpassungen jederzeit möglich. Das Limit lässt sich innerhalb des Monats anheben oder deaktivieren, um den Zugriff wiederherzustellen.

Das Limit wird monatlich zurückgesetzt; die konfigurierte Grenze gilt so lange, bis sie geändert wird. Da Nutzungsdaten in Intervallen synchronisiert werden – nicht in Echtzeit –, kann nach Erreichen der Obergrenze eine geringe Mehrmenge anfallen, bevor die Durchsetzung greift. Details dazu finden sich in der GitLab-Credits-Dokumentation.

Nutzerlimits auf individueller Ebene

Nicht alle Nutzenden verbrauchen Credits im gleichen Tempo – das ist erwartbar. Problematisch wird es, wenn ein oder zwei Intensivnutzende einen unverhältnismäßig großen Anteil des Kontingents beanspruchen und der Rest des Teams vor Monatsende keinen Zugriff mehr hat.

Individuelle Nutzerlimits verhindern, dass einzelne Nutzende mehr als ihren fairen Anteil verbrauchen:

• Einheitliches Nutzerlimit. Ein gleiches Credit-Limit für alle Nutzenden des Abonnements lässt sich über die GitLab GraphQL API setzen. Anders als die Abonnementobergrenze gilt dieses Limit für den Gesamtverbrauch einer Person über alle Credit-Quellen hinweg.
• Individuelle Ausnahmen. Für differenzierte Limits können über die GraphQL API individuelle Credit-Obergrenzen für bestimmte Nutzende gesetzt werden. So lässt sich beispielsweise Staff Engineers ein höheres Kontingent einräumen, während für das breitere Team ein Standardlimit gilt.
• Individuelle Durchsetzung. Erreicht eine Person ihr Limit, behält sie vollen Zugriff auf GitLab. Lediglich die Duo-Agent-Platform-Nutzung via Credits wird bis zum nächsten Abrechnungszeitraum pausiert. Alle anderen arbeiten unterbrechungsfrei weiter – bis sie ihr eigenes Limit oder die Abonnementobergrenze erreichen, je nachdem, was zuerst eintritt.

Sichtbarkeit und Benachrichtigungen

Wird die Abonnementobergrenze erreicht, sendet GitLab eine E-Mail-Benachrichtigung an Billing Account Manager, damit diese reagieren können: das Limit anheben, die nächste Periode abwarten oder Credits umverteilen.

Innerhalb von GitLab können Group Owner (GitLab.com) und Instanz-Administratoren (Self-Managed) einsehen, welche Nutzenden aufgrund ihres individuellen Limits gesperrt wurden, und den Zugriff durch Anpassung der Grenze über die GraphQL API wiederherstellen.

Warum Budgetlimits die KI-Skalierung ermöglichen

Klare Steuerungsmechanismen sind entscheidend, wenn Organisationen ihre KI-Nutzung ausweiten. Drei Gründe:

Planbare KI-Budgets

Verbrauchssteuerung für GitLab Duo Agent Platform macht KI-Ausgaben zu einer planbaren, begrenzten Budgetposition auf Basis von On-Demand GitLab Credits. Das erleichtert sowohl die Budgetfreigabe durch Finance als auch die Planung der quartalsweisen Ausgaben.

Governance und interne Kostenverrechnung

Große Organisationen müssen KI-Ausgaben häufig internen Budgets, Kostenstellen oder Abteilungsrichtlinien zuordnen. Individuelle Nutzerlimits geben Platform-Teams einen unkomplizierten Mechanismus, Credits fair zuzuweisen und den Verbrauch auf Personenebene nachzuverfolgen. Die API-Konfiguration macht dies auch im Enterprise-Maßstab handhabbar. In Kombination mit den personenbezogenen Verbrauchsdaten aus dem GitLab-Credits-Dashboard lassen sich Verbrauchsmuster nachverfolgen – als Grundlage für interne Kostenverrechnungs- oder Budgetzuweisungsprozesse.

Sicherheit beim Skalieren

Viele Kunden starten GitLab Duo Agent Platform zunächst mit einer kleinen Pilotgruppe. Verbrauchssteuerung beseitigt die Risiken, die mit einer Ausweitung auf die gesamte Organisation verbunden sind. Duo Agent Platform lässt sich auf Hunderte oder Tausende von Entwicklungsteams ausrollen – mit der Gewissheit, dass eine harte Ausgabenobergrenze das Budget schützt. Wächst die Nutzung schneller als erwartet, greift das Limit – nicht eine unerwartete Rechnung.

Sitzplatzbasiert vs. verbrauchsbasiert

Viele KI-Coding-Tools setzen auf ein sitzplatzbasiertes Preismodell. Eine feste Anzahl von Lizenzen wird zu einem einheitlichen Preis pro Nutzenden erworben. Einfach, aber unflexibel: Der Preis ist derselbe, unabhängig davon, ob jemand das Tool zehnmal täglich nutzt oder gar nicht. Wenn Anbieter zudem Premium-Modelle und verbrauchsabhängige Zusatzkosten auf die Lizenzgebühr aufschlagen, erodiert die Kostentransparenz, die das Lizenzmodell ursprünglich versprochen hat.

GitLab verfolgt einen anderen Ansatz: verbrauchsbasierte Abrechnung mit harten Limits und einem zentralen Governance-Dashboard. Das verbindet die Flexibilität, nur für tatsächliche Nutzung zu zahlen, mit der Budgetplanbarkeit durchgesetzter Ausgabengrenzen.

Anwendungsbeispiele

Beispiel 1: Mittelgroßes SaaS-Unternehmen mit 200 Entwicklungspersonen. Die Organisation setzt eine Abonnementobergrenze in Höhe des erwarteten On-Demand-Verbrauchs. Die VP of Engineering kann Finance gegenüber zuverlässig zusichern, dass die Duo-Agent-Platform-Ausgaben den genehmigten Betrag nicht überschreiten werden – auch während des Onboardings neuer Teams. Nähert sich die Grenze in der Monatsmitte, erhält der Billing Account Manager eine Benachrichtigung und kann entscheiden: Limit anheben oder die nächste Periode abwarten.

Beispiel 2: Globales Finanzdienstleistungsunternehmen mit 2.000 Entwicklungspersonen. Das Unternehmen setzt individuelle Nutzerlimits, um einen fairen Zugang sicherzustellen. Staff Engineers, die an komplexen Refactoring-Projekten arbeiten, erhalten über die API ein höheres individuelles Kontingent; die meisten Entwicklungsteams erhalten ein Standard-Pauschalimit. Einzelne Nutzende können das Gesamtkontingent nicht erschöpfen. Das Platform-Team nutzt die personenbezogenen Verbrauchsdaten im GitLab-Credits-Dashboard für die Nachverfolgung von Verbrauchsmustern und die quartalsweise Budgetplanung.

Erste Schritte

Verbrauchssteuerung ist für GitLab.com- und Self-Managed-Kunden ab GitLab 18.11 verfügbar. Die Konfiguration erfolgt je nach Geltungsbereich und Rolle an unterschiedlichen Stellen.

Abonnementobergrenze

Billing Account Manager setzen die Abonnementobergrenze im Customers Portal:

1. Im Customers Portal anmelden.
2. Auf der Abonnementkarte zu den GitLab Credits-Einstellungen navigieren.
3. Die monatliche On-Demand-Credits-Obergrenze aktivieren und den gewünschten Wert eingeben.

Einheitliches Nutzerlimit

Das einheitliche Nutzerlimit wird über die GitLab GraphQL API durch Namespace Owner (GitLab.com) oder Instanz-Administratoren (Self-Managed) gesetzt. Details zu verfügbaren Konfigurationsoberflächen finden sich in der GitLab-Credits-Dokumentation.

Individuelle Ausnahmen

Für differenzierte Limits können Namespace Owner (GitLab.com) und Instanz-Administratoren (Self-Managed) individuelle Obergrenzen programmatisch setzen – geeignet für Automatisierungs- und Infrastructure-as-Code-Workflows.

Verbrauch und Status überwachen

• Customers Portal: Detaillierter Verbrauch und Limitstatus einsehbar.
• GitLab.com: Group Owner können gesperrte Nutzende unter Einstellungen > GitLab Credits einsehen.
• Self-Managed: Instanz-Administratoren können Limitstatus und gesperrte Nutzende unter Admin > GitLab Credits einsehen.

GitLab Duo Agent Platform – bereit für die Skalierung

Verbrauchssteuerung ist ab sofort in GitLab 18.11 verfügbar. Ausgabelimits setzen, Duo Agent Platform auf weitere Teams ausrollen – und die KI-Ausgaben dabei vollständig im Griff behalten.

Mehr über GitLab Credits und Verbrauchssteuerung erfahren.

In GitLab 18.11 adressieren zwei neue Foundational Agents der Duo Agent Platform konkrete Lücken im Entwicklungszyklus, die KI bislang weitgehend unberührt gelassen hat:

• CI Expert Agent (jetzt in Beta) schließt die Lücke zwischen dem Schreiben von Code und einer laufenden Pipeline
• Data Analyst Agent (jetzt allgemein verfügbar) schließt die Lücke zwischen dem Ausliefern von Code und der Fähigkeit, grundlegende Fragen zur tatsächlichen Delivery zu beantworten

Diese Problembereiche lassen sich nicht mit einem allgemeinen Assistenten lösen. Ein Tool außerhalb von GitLab kann eine YAML-Datei generieren oder eine Frage beantworten – es hat jedoch keine Kenntnis davon, wie Pipelines historisch performt haben, wo Fehler gehäuft auftreten oder wie die tatsächlichen MR-Durchlaufzeiten aussehen. Dieser Kontext liegt in GitLab. Diese Agenten auch.

Schnelles CI-Setup mit CI Expert Agent

KI beschleunigt das Schreiben von Code erheblich. Den Code in eine laufende Pipeline zu bringen ist etwas, das die meisten Teams Tage oder Wochen später erledigen – wenn überhaupt. Das Blank-Page-Problem liegt nicht mehr im Editor. Es liegt jetzt in der .gitlab-ci.yml.

Entwicklungsteams, die CI noch nie konfiguriert haben, wissen nicht, wie Language Detection in YAML aussieht, welche Test-Befehle verwendet werden sollten oder wie das Ergebnis vor dem Push validiert wird. Teams kopieren entweder eine Konfiguration aus einem früheren Projekt, die möglicherweise nicht passt, fügen Beispiele aus der Dokumentation zusammen oder warten auf die eine Person, die es schon einmal gemacht hat. Ist diese Person nicht verfügbar, wird CI zu etwas, das man "später erledigt". Aus "später" wird "nie".

Wenn CI dauerhaft ausbleibt, zeigen sich die Folgen im gesamten Entwicklungsprozess: Änderungen werden ohne automatisierte Absicherung ausgeliefert, Regressionen tauchen in der Produktion statt in der Pipeline auf, und Arbeit häuft sich in größeren, riskanteren Batches an. Teams gewöhnen sich mit der Zeit daran, ohne strukturierte Rückkopplung zu arbeiten – auf undokumentiertes Erfahrungswissen angewiesen statt auf einen reproduzierbaren Feedback-Mechanismus, der in jeden Commit integriert ist.

CI Expert Agent, jetzt in Beta verfügbar, beseitigt diese Hürde systematisch. Der Agent analysiert das Repository, erkennt Sprache und Framework und schlägt eine funktionsfähige Build- und Test-Pipeline vor, die auf dem tatsächlichen Repository-Inhalt basiert – mit einer Erklärung jeder Entscheidung in verständlicher Sprache. Das Ziel: eine laufende Pipeline, ohne YAML manuell schreiben zu müssen.

Funktionsumfang von CI Expert Agent:

• Repository-bewusste Pipeline-Generierung erkennt Sprache, Framework und Test-Setup
• Generiert valide, ausführbare Build- und Test-Konfigurationen
• Geführter Erstkonfigurations-Ablauf mit verständlicher Erklärung jedes Schritts im Agentic Chat
• Native GitLab-CI-Semantik ohne Konfigurations-Übersetzung

Da der Agent innerhalb von GitLab läuft und das tatsächliche Pipeline-Verhalten über Zeit beobachtet, kann jede Verbesserung auf der Arbeitsweise der Teams aufbauen – nicht nur auf statischen Beispielen.

CI Expert Agent ist verfügbar auf GitLab.com, Self-Managed und Dedicated in den Editionen Free, Premium und Ultimate – mit aktivierter Duo Agent Platform.

SDLC-Daten in natürlicher Sprache abfragen mit Data Analyst Agent

KI hat das Tempo der Code-Auslieferung erhöht. Grundlegende Fragen dazu, wie diese Arbeit verläuft, sind dadurch nicht einfacher zu beantworten – im Gegenteil.

Wie lange liegen MRs im Review? Welche Pipelines bremsen Teams aus? Werden Deployment-Ziele tatsächlich erreicht? Diese Fragen ließen sich früher mit einem Blick auf ein Dashboard beantworten. Mit mehr Code, mehr Teams und mehr Komplexität sind die Daten zwar vorhanden – sie liegen in GitLab – der Zugriff erfordert jedoch nach wie vor das Warten auf ein Analytics-Team, eine Dashboard-Anfrage oder die Einarbeitung in GLQL.

Data Analyst Agent schließt diese Lücke. Eine Frage in natürlicher Sprache stellen – und eine sofortige Visualisierung im Agentic Chat erhalten. Keine Abfragesprache, keine Dashboard-Anfrage, kein Warten.

Der Agent beantwortet beispielsweise folgende Fragen – je nach Rolle:

• Engineering Manager: MR-Durchlaufzeiten, Durchsatz nach Projekt, wo Reviews stocken
• Entwicklungsteams: Beitragsmuster, instabile Tests, die MRs blockieren, Pipeline-Geschwindigkeit
• DevOps- und Plattform-Teams: Pipeline-Erfolgs- und Fehlerquoten, Runner-Auslastung, Deployment-Frequenz
• Engineering Leadership: Deployment-Frequenz über Portfolios hinweg, Projektgesundheitsmetriken, Lead-Time-Vergleiche

Mit der allgemeinen Verfügbarkeit in GitLab 18.11 deckt der Agent MRs, Issues, Projekte, Pipelines und Jobs ab – vollständige SDLC-Abdeckung, erweitert gegenüber dem Beta-Umfang. Da Data Analyst Agent direkt auf vorhandene GitLab-Daten zugreift, ist der Kontext stets aktuell – ohne eine separate Datenpipeline pflegen oder ein Drittanbieter-Tool synchron halten zu müssen. Generierte GitLab Query Language-Abfragen lassen sich überall dort kopieren und verwenden, wo GitLab Flavored Markdown unterstützt wird; ein direkter Export zu Work Items und Dashboards ist in Planung.

Data Analyst Agent ist verfügbar auf GitLab.com, Self-Managed und Dedicated in den Editionen Free, Premium und Ultimate – mit aktivierter Duo Agent Platform.

Eine Plattform, verbundener Kontext

Beide Agenten laufen innerhalb von GitLab und haben Zugriff auf den Code, die Pipelines, Issues und Merge Requests, die dort bereits vorhanden sind. Das unterscheidet plattformnative KI von einem externen Assistenten: Der Kontext ist stets aktuell und wächst mit der Nutzung. CI Expert Agent und Data Analyst Agent sind zwei konkrete Erweiterungen einer Plattform, auf der KI den gesamten Entwicklungszyklus unterstützt – von der Pipeline-Konfiguration über die Auslieferung bis zur Nachverfolgung.

GitLab Duo Agent Platform kostenlos testen und diese KI-Agenten direkt im Entwicklungs-Workflow einsetzen.

Mit der allgemeinen Verfügbarkeit in GitLab 18.11 generiert Agentic SAST Vulnerability Resolution automatisch zusammenführungsbereite Code-Fixes zur Behebung von SAST-Schwachstellen:

• Entwicklungsteams bleiben im Arbeitsfluss
• Schwachstellen werden behoben, bevor sie die Produktion erreichen
• AppSec-Teams verbringen weniger Zeit mit Triage und der Nachverfolgung offener Findings

GitLab 18.11 liefert darüber hinaus schnelleres SAST-Scanning, evidenzbasierte Priorisierung und klar abgegrenzte Governance-Kontrollen.

Auto-Remediierung ohne Unterbrechung des Arbeitsflusses

Wenn KI Code in großem Umfang generiert, verändert sich die Ausgangslage grundlegend. Ein Security-Rückstand, der früher linear wuchs, nimmt heute mit jedem modellgestützten Commit weiter zu. Mehr manuelle Kontextwechsel von Entwicklungsteams zu fordern löst dieses Problem nicht – die Mengen sind schlicht zu groß.

Agentic SAST Vulnerability Resolution verändert die Dynamik dieses Zyklus. Sobald ein SAST-Scan abgeschlossen ist, starten die Findings automatisch den Erkennungsfluss für Fehlalarme (SAST False Positive Detection). Bestätigte True Positives werden direkt in den Agentic SAST Vulnerability Resolution Flow übergeben, wo GitLab Duo Agent Platform:

• die Schwachstelle im Kontext analysiert
• einen Fix erstellt, der die Grundursache behebt
• den Fix durch automatisierte Tests validiert

Entwicklungsteams erhalten einen zusammenführungsbereiten MR mit einem Confidence-Score, auf dessen Basis eine fundierte Entscheidung zur Behebung getroffen werden kann. Der Sprint bleibt auf Kurs, Schwachstellen werden behoben, bevor sie die Produktion erreichen.

Zum Thema Scan-Geschwindigkeit: GitLab 18.11 führt inkrementelles Scanning für Advanced SAST ein. Entwicklungsteams erhalten Schwachstellenergebnisse, ohne auf den Abschluss eines vollständigen Scans warten zu müssen – Pipelines bleiben durchgehend in Bewegung.

Remediierung nach Geschäftsrisiko – nicht nach Score

Eine automatisierte Remediierungspipeline funktioniert nur so gut wie das Signal, das sie antreibt. Wenn Schwachstellenscores die tatsächliche Ausnutzbarkeit nicht widerspiegeln, verlieren Entwicklungsteams das Vertrauen in das Signal – und beginnen, es zu ignorieren.

GitLab 18.11 adressiert dieses Problem auf vier Ebenen. Erstens sind Schwachstellenscores jetzt im Common Vulnerability Scoring System (CVSS) 4.0 verankert – dem aktuellen Industriestandard mit differenzierteren Metriken zur Erfassung realer Ausnutzbarkeit. Der Score, den Entwicklungsteams in GitLab sehen, entspricht damit dem Stand der Technik für die Bewertung realer Risiken.

Darüber hinaus können AppSec-Teams richtlinienbasierte Regeln definieren, die Schwachstellenscores automatisch anpassen – basierend auf Signalen wie Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE) sowie Dateipfad oder Verzeichnis. Einmal konfiguriert, greifen die Schweregrad-Anpassungen sofort, sodass Entwicklungsteams an einem Rückstand arbeiten, der das tatsächliche Geschäftsrisiko widerspiegelt und nicht den unbereinigten Scanner-Output.

Die risikobasierte Steuerung endet nicht beim Rückstand. AppSec-Teams können jetzt Freigaberichtlinien konfigurieren, die Merges blockieren oder warnen – basierend auf dem Known Exploited Vulnerabilities (KEV)-Status oder dem Exploit Prediction Scoring System (EPSS)-Score. Wird ein Merge blockiert, wissen Entwicklungsteams, dass dies auf realen Ausnutzbarkeitsdaten beruht.

Das neue Top-CWEs-Diagramm im Security-Dashboard gibt Teams abschließend Einblick, welche Schwachstellenklassen in ihren Projekten am häufigsten auftreten. Statt einzelnen Findings nachzujagen, lassen sich Muster erkennen, Grundursachen priorisieren und systemische Risiken adressieren, bevor sie sich auswachsen.

Stärkere Security-Kontrollen bei geringerem operativem Aufwand

Eine automatisierte Remediierungspipeline ist nur so gut wie die darunterliegende Scanner-Abdeckung. Inkonsistente Scanner-Konfigurationen führen zu unvollständigen Findings – und damit zu unvollständigen Fixes.

GitLab 18.11 führt den Security Manager ein – eine neue Standardrolle, die speziell für Security-Professionals entwickelt wurde. Mit dieser Rolle lassen sich Security-Scanner durchsetzen, Security-Richtlinien definieren und konfigurieren, Triage- und Remediierungs-Workflows für Schwachstellen verwalten sowie Compliance-Frameworks und Audit-Streams pflegen – ohne Code-Änderungs- oder Deployment-Berechtigungen zu benötigen. Security-Teams erhalten genau die Zugriffsrechte, die ihre Aufgaben erfordern, und keine weiteren.

Für AppSec-Teams vereinfachen SAST-Konfigurationsprofile die konsistente Scanner-Abdeckung über mehrere Projekte und Gruppen hinweg erheblich. Das Scanning wird einmalig definiert und mit einer Aktion auf alle Projekte einer Gruppe angewendet. Das manuelle Pflegen von YAML-Policy-Dateien, die Abhängigkeit von Entwicklungsteams bei der Scanner-Konfiguration und das Prüfen einzelner Projekte auf Abdeckungslücken entfällt damit.

Automatisierte Vulnerability-Remediierung – jetzt starten

GitLab 18.11 liefert den vollständigen Vulnerability-Workflow auf einer Plattform: KI, die Schwachstellen automatisch behebt, CVSS-4.0-basierte Priorisierung, die Vulnerability-Rauschen reduziert, und Governance-Kontrollen, die Security-Teams den erforderlichen Zugriff und vollständige Abdeckung ermöglichen.

GitLab Ultimate kostenlos testen und erleben, wie GitLab Duo Agent Platform die automatisierte Remediierung direkt in den Entwicklungs-Workflow integriert.

Für konkrete Compliance-Anforderungen empfiehlt sich die Rücksprache mit entsprechender Fachberatung.

Wir wissen, dass die Verwaltung von Breaking Changes bei einem Major-Upgrade aufwändig ist: Es erfordert Analyse und Koordination im gesamten Unternehmen. Als Reaktion darauf haben wir eine Genehmigungspflicht für Breaking Changes eingeführt, die eine Folgenabschätzung und die Freigabe durch die Führungsebene vorschreibt, bevor ein Breaking Change umgesetzt werden kann. Dieser Prozess zeigt Wirkung, und wir sind entschlossen, die Zahl weiter zu senken.

Im Folgenden sind alle Breaking Changes in GitLab 19.0 aufgeführt, geordnet nach Deployment-Typ und Auswirkung, zusammen mit den Migrationsschritten für ein reibungsloses Upgrade.

Deployment-Fenster

Folgende Deployment-Fenster sind relevant.

GitLab.com

Inkompatible Änderungen für GitLab.com sind auf diese zwei Fenster begrenzt:

• 4.–6. Mai 2026 (09:00–22:00 UTC) — primäres Fenster
• 11.–13. Mai 2026 (09:00–22:00 UTC) — Ausweichfenster

Viele weitere Änderungen werden im Laufe des Monats ausgerollt. Mehr zu den Breaking Changes innerhalb dieser Fenster in der Dokumentation zu Breaking-Change-Fenstern.

Hinweis: In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Fenster fallen.

GitLab Self-Managed

GitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.

Mehr zum Release-Zeitplan.

GitLab Dedicated

Das Upgrade auf GitLab 19.0 findet im zugewiesenen Wartungsfenster statt. Das Wartungsfenster ist im Switchboard-Portal einsehbar. GitLab Dedicated-Instanzen werden auf Release N-1 gehalten, das Upgrade auf GitLab 19.0 erfolgt daher im Wartungsfenster in der Woche ab dem 22. Juni 2026.

Auf der Deprecations-Seite ist die vollständige Liste der für GitLab 19.0 geplanten Entfernungen zu finden. Im Folgenden wird erläutert, was kommt und wie man sich je nach Deployment darauf vorbereitet.

Breaking Changes

Folgende Breaking Changes haben hohe Auswirkungen.

Hohe Auswirkung

1. NGINX Ingress-Unterstützung durch Gateway API mit Envoy Gateway ersetzt

GitLab Self-Managed (Helm chart)

Der GitLab Helm chart hat NGINX Ingress als Standard-Netzwerkkomponente gebündelt. NGINX Ingress hat im März 2026 das End-of-Life erreicht. GitLab wechselt nun zu Gateway API mit Envoy Gateway als neuem Standard.

Ab GitLab 19.0 werden Gateway API und das gebündelte Envoy Gateway zur Standard-Netzwerkkonfiguration. Falls eine Migration zu Envoy Gateway für das eigene Deployment nicht sofort möglich ist, kann das gebündelte NGINX Ingress explizit wieder aktiviert werden — es bleibt bis zur geplanten Entfernung in GitLab 20.0 verfügbar.

Diese Änderung betrifft nicht:

• Das im Linux-Paket enthaltene NGINX
• GitLab Helm chart- und GitLab Operator-Instanzen, die einen extern verwalteten Ingress- oder Gateway-API-Controller verwenden

GitLab stellt bis zur vollständigen Entfernung Best-Effort-Sicherheitswartung für den geforkten NGINX Ingress chart und die zugehörigen Builds bereit. Für einen reibungslosen Übergang empfiehlt sich eine frühzeitige Migration zur bereitgestellten Gateway-API-Lösung oder zu einem extern verwalteten Ingress-Controller.

Deprecation notice

2. Gebündelte PostgreSQL-, Redis- und MinIO-Komponenten aus dem GitLab Helm chart entfernt

GitLab Self-Managed (Helm chart)

Der GitLab Helm chart hat Bitnami PostgreSQL, Bitnami Redis und einen Fork des offiziellen MinIO-Charts gebündelt, um die Einrichtung von GitLab in Proof-of-Concept- und Testumgebungen zu erleichtern. Aufgrund von Änderungen bei Lizenzierung, Projektpflege und Verfügbarkeit öffentlicher Images werden diese Komponenten ohne Ersatz aus dem GitLab Helm chart und dem GitLab Operator entfernt.

Diese Charts sind ausdrücklich als nicht für den Produktionseinsatz geeignet dokumentiert. Ihr einziger Zweck war die Bereitstellung schneller Testumgebungen.

Wer eine Instanz mit gebündeltem PostgreSQL, Redis oder MinIO betreibt, muss vor dem Upgrade auf GitLab 19.0 der Migrationsanleitung folgen, um externe Dienste zu konfigurieren. Redis und PostgreSQL aus dem Linux-Paket sind von dieser Änderung nicht betroffen.

Deprecation notice

3. Resource Owner Password Credentials (ROPC) OAuth Grant entfernt

GitLab.com | Self-Managed | Dedicated

Die Unterstützung für den Resource Owner Password Credentials (ROPC) Grant als OAuth-Flow wird in GitLab 19.0 vollständig entfernt. Dies entspricht dem OAuth RFC Version 2.1-Standard, der ROPC aufgrund seiner inhärenten Sicherheitsschwächen entfernt.

GitLab hat seit dem 8. April 2025 bereits eine Client-Authentifizierung für ROPC auf GitLab.com vorgeschrieben. In Version 18.0 wurde eine Administrator-Einstellung hinzugefügt, die einen kontrollierten Opt-out vor der Entfernung ermöglicht.

Nach dem Upgrade auf 19.0 kann ROPC unter keinen Umständen mehr verwendet werden, auch nicht mit Client-Credentials. Alle Anwendungen oder Integrationen, die diesen Grant-Typ verwenden, müssen vor dem Upgrade auf einen unterstützten OAuth-Flow migrieren — beispielsweise den Authorization Code Flow.

Deprecation notice

4. PostgreSQL 16 nicht mehr unterstützt — PostgreSQL 17 ist das neue Minimum

GitLab Self-Managed

GitLab folgt einem jährlichen Upgrade-Rhythmus für PostgreSQL. In GitLab 19.0 wird PostgreSQL 17 zur Mindestanforderung, die Unterstützung für PostgreSQL 16 wird eingestellt.

PostgreSQL 17 ist ab GitLab 18.9 verfügbar und kann jederzeit vor dem 19.0-Release upgradet werden.

Bei Instanzen mit einer einzelnen, über das Linux-Paket installierten PostgreSQL-Instanz wird beim Upgrade auf 18.11 möglicherweise ein automatisches Upgrade auf PostgreSQL 17 durchgeführt. Für das Upgrade ist ausreichend freier Speicherplatz einzuplanen.

Bei Instanzen mit PostgreSQL Cluster oder solchen, die das automatische Upgrade deaktivieren, ist vor dem Upgrade auf GitLab 19.0 ein manuelles Upgrade auf PostgreSQL 17 erforderlich.

Deprecation notice | Upgrade-Anleitung

Mittlere Auswirkung

Folgende Breaking Changes haben mittlere Auswirkungen.

1. Linux-Paket-Unterstützung für Ubuntu 20.04 eingestellt

GitLab Self-Managed

Der Standard-Support für Ubuntu 20.04 endete im Mai 2025. Gemäß der Richtlinie für unterstützte Plattformen im Linux-Paket werden Pakete eingestellt, sobald ein Anbieter den Support für das Betriebssystem beendet.

Ab GitLab 19.0 werden keine Pakete mehr für Ubuntu 20.04 bereitgestellt. GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distribution.

Wer GitLab derzeit auf Ubuntu 20.04 betreibt, muss vor dem Upgrade auf GitLab 19.0 auf Ubuntu 22.04 oder ein anderes unterstütztes Betriebssystem wechseln. Canonical stellt eine Upgrade-Anleitung für die Migration bereit.

Deprecation notice

2. Unterstützung für Redis 6 entfernt

GitLab Self-Managed

In GitLab 19.0 wird die Unterstützung für Redis 6 entfernt. Instanzen mit einem externen Redis-6-Deployment müssen vor dem Upgrade auf Redis 7.2 oder Valkey 7.2 migrieren; Valkey 7.2 ist ab GitLab 18.9 in der Beta verfügbar, die allgemeine Verfügbarkeit ist für GitLab 19.0 geplant.

Das im Linux-Paket enthaltene Redis verwendet seit GitLab 16.2 Redis 7 und ist nicht betroffen. Handlungsbedarf besteht nur bei Instanzen mit einem externen Redis-6-Deployment.

Migrationsressourcen für gängige Plattformen:

• AWS ElastiCache: Upgrade auf Redis 7.2 oder Valkey 7.2
• GCP Memorystore: Upgrade auf Redis 7.2 oder Valkey 7.2
• Azure Cache for Redis: Managed Redis 7.2 oder Valkey 7.2 ist auf Azure noch nicht verfügbar. Als Alternative kann ein selbstgehostetes Deployment auf Azure VMs oder AKS genutzt werden, oder die Linux-Paket-Installation, die Valkey 7.2 mit GitLab 19.0 GA unterstützen wird.
• Self-hosted: Upgrade der Redis-6-Instanz auf Redis 7.2 oder Valkey 7.2.

Deprecation notice | Anforderungsdokumentation

3. heroku/builder:22-Image durch heroku/builder:24 ersetzt

GitLab.com | Self-Managed | Dedicated

Das Cloud-Native-Buildpack (CNB) Builder-Image in Auto DevOps wurde auf heroku/builder:24 aktualisiert. Betroffen sind Pipelines, die das auto-build-image der Auto Build-Stage von Auto DevOps verwenden.

Die meisten Workloads sind nicht betroffen. Für einige Nutzende kann dies jedoch ein Breaking Change sein. Vor dem Upgrade sollten die Heroku-24-Stack-Release-Notes und Upgrade-Hinweise geprüft werden.

Wer nach GitLab 19.0 weiterhin heroku/builder:22 verwenden möchte, setzt die CI/CD-Variable AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER auf heroku/builder:22.

Deprecation notice

4. Mattermost aus dem Linux-Paket entfernt

GitLab Self-Managed

In GitLab 19.0 wird das gebündelte Mattermost aus dem Linux-Paket entfernt. Mattermost wurde seit 2015 mit GitLab gebündelt, verfügt inzwischen aber über ausgereifte eigenständige Deployment-Optionen. Mit Mattermost v11 wurde zudem GitLab SSO aus dem kostenlosen Angebot entfernt, was den Mehrwert der gebündelten Integration verringert.

Wer das gebündelte Mattermost nicht verwendet, ist nicht betroffen. Bei Bedarf steht in der Mattermost-Dokumentation eine Anleitung zur Migration von GitLab Omnibus zu Mattermost Standalone zur Verfügung.

Deprecation notice

5. Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt

GitLab Self-Managed

In GitLab 19.0 wird die Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt. Betroffen sind:

• openSUSE Leap 15.6
• SUSE Linux Enterprise Server 12.5
• SUSE Linux Enterprise Server 15.6

GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distributionen. Der empfohlene Weg ist eine Migration zu einem Docker-Deployment von GitLab auf der bestehenden Distribution — so ist kein Wechsel des Betriebssystems nötig, um weiterhin Upgrades zu erhalten.

Deprecation notice

Geringe Auswirkung

Folgende Breaking Changes haben geringe Auswirkungen.

1. Spamcheck aus Linux-Paket und GitLab Helm chart entfernt

GitLab Self-Managed

In GitLab 19.0 wird Spamcheck aus dem Linux-Paket und dem GitLab Helm chart entfernt. Es ist in erster Linie für große öffentliche Instanzen relevant — ein Sonderfall in der GitLab-Kundenbasis. Die Entfernung reduziert die Paketgröße und den Abhängigkeits-Footprint für die Mehrheit der Nutzenden.

Wer Spamcheck nicht verwendet, ist nicht betroffen. Wer das gebündelte Spamcheck nutzt, kann es separat über Docker bereitstellen. Eine Datenmigration ist nicht erforderlich.

Deprecation notice

2. Slack-Slash-Commands-Integration entfernt

GitLab Self-Managed | Dedicated

Die Slack-Slash-Commands-Integration wird zugunsten der GitLab for Slack-App eingestellt, die eine sicherere Integration mit denselben Funktionen bietet.

Ab GitLab 19.0 können Slack Slash Commands nicht mehr konfiguriert oder verwendet werden. Diese Integration existiert nur in GitLab Self-Managed und GitLab Dedicated — GitLab.com-Nutzende sind nicht betroffen.

Ob die eigene Instanz betroffen ist, lässt sich mit der Betroffenheitsprüfung feststellen.

Deprecation notice

3. Bitbucket-Cloud-Import über API unterstützt keine App-Passwörter mehr

GitLab.com | Self-Managed | Dedicated

Atlassian hat App-Passwörter (Benutzername-Passwort-Authentifizierung) für Bitbucket Cloud eingestellt und angekündigt, dass diese Authentifizierungsmethode ab dem 9. Juni 2026 nicht mehr funktioniert.

Ab GitLab 19.0 erfordert der Import von Repositories aus Bitbucket Cloud über die GitLab API User-API-Tokens anstelle von App-Passwörtern. Nutzende, die aus Bitbucket Server oder über die GitLab-Benutzeroberfläche aus Bitbucket Cloud importieren, sind nicht betroffen.

Deprecation notice | Betroffenheitsprüfung

4. Trending-Tab auf der Seite „Projekte erkunden" entfernt

GitLab.com | Self-Managed | Dedicated

Der Tab Trending unter Erkunden > Projekte und die zugehörigen GraphQL-Argumente werden in GitLab 19.0 entfernt. Der Trending-Algorithmus berücksichtigt nur öffentliche Projekte und ist daher für Self-Managed-Instanzen, die hauptsächlich interne oder private Projektsichtbarkeit verwenden, nicht zielführend.

Im Monat vor dem GitLab-19.0-Release wird der Tab Trending auf GitLab.com auf den Tab Aktiv, sortiert nach Sternen in absteigender Reihenfolge, weitergeleitet.

Ebenfalls entfernt: das trending-Argument in den GraphQL-Typen Query.adminProjects, Query.projects und Organization.projects.

Deprecation notice

5. Container-Registry-Speichertreiber-Updates

GitLab Self-Managed

Zwei ältere Container-Registry-Speichertreiber werden in GitLab 19.0 ersetzt:

• Azure-Speichertreiber: Der ältere azure-Treiber wird zu einem Alias für den neuen azure_v2-Treiber. Es ist keine manuelle Aktion erforderlich, eine proaktive Migration wird jedoch für verbesserte Zuverlässigkeit und Leistung empfohlen. Migrationsschritte sind in der Object-Storage-Dokumentation beschrieben. Deprecation notice
• S3-Speichertreiber (AWS SDK v1): Der ältere s3-Treiber wird zu einem Alias für den neuen s3_v2-Treiber. Der s3_v2-Treiber unterstützt Signature Version 2 nicht — eine vorhandene v4auth: false-Konfiguration wird transparent ignoriert. Vor dem Upgrade ist eine Migration auf Signature Version 4 erforderlich. Deprecation notice

6. ciJobTokenScopeAddProject-GraphQL-Mutation entfernt

GitLab.com | Self-Managed | Dedicated

Die ciJobTokenScopeAddProject-GraphQL-Mutation wird zugunsten von ciJobTokenScopeAddGroupOrProject eingestellt, das zusammen mit den CI/CD-Job-Token-Scope-Änderungen in GitLab 18.0 eingeführt wurde. Automatisierungen oder Tools, die die veraltete Mutation verwenden, müssen vor dem Upgrade aktualisiert werden.

Deprecation notice

7. ci_job_token_scope_enabled-Attribut der Projects API entfernt

GitLab.com | Self-Managed | Dedicated

Das Attribut ci_job_token_scope_enabled in der Projects REST API wird in GitLab 19.0 entfernt. Das Attribut wurde in GitLab 18.0 eingestellt, als die zugrundeliegende Einstellung entfernt wurde, und hat seitdem stets false zurückgegeben.

Zur Steuerung des CI/CD-Job-Token-Zugriffs werden die CI/CD-Job-Token-Projekteinstellungen verwendet.

Deprecation notice

8. Paginierungslimit für nicht authentifizierte Projects-API auf GitLab.com eingeführt

GitLab.com

Zur Sicherstellung der Plattformstabilität und konsistenten Leistung wird für alle nicht authentifizierten Anfragen an die Projects-List-REST-API auf GitLab.com ein maximales Offset-Limit von 50.000 eingeführt. Beispielsweise ist der page-Parameter bei 20 Ergebnissen pro Seite auf 2.500 Seiten begrenzt.

Workflows, die Zugriff auf mehr Daten benötigen, müssen keyset-basierte Paginierungsparameter verwenden. Dieses Limit gilt nur für GitLab.com. In GitLab Self-Managed und GitLab Dedicated ist das Offset-Limit standardmäßig deaktiviert und hinter einem Feature-Flag verfügbar.

Deprecation notice

Ressourcen zur Folgenabschätzung

GitLab stellt spezifische Tools bereit, mit denen sich die Auswirkungen der geplanten Änderungen auf die eigene GitLab-Instanz analysieren lassen. Nach der Folgenabschätzung empfiehlt sich die Prüfung der Migrationsschritte in der jeweiligen Dokumentation für einen reibungslosen Übergang zu GitLab 19.0.

GitLab Detective (nur Self-Managed): Dieses experimentelle Tool prüft eine GitLab-Installation automatisch auf bekannte Probleme, indem es Konfigurationsdateien und Datenbankwerte analysiert. Hinweis: Es muss direkt auf den GitLab-Nodes ausgeführt werden.

Nutzende mit einem kostenpflichtigen Plan, die Fragen haben oder Unterstützung bei diesen Änderungen benötigen, können ein Support-Ticket im GitLab Support-Portal eröffnen.

Kostenlose GitLab.com-Nutzende können zusätzlichen Support über Community-Ressourcen wie die GitLab-Dokumentation, das GitLab Community Forum und Stack Overflow erhalten.

Im Rahmen dieser Partnerschaft automatisiert GitLab Duo Agent Platform die Orchestrierung und den Lifecycle-Kontext der Softwareentwicklung – über die Integration mit Vertex AI auf Google Cloud, das die Modellebene für Agent-Aufrufe bereitstellt. Softwareteams arbeiten weiterhin mit Issues, Merge Requests, Pipelines und Security-Workflows, während die Inferenz der Google Cloud-Konfiguration folgt, die bereits definiert wurde.

Fortschritte bei den Vertex AI-Modellen von Google Cloud erweitern die Einsatzmöglichkeiten von GitLab Duo Agent Platform. Kunden erhalten eine KI-gestützte DevSecOps-Steuerungsebene in GitLab, gestützt auf eine leistungsfähige KI-Infrastruktur in Vertex AI und die flexiblen Deployment- und Integrationsoptionen von Duo Agent Platform. In Kombination ermöglicht das leistungsfähigere, kontrollierte agentenbasierte Workflows im Enterprise-Maßstab.

Agenten über den gesamten Lifecycle hinweg

Viele KI-Tools konzentrieren sich auf eine einzelne Aufgabe: Code schneller generieren. GitLab Duo Agent Platform geht weiter. Die Plattform orchestriert KI-Agenten über den gesamten Software Development Lifecycle (SDLC) – von der Planung über das Security-Review bis zur Auslieferung, teamübergreifend und über viele Projekte und Releases hinweg. In diesem Maßstab sind KI-Coding-Assistenten zwar notwendig für kontinuierliche Innovation, aber nicht ausreichend.

Einzelne Coding-Assistenten erfassen selten den vollständigen Zustand eines Projekts. Backlog-Strukturen, offene Merge Requests, fehlgeschlagene Jobs und Sicherheitsbefunde befinden sich in GitLab – aber ein separates Chat-Fenster in einem Coding-Assistenten übernimmt dieses Gesamtbild des SDLC nicht. Die Lücke zeigt sich in manuellen Übergaben, wiederholten Erklärungen an eine KI ohne Kontext und Governance-Teams, die Datenflüsse über Tools hinweg nachvollziehen müssen, die nie als einheitliches System konzipiert wurden.

GitLab Duo Agent Platform schließt diese Lücke, indem Agenten und Flows auf denselben Objekten arbeiten, die Entwicklungsteams täglich nutzen. Vertex AI liefert dabei die Modelle und Services, die diese Agenten aufrufen, wenn Google Cloud als Inferenz-Umgebung gewählt wird – wobei GitLabs AI Gateway den Zugriff vermittelt, sodass Administratoren jederzeit nachvollziehen können, was womit verbunden ist. So analysiert beispielsweise der GitLab Duo Planner Agent Backlogs, gliedert Epics in strukturierte Aufgaben und wendet Priorisierungs-Frameworks an, um Teams bei der Entscheidung zu unterstützen, was als Nächstes umgesetzt werden soll. Der Security Analyst Agent priorisiert Schwachstellen, beschreibt Risiken in verständlicher Sprache und empfiehlt Behebungsmaßnahmen in priorisierter Reihenfolge. Integrierte Flows verbinden diese Agenten zu durchgängigen Prozessen, ohne dass Entwicklungsteams jeden Übergabeschritt manuell steuern müssen.

Agentic Chat in GitLab Duo Agent Platform verbindet das Gesamterlebnis für Entwicklungsteams. Abfragen in natürlicher Sprache liefern kontextbezogene Antworten mit mehrstufigem Reasoning, das auf den vollständigen Projektzustand zugreift: Issues, Merge Requests, Pipelines, Sicherheitsbefunde und Codebase. Da GitLab als System of Record für den SDLC mit einem einheitlichen Datenmodell dient, arbeiten GitLab Duo-Agenten mit Lifecycle-Kontext, der über die Reichweite eigenständiger, toolspezifischer KI-Assistenten hinausgeht.

Verstärkt durch Vertex AI

GitLab Duo Agent Platform ist modellflexibel konzipiert und leitet verschiedene Aufgaben an verschiedene Modelle weiter – je nachdem, welches Modell für die jeweilige Aufgabe am besten geeignet ist. Diese Architekturentscheidung zahlt sich auf Google Cloud aus, wo Vertex AI als verwaltete Umgebung für Foundation Models und zugehörige Services fungiert und ein breites Modell-Ökosystem sowie verwaltete Infrastruktur bereitstellt, die die Plattformfähigkeiten erweitert.

Die neuesten Generationen von KI-Modellen, die über Vertex AI verfügbar sind, bieten deutliche Verbesserungen bei Reasoning, Tool-Nutzung und Long-Context-Verständnis gegenüber früheren Versionen – genau die Eigenschaften, auf die GitLabs Agenten bei der Arbeit mit vielen Projekten und Teams mit großen, komplexen Codebases angewiesen sind. Längere Kontextfenster und umfangreichere Tool-Integration in den zugrunde liegenden Modellen erweitern das, was Agenten in einem einzigen Durchlauf erreichen können – besonders relevant bei Aufgaben wie einer umfassenden Backlog-Analyse oder dem Security-Review von Monorepos.

Vertex AI Model Garden bietet mit Zugang zu einer breiten Palette von Foundation Models die nötige Auswahl, um Entscheidungen auf Basis von Leistung, Kosten und regulatorischen Anforderungen zu treffen – statt an einen einzelnen Anbieter gebunden zu sein.

Darüber hinaus können GitLab-Kunden Bring Your Own Model (BYOM) für Duo Agent Platform nutzen, sodass zugelassene Anbieter und Gateways dort eingebunden werden, wo das eigene Sicherheitsmodell es vorsieht. In GitLabs Beitrag zum 18.9-Release über Self-Hosted Duo Agent Platform und BYOM wird beschrieben, wie diese Anbindung funktioniert. Mit dieser Deployment-Option erhalten Kunden Zugang zu einem breiteren Spektrum an Modelloptionen, die sich auf den eigenen Entwicklungsprozess zuschneiden lassen: das richtige Modell für den richtigen Workflow mit den richtigen Leitplanken.

Für GitLab war die Entscheidung, auf Vertex AI zu bauen, von der Anforderung an Enterprise-taugliche Zuverlässigkeit und breite Modellverfügbarkeit getrieben. Vertex AI und Model Garden abstrahieren das LLM-Hosting vollständig – das bedeutet schnelle Versionsbereitstellung, robuste Sicherheit und strikte Governance sind in die Integration eingebaut. Über Gemini-Modelle hinaus bietet Vertex AI globalen, latenzarmen Zugang zu einem umfangreichen Katalog von Drittanbieter- und Open-Source-Modellen.

In Kombination mit Google Clouds Ansatz für Datenschutz und Modellschutz war Vertex AI die passende Wahl, um GitLabs Developer Experience der nächsten Generation zu unterstützen.

Durch die Integration von Vertex AI Model Garden in das Backend erweitert GitLab seine DevSecOps-Plattform, ohne den Nutzenden zusätzliche Komplexität aufzubürden. Entwicklungsteams müssen die zugrunde liegenden LLMs weder evaluieren noch verwalten – stattdessen nutzen sie einen optimierten, KI-gestützten Workflow für die Entwicklung ihrer Anwendungen.

GitLab abstrahiert die Cloud-Orchestrierung vollständig, sodass sich Entwicklungsteams ganz auf das Schreiben von Code konzentrieren können, während Vertex AI die unterstützenden Features und Funktionen bereitstellt.

Was das für Kunden auf Google Cloud bedeutet

GitLab Duo Agent Platform liefert bereits heute KI-Agenten, die über den gesamten Software-Lifecycle hinweg innerhalb eines einzigen, kontrollierten System of Record arbeiten. Auf Google Cloud ermöglicht das schnelle Innovation, während Vertex AI die Modell- und Infrastrukturebene kontinuierlich weiterentwickelt.

Für Google Cloud-Kunden bedeutet diese Integration eine optimierte Softwarebereitstellung bei gleichzeitig strikter Enterprise-Governance. Für Platform-Engineering-Teams bedeutet es, zu standardisieren, welche Vertex-gestützten Modelle Vorschläge, Analysen und Behebungen innerhalb von GitLab bereitstellen – statt Dutzende clientseitiger Tools zu katalogisieren. Sicherheitsprogramme profitieren, wenn Agenten Fixes dort vorschlagen und validieren, wo Entwicklungsteams bereits Befunde bearbeiten, was Kontextwechsel reduziert und Arbeit vermeidet, die sonst in nicht verwaltete Kanäle abfließen würde.

Aus Sicht der Cloud-Ökonomie und -Governance sorgt die Steuerung der Agent-Inferenz über Vertex innerhalb von GitLab dafür, dass die Nutzung näher an den bestehenden Vereinbarungen und Kontrollen auf Google Cloud bleibt – das hilft, doppelte Ausgaben und Schattenpfade zu vermeiden, die am Einkauf vorbeilaufen.

Da Vertex AI als zugrunde liegender Infrastrukturanbieter für GitLab Duo Agent Platform dient, können Unternehmen die Produktivität ihrer Entwicklungsteams deutlich steigern – ohne den Overhead und das Risiko fragmentierter KI-Toolchains. Teams bleiben innerhalb eines einzigen, sicheren System of Record abgestimmt und können Anwendungen schneller entwickeln und mit Zuversicht ausliefern.

Die Zusammenarbeit zwischen GitLab und Google Cloud besteht seit 2018. Heute stellt sie einen der umfassendsten Wege dar, um von KI-Experimenten zu vollständig kontrollierter, agentenbasierter Softwareentwicklung auf Google Cloud zu gelangen. Da sich beide Plattformen kontinuierlich weiterentwickeln – GitLab mit erweiterter Agent-Orchestrierung und Developer-Kontext, Vertex AI mit weiter steigender Modellleistung und Agent-Infrastruktur – wird der Mehrwert für gemeinsame Kunden weiter wachsen.

Starte eine kostenlose Testversion von GitLab Duo Agent Platform, um GitLab und Vertex AI auf Google Cloud kennenzulernen.

Die diesjährige Bewertung ist aus einem konkreten Grund bemerkenswert: Omdia hat die Bewertungskriterien erweitert und erstmals KI-Entwicklungstools nach ihrer Abdeckung des gesamten Software-Lifecycles bewertet – nicht nur nach Programmierfähigkeiten. Dieser Wandel spiegelt die aktuelle Entwicklung im KI-Bereich wider und hat die Rangfolge der Anbieter neu geordnet.

Den vollständigen Omdia Universe Report herunterladen.

Über Omdia Universe

Das Omdia Universe ordnet Anbieter nach Solution Capability sowie Strategy and Execution in drei Kategorien ein: Leaders (stärkste Positionierung auf beiden Achsen, für jede Shortlist empfohlen), Challengers (geringerer Funktionsumfang oder geringere Reife) und Prospects (frühe Phase oder angrenzende Anwendungsbereiche).

Was ist in der diesjährigen Bewertung anders?

Die Erweiterung der Omdia-Kriterien spiegelt wider, was Entwicklungsteams in der Praxis bereits erleben. KI-Programmierwerkzeuge haben die Entwicklerleistung deutlich gesteigert, und Anwendungen, deren Entwicklung früher Wochen dauerte, lassen sich heute in einem Bruchteil der Zeit als Prototyp umsetzen. Beschleunigung beim Programmieren führt jedoch nicht automatisch zu schnellerer Auslieferung. Review-Backlogs wachsen. Sicherheitsbefunde häufen sich an. Deployments erfordern weiterhin die Koordination zwischen Teams, die mit Tools arbeiten, die nicht aufeinander abgestimmt wurden.

Omdia hat diese Dynamik direkt erfasst: Die Plattformen, die sich absetzen, decken Testing, Security, Deployment und Orchestrierung ab – nicht nur Code-Generierung. Dieser Befund war ausschlaggebend für die Erweiterung der Bewertungskriterien und hat Leaders von Challengers unterschieden.

Eine weitere wesentliche Neuerung in diesem Jahr betrifft die Behandlung von agentischer KI. Die Bewertung 2026 gewichtet agentische Fähigkeiten als aktuelle Bewertungsdimension – nicht als Zukunftsperspektive. Berücksichtigt wird dabei, ob eine Plattform mehrere Aufgaben autonom koordinieren, Übergaben zwischen spezialisierten Agenten orchestrieren und Teams in unterschiedlichen Phasen der Agentenadoption unterstützen kann.

GitLabs Bewertungen im Überblick

GitLab erzielte Spitzenwerte in drei Kategorien:

Solution Breadth: 100 %. Diese Kategorie bewertet, wie viele Phasen des Software-Lifecycles eine Plattform abdeckt. GitLab erzielt hier den Höchstwert: Die Plattform deckt den gesamten SDLC ab – von Planung und Anforderungen bis zu Deployment und Issue-Management, einschließlich Lifecycle-Phasen, die die meisten KI-Programmierwerkzeuge nicht erreichen. Vorgefertigte Agenten wie Planner Agent und Security Analyst Agent erweitern die KI-Unterstützung auf Sprint-Planung, Vulnerability-Triage und Behebungsempfehlungen – genau die Bereiche des Lifecycles, in denen Auslieferungen ins Stocken geraten.

Strategy and Innovation: 88 %. Hier bewertet Omdia, wie Anbieter ihre Plattform langfristig positionieren und weiterentwickeln. GitLab differenziert durch End-to-End-Orchestrierung, Privacy-first-Architektur ohne Training auf privaten Daten und Multi-Modell-Unterstützung durch Partnerschaften mit Anthropic, Google und AWS. Teams können Modelle je nach Workload und Datenanforderungen auswählen. Der Ansatz der Plattform für einheitlichen Kontext – bei dem Agenten übergreifend an Issues, Merge Requests, Pipelines und Security-Findings zusammenarbeiten, ohne den Zustand zu verlieren – steht beispielhaft für die architektonische Innovation, die Omdia in dieser Kategorie bewertet hat.

Core Features: 82 %. Diese Kategorie erfasst die Tiefe der Kernfunktionen, auf die Entwicklungsteams im Tagesgeschäft angewiesen sind. Code wird mit Echtzeit-Kontext aus IDE und Codebase generiert, über Unit-, Integrations- und Security-Dimensionen getestet und mit integrierter Priorisierung reviewt. Die DevOps-Automatisierung übernimmt CI/CD, GitOps und Root-Cause-Analyse bei Pipeline-Fehlern. Das AI Impact Dashboard bietet Teams messbare Transparenz über Cycle Times, Deployment-Frequenz und die tatsächlichen Auswirkungen von KI auf die Produktivität.

Für Extended Features (80 %) und Vendor Execution (88 %) erhielt GitLab ebenfalls erstklassige Bewertungen.

Die veränderte Rolle von Entwicklungsteams und KI-Agenten

Zu den substanziellen Erkenntnissen des Omdia-Berichts gehört die sich verändernde Rolle der Softwareentwicklung neben diesen Werkzeugen. Entwicklungsteams bestehen zunehmend aus KI-Ingenieuren und ihren KI-Agenten, wobei die Ingenieure die agentische KI überwachen und steuern. Da KI-Codierung den Großteil des Codes generiert, verlagert sich die menschliche Arbeit darauf, sicherzustellen, dass technologische Anforderungen tatsächlich erfüllt werden, Qualität zu überwachen, geeignete Schutzmechanismen zu etablieren, autonome Produktionspipelines zu gestalten und zwischen Geschäftszielen und dem Einsatz agentischer KI im gesamten Software-Lifecycle zu vermitteln.

Dieser Wandel hat Auswirkungen darauf, wie Unternehmen ihre KI-Investitionen bewerten. Ein Team, das die Code-Generierung automatisiert hat, Review, Testing und Deployment aber weiterhin manuell abwickelt, hat die Softwareentwicklung noch nicht grundlegend beschleunigt. Der Produktivitätsgewinn durch schnelleres Programmieren verstärkt sich, wenn der übrige Lifecycle mithalten kann – und er schwindet, wenn er es nicht kann, da sich die Engpässe nur nachgelagert verschieben.

Enterprise-Anforderungen als Grundvoraussetzung

Bemerkenswert an der Struktur der diesjährigen Omdia-Bewertung: Enterprise-Kontrollen und Schutzmechanismen sind keine Bonuskategorie mehr. Compliance-Zertifizierungen, Deployment-Flexibilität und Datenschutzarchitektur gelten als Grundvoraussetzungen für Plattformen auf Leader-Niveau – nicht als Differenzierungsmerkmale. Unternehmen in regulierten Branchen und solche mit Datensouveränitätsanforderungen gewichten diese Faktoren bereits als Einstiegskriterien.

GitLabs Positionierung in diesen Bereichen hebt sich im Markt ab: SOC 2- und ISO 27001-zertifizierte Plattform, Privacy-first-Design ohne Training auf privaten Kundendaten für die agentischen KI-Fähigkeiten, Self-Managed-Deployment-Unterstützung für Cloud und On-Premises (einschließlich Air-Gapped-Umgebungen) sowie Unterstützung für selbstgehostete KI-Modelle. Die Nutzung als Single-Tenant-SaaS-Anwendung über GitLab Dedicated – mit FedRAMP Moderate Authorization über GitLab Dedicated for Government – ergänzt die Deployment-Flexibilität.

Der Omdia-Bericht hat diese Eigenschaften nicht als Funktionsliste bewertet, sondern als Nachweis der Plattformreife für Unternehmen mit den höchsten Compliance-Anforderungen: Finanzdienstleistungen, öffentlicher Sektor, Gesundheitswesen und weitere regulierte Branchen, für die Datenhoheit und Auditierbarkeit nicht verhandelbar sind.

Reifegrad in der Softwareentwicklung einordnen

Für Teams, die ihren KI-Entwicklungsansatz aktiv evaluieren, ist die Empfehlung von Omdia eindeutig: GitLab gehört auf jede Shortlist.

Die entscheidendere Frage für Engineering-Verantwortliche ist nicht, welches KI-Werkzeug den besten Code generiert. Ausschlaggebend ist, ob der generierte Code mit dem erforderlichen Qualitäts-, Sicherheits- und Leistungsniveau in Produktion gebracht werden kann. Er muss von den verantwortlichen Teams verstanden, gesteuert und gewartet werden können. Mit GitLab überträgt sich die Geschwindigkeit beim Programmieren auf den gesamten Entwicklungsprozess.

Wer den Reifegrad der eigenen Organisation in der Softwareentwicklung einordnen möchte, erhält in den Assessments für KI-Modernisierung, DevOps-Modernisierung und Security-Modernisierung eine personalisierte Bewertung und konkrete nächste Schritte.

Den vollständigen Omdia Universe Report herunterladen.

Für Engineering-Leads und Entscheidungsträger: Konzept, Anwendungsfälle und Architekturprinzipien. Konfigurationsdetails folgen in Abschnitt 2.

Die meisten CI/CD-Werkzeuge können einen Build ausführen und ein Deployment anstoßen. Der Unterschied zeigt sich erst dann, wenn die Delivery-Anforderungen komplexer werden: ein Monorepo mit einem Dutzend Services, Microservices über mehrere Repositories verteilt, Deployments in Dutzende von Umgebungen gleichzeitig – oder ein Platform-Team, das organisationsweite Standards durchsetzen will, ohne dabei zum Engpass zu werden.

GitLabs Pipeline-Modell wurde für genau diese Komplexität entwickelt. Parent-Child-Pipelines, DAG-Execution, dynamische Pipeline-Generierung, Multi-Project-Trigger, Merge-Request-Pipelines mit Merged-Results-Verarbeitung und CI/CD Components lösen jeweils eine eigene Klasse von Problemen. Da sich diese Bausteine kombinieren lassen, erschließt das vollständige Modell mehr als nur kürzere Pipeline-Laufzeiten.

Dieser Artikel beschreibt die fünf Muster, bei denen das Modell seine Stärken deutlich zeigt – jeweils zugeordnet zu einem konkreten Engineering-Szenario. Konfigurationen und Implementierungsdetails folgen in Abschnitt 2.

1. Monorepos: Parent-Child-Pipelines und DAG-Execution

Das Problem: Ein Monorepo enthält Frontend, Backend und Dokumentation. Jeder Commit löst einen vollständigen Rebuild aller Komponenten aus – auch wenn sich nur eine README-Datei geändert hat.

GitLab kombiniert zwei sich ergänzende Mechanismen: Parent-Child-Pipelines ermöglichen es einer übergeordneten Pipeline, isolierte Child-Pipelines zu starten. DAG-Execution via needs bricht die starre Stage-Reihenfolge auf und startet Jobs, sobald ihre Abhängigkeiten abgeschlossen sind – nicht erst, wenn alle Jobs einer Stage fertig sind.

Eine Parent-Pipeline erkennt, welche Teile des Repos sich geändert haben, und löst ausschließlich die betroffenen Child-Pipelines aus. Jeder Service verwaltet seine eigene Pipeline-Konfiguration; Änderungen in einem Service können keine anderen beeinflussen. Damit bleibt die Komplexität beherrschbar, während das Repository und das Team wachsen.

Einen technischen Aspekt gilt es dabei zu kennen: Wenn mehrere Dateien an einen einzelnen trigger: include:-Block übergeben werden, fusioniert GitLab sie zu einer einzigen Child-Pipeline-Konfiguration. Jobs aus diesen Dateien teilen denselben Pipeline-Kontext und können sich gegenseitig per needs: referenzieren – das ist die Voraussetzung für die DAG-Optimierung. Werden die Dateien stattdessen auf separate Trigger-Jobs aufgeteilt, entsteht jeweils eine isolierte Pipeline, und dateiübergreifende needs:-Referenzen funktionieren nicht.

In großen Monorepos lassen sich Pipeline-Laufzeiten durch DAG-Execution deutlich reduzieren, da Jobs nicht mehr auf unabhängige Arbeitsschritte in derselben Stage warten.

2. Microservices: Cross-Repo-Pipelines über mehrere Projekte

Das Problem: Frontend und Backend leben in separaten Repositories. Wenn das Frontend-Team eine Änderung ausliefert, ist nicht erkennbar, ob sie die Backend-Integration beeinträchtigt – und umgekehrt.

Multi-Project-Pipelines ermöglichen es, aus einem Projekt heraus eine Pipeline in einem anderen Projekt auszulösen und auf das Ergebnis zu warten. Das auslösende Projekt sieht die verknüpfte Downstream-Pipeline direkt in seiner eigenen Pipeline-Ansicht.

In der Praxis erstellt die Frontend-Pipeline ein API-Contract-Artifact und veröffentlicht es, bevor die Backend-Pipeline ausgelöst wird. Das Backend ruft dieses Artifact über die Jobs API ab und validiert es, bevor weitere Schritte erlaubt sind. Wird eine Breaking Change erkannt, schlägt die Backend-Pipeline fehl – und mit ihr die Frontend-Pipeline. Probleme, die bisher erst in der Produktion sichtbar wurden, werden damit im Pipeline-Prozess abgefangen. Die Abhängigkeit zwischen Services wird sichtbar, nachvollziehbar und aktiv verwaltbar.

Cross-project pipelines

3. Multi-Tenant/Matrix-Deployments: Dynamische Child-Pipelines

Das Problem: Dieselbe Anwendung wird in 15 Kundenumgebungen, drei Cloud-Regionen oder den Stages Dev/Staging/Prod deployed. Manuelle Anpassungen je Umgebung führen zu Konfigurationsdrift. Eine separate Pipeline pro Umgebung ist von Anfang an nicht wartbar.

Dynamische Child-Pipelines generieren die Pipeline-Struktur zur Laufzeit. Ein Job führt ein Skript aus, das eine YAML-Datei erzeugt – und diese YAML-Datei wird zur Pipeline für den nächsten Schritt. Die Pipeline-Struktur selbst wird damit zu Daten.

Das Generierungsskript iteriert über eine ENVIRONMENTS-Variable, statt jede Umgebung fest zu kodieren. Eine neue Umgebung lässt sich durch Anpassen der Variable hinzufügen – ohne Änderungen an der Pipeline-Konfiguration selbst. Trigger-Jobs erben mit extends: eine gemeinsame Template-Konfiguration, sodass strategy: depend einmal definiert und nicht für jeden Trigger-Job wiederholt wird. Ein when: manual-Gate für das Produktions-Deployment ist direkt in den Pipeline-Graph integriert.

Platform-Teams nutzen dieses Muster, um Dutzende von Umgebungen zu verwalten, ohne Pipeline-Logik zu duplizieren.

4. MR-First-Delivery: Merge-Request-Pipelines, Merged-Results und Workflow-Routing

Das Problem: Die Pipeline läuft bei jedem Push auf jeden Branch. Aufwändige Tests werden auf Feature-Branches ausgeführt, die nie gemergt werden. Gleichzeitig gibt es keine Garantie, dass das Getestete dem entspricht, was nach dem Merge auf main tatsächlich landet.

GitLab kombiniert drei ineinandergreifende Mechanismen: Merge-Request-Pipelines laufen ausschließlich dann, wenn ein Merge Request existiert – nicht bei jedem Branch-Push. Allein dadurch entfällt ein erheblicher Anteil unnötiger Compute-Ausführungen. Merged-Results-Pipelines gehen einen Schritt weiter: GitLab erstellt einen temporären Merge-Commit aus dem Branch und dem aktuellen Ziel-Branch und führt die Pipeline dagegen aus. Getestet wird damit das tatsächliche Ergebnis des Merges – nicht der Branch in Isolation. Workflow-Rules definieren schließlich, welcher Pipeline-Typ unter welchen Bedingungen ausgeführt wird. Die $CI_OPEN_MERGE_REQUESTS-Guard verhindert dabei, dass für einen Branch mit offenem MR doppelte Pipelines ausgelöst werden.

Das Ergebnis ist ein Pipeline-Verhalten, das sich je nach Kontext unterscheidet: Ein Push auf einen Feature-Branch ohne offenen MR führt nur Lint und Unit-Tests aus. Sobald ein MR geöffnet wird, wechseln die Workflow-Rules auf eine MR-Pipeline mit der vollständigen Test-Suite gegen das Merged-Result. Ein Merge auf main stellt ein manuelles Produktions-Deployment in die Warteschlange. Der Nightly-Scan läuft einmalig als geplante Pipeline – nicht bei jedem Commit.

Merged-Results-Pipelines fangen dabei die Klasse von Fehlern ab, die erst nach einem Merge sichtbar werden – bevor sie main erreichen.

5. Governed Pipelines: CI/CD Components

Das Problem: Das Platform-Team hat den richtigen Weg für Build, Test und Deploy definiert. Jedes Anwendungsteam pflegt jedoch eine eigene .gitlab-ci.yml mit subtilen Abweichungen. Security-Scanning wird übersprungen. Deployment-Standards driften. Audits werden aufwändig.

CI/CD Components ermöglichen es Platform-Teams, versionierte, wiederverwendbare Pipeline-Bausteine zu veröffentlichen. Anwendungsteams binden sie mit einer einzigen include:-Zeile ein – kein Copy-Paste, kein Drift. Components sind über den CI/CD Catalog auffindbar, sodass Teams bewährte Bausteine finden und übernehmen können, ohne das Platform-Team direkt einschalten zu müssen.

Drei Zeilen include: ersetzen hunderte von duplizierten YAML-Zeilen. Das Platform-Team kann einen Security-Fix in einer neuen Komponentenversion veröffentlichen – Teams steigen auf ihrem eigenen Zeitplan um, oder das Platform-Team fixiert alle auf eine Mindestversion. In beiden Fällen propagiert eine Änderung organisationsweit, statt repo-für-repo angewendet zu werden.

Kombiniert mit Resource Groups zur Vermeidung konkurrierender Deployments und Protected Environments für Freigabe-Gates entsteht eine governed Delivery-Plattform, auf der Compliance der Standard ist, nicht die Ausnahme. Platform-Teams setzen Vorgaben durch, ohne zum Engpass zu werden.

Das Modell als Ganzes

Keines dieser Muster existiert isoliert. Der Wert von GitLabs Pipeline-Modell liegt in der Kombinierbarkeit seiner Bausteine:

• Ein Monorepo nutzt Parent-Child-Pipelines, und jede Child-Pipeline nutzt DAG-Execution.
• Eine Microservices-Plattform nutzt Multi-Project-Pipelines, und jedes Projekt nutzt MR-Pipelines mit Merged-Results.
• Eine governed Plattform nutzt CI/CD Components, um die obigen Muster organisationsweit zu standardisieren.

Die meisten Teams entdecken eines dieser Muster, wenn sie auf ein konkretes Problem stoßen. Teams, die das vollständige Modell verstehen, entwickeln daraus eine Delivery-Infrastruktur, die tatsächlich abbildet, wie ihre Engineering-Organisation arbeitet – und mit ihr wächst.

Weitere Muster

Das Pipeline-Modell geht über die fünf vorgestellten Muster hinaus:

• Review Apps mit dynamischen Umgebungen erstellen für jeden Feature-Branch eine Live-Vorschau und räumen sie automatisch auf, wenn der MR geschlossen wird.
• Caching- und Artifact-Strategien sind nach der strukturellen Arbeit häufig der direkteste Weg zur weiteren Laufzeitoptimierung – ohne die Pipeline-Struktur zu verändern.
• Geplante und API-ausgelöste Pipelines eignen sich für Workloads, die nicht bei jedem Code-Push laufen sollten: Nightly-Security-Scans, Compliance-Reports und Release-Automatisierung lassen sich als geplante oder API-ausgelöste Pipelines mit $CI_PIPELINE_SOURCE-Routing modellieren.

GitLab Ultimate kostenlos testen und Pipeline-Logik ab heute einsetzen.

Für deutsche Unternehmen: Regulatorischer Kontext

Teams, die Pipeline-Governance nach Muster 5 einführen, adressieren dabei möglicherweise auch Anforderungen, die regulatorische Frameworks an sichere Softwareentwicklungsprozesse stellen.

CI/CD Components mit erzwungenen Security-Gates könnten Anforderungen an sichere Entwicklungsprozesse betreffen – beispielsweise in Bereichen, die Frameworks wie NIS2, ISO 27001 oder BSI IT-Grundschutz an den Software-Entwicklungslebenszyklus adressieren. Protected Environments und Resource Groups betreffen ähnliche Themen im Bereich Änderungskontrolle und Umgebungstrennung, wie sie in Governance-Frameworks typischerweise explizit formuliert sind.

Multi-Project-Pipelines mit API-Contract-Validierung (Muster 2) schaffen Sichtbarkeit über Service-Abhängigkeiten hinweg – ein Aspekt, den Frameworks zur Lieferkettensicherheit adressieren.

Merged-Results-Pipelines (Muster 4) dokumentieren automatisch, dass das tatsächliche Merge-Ergebnis getestet wurde, nicht nur der Feature-Branch in Isolation. Dies könnte Anforderungen an nachvollziehbare Änderungsprozesse betreffen, wie sie in Change-Management-Kontrollen verschiedener Sicherheitsframeworks formuliert sind.

Für konkrete Compliance-Anforderungen im eigenen regulatorischen Umfeld empfiehlt sich Rücksprache mit entsprechender Fachberatung.

Abschnitt 2: Konfiguration und Implementierung

Für Entwicklungsteams und DevOps-Praktiker: ausgewählte Konfigurationsbeispiele zu den Mustern 1, 4 und 5. Für vollständige Konfigurationen aller Muster: englischer Originalartikel.

Die folgenden Konfigurationen sind illustrativ aufgebaut. Die Skripte verwenden echo-Befehle, um das Wesentliche sichtbar zu halten. Für den produktiven Einsatz werden die echo-Befehle durch die tatsächlichen Build-, Test- und Deploy-Schritte ersetzt.

Muster 1: Parent-Child-Pipelines und DAG-Execution

Eine Parent-Pipeline erkennt Änderungen und löst nur die betroffenen Child-Pipelines aus:

  - trigger

trigger-services:
  stage: trigger
  trigger:
    include:
      - local: '.gitlab/ci/api-service.yml'
      - local: '.gitlab/ci/web-service.yml'
      - local: '.gitlab/ci/worker-service.yml'
    strategy: depend

Innerhalb der Child-Pipeline ermöglicht needs: DAG-Execution – der Test startet, sobald der Build abgeschlossen ist, ohne auf andere Jobs in derselben Stage zu warten:

  - build
  - test

build-api:
  stage: build
  script:
    - echo "Building API service"

test-api:
  stage: test
  needs: [build-api]
  script:
    - echo "Running API tests"

Muster 4: MR-First-Delivery

Workflow-Rules, MR-Pipelines und Merged-Results zusammen ergeben ein kontextabhängiges Pipeline-Verhalten:

  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "schedule"

stages:
  - fast-checks
  - expensive-tests
  - deploy

lint-code:
  stage: fast-checks
  script:
    - echo "Running linter"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

unit-tests:
  stage: fast-checks
  script:
    - echo "Running unit tests"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

integration-tests:
  stage: expensive-tests
  script:
    - echo "Running integration tests (15 min)"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

e2e-tests:
  stage: expensive-tests
  script:
    - echo "Running E2E tests (30 min)"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

nightly-comprehensive-scan:
  stage: expensive-tests
  script:
    - echo "Running full nightly suite (2 hours)"
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

deploy-production:
  stage: deploy
  script:
    - echo "Deploying to production"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

Muster 5: CI/CD Components

Eine Komponentendefinition aus einer gemeinsamen Bibliothek:

  inputs:
    stage:
      default: deploy
    environment:
      default: production
--- deploy-job:
  stage: $[[ inputs.stage ]]
  script:
    - echo "Deploying $APP_NAME to $[[ inputs.environment ]]"
    - echo "Deploy URL: $DEPLOY_URL"
  environment:
    name: $[[ inputs.environment ]]

So bindet ein Anwendungsteam die Komponenten ein:

  APP_NAME: "my-awesome-app"
  DEPLOY_URL: "https://api.example.com"

include:
  - component: gitlab.com/my-org/component-library/build@v1.0.6
  - component: gitlab.com/my-org/component-library/test@v1.0.6
  - component: gitlab.com/my-org/component-library/deploy@v1.0.6
    inputs:
      environment: staging

stages:
  - build
  - test
  - deploy

Orientierung zu den Mustern 2 und 3

Muster 2 (Multi-Project-Pipelines): Das Frontend-Repository publiziert ein API-Contract-Artifact und löst anschließend die Backend-Pipeline aus. Das Backend ruft das Artifact über die GitLab Jobs API ab und validiert es. Der integration-test-Job läuft dabei nur dann, wenn er von einer Upstream-Pipeline ausgelöst wurde ($CI_PIPELINE_SOURCE == "pipeline"), nicht bei einem eigenständigen Push. Die Frontend-Projekt-ID wird als CI/CD-Variable gesetzt, um Hardcoding zu vermeiden. Vollständige Konfigurationen beider Repositories: englischer Originalartikel.

Muster 3 (Dynamische Child-Pipelines): Ein generate-config-Job erzeugt zur Laufzeit environment-spezifische YAML-Dateien. Trigger-Jobs nutzen extends: für gemeinsam genutzte Konfiguration und needs: für sequenzielle Promotion (dev → staging → prod mit manuellem Gate). Vollständige Konfiguration: englischer Originalartikel.

Weiterführende Artikel

• Variable and artifact sharing in GitLab parent-child pipelines
• CI/CD inputs: Secure and preferred method to pass parameters to a pipeline
• Tutorial: How to set up your first GitLab CI/CD component
• How to include file references in your CI/CD components
• FAQ: GitLab CI/CD Catalog
• Building a GitLab CI/CD pipeline for a monorepo the easy way
• A CI/CD component builder's journey
• CI/CD Catalog goes GA: No more building pipelines from scratch

Vorteile der Integration

Manuelle Uploads entfallen, Nachvollziehbarkeit steigt

DevSecOps-Engineers und QA-Teams müssen Testergebnisse nicht mehr manuell exportieren und importieren – die Komponente übernimmt das automatisch nach jeder Pipeline-Ausführung. Zugleich erhalten Teams vollständige Nachvollziehbarkeit von Anforderungen über Testfälle bis hin zu tatsächlichen Ausführungsergebnissen.

Compliance- und Audit-Anforderungen erfüllen

Für Organisationen in regulierten Branchen ist lückenlose Testdokumentation nicht verhandelbar. Die Integration stellt sicher, dass jede Testausführung in QMetry mit Verknüpfungen zur jeweiligen GitLab-Pipeline, zum Commit und zum Build dokumentiert wird – ohne zusätzlichen manuellen Aufwand.

KI-gestützte Test-Insights nutzen

QMetry analysiert mithilfe von KI Testausführungsmuster, identifiziert instabile Tests, prognostiziert Testfehler und empfiehlt Optimierungsmöglichkeiten. Echtzeit-Daten aus GitLab-Pipelines maximieren den Wert dieser Funktionen.

Über die GitLab-SmartBear-Partnerschaft

Diese Komponente steht für die wachsende Partnerschaft zwischen GitLab und SmartBear, CI/CD-Ausführung und Testmanagement in einem Workflow zu verbinden. Gemeinsam helfen sie Teams, Testing in den Entwicklungszyklus zu integrieren und dabei die Qualitäts-, Sicherheits- und Compliance-Standards ihrer Branchen einzuhalten.

Praxisbeispiele

Finanzdienstleistungen: Enterprise-Banking-Plattformen

Führende Finanzinstitute stehen vor besonderen Herausforderungen beim Skalieren von Testautomatisierung:

• Regulatorische Compliance: Detaillierte Audit-Trails für alle Testaktivitäten erforderlich
• Mehrere Compliance-Frameworks: BaFin BAIT, PSD2, DSGVO und interne Risikomanagement-Richtlinien
• Hochfrequente Deployments: Mehrere Produktions-Deployments täglich über Microservices
• Verteilte Teams: Echtzeit-Transparenz über globale Engineering-Teams hinweg erforderlich Finanzdienstleister, die den QMetry GitLab Component einsetzen, automatisieren Testergebnis-Uploads für Unit-Tests, API-Contract-Tests, End-to-End-Tests für Transaktionsabläufe sowie Security- und Performance-Testergebnisse.

Mögliche Ergebnisse:

• Deutliche Reduzierung des manuellen Test-Reporting-Aufwands
• Vollständige Audit-Trail-Abdeckung für Regulierungsprüfungen
• Echtzeit-Transparenz für verteilte QA-Teams
• Verbesserte Compliance-Position durch vollständige Nachvollziehbarkeit von Anforderungen bis zur Testausführung

Flugregelungssoftware in der Luft- und Raumfahrt

Die Softwareentwicklung in der Luft- und Raumfahrt unterliegt besonderen Anforderungen:

• DO-178C-Compliance: Avioniksoftware muss strikte Zertifizierungsstandards erfüllen
• Vollständige Nachvollziehbarkeit: Jede Anforderung verknüpft mit Testfällen und Ausführungsergebnissen
• Audit-Trails: Zertifizierungsbehörden verlangen detaillierte Aufzeichnungen aller Testaktivitäten
• Mehrere Teststufen: Unit-, Integrations-, System- und Zertifizierungstests Durch die Integration von GitLab CI/CD mit QMetry automatisiert das Aerospace-Engineering-Team Testausführung und Reporting über alle Teststufen hinweg.

Vor der Integration:

• Manueller Export aus GitLab, Import in QMetry über UI-Uploads
• Prozess dauerte 2–3 Stunden pro Testzyklus
• Fehlerrisiko bei der Dateneingabe, verzögerte Rückmeldung an Stakeholder

Nach der Integration:

• Testergebnisse fließen automatisch von GitLab nach QMetry
• Vollständiger Audit-Trail vom Commit über den Test bis zum Ergebnis
• Kein manueller Eingriff, Echtzeit-Transparenz für Zertifizierungsprüfer
• Compliance-Reports werden automatisch erstellt

Beispiel-Dashboard in QMetry nach der Integration:

    ╔════════════════════════════════════════════════════════════╗
    ║  Flight Control System v2.4 - Test Execution Dashboard     ║
    ╠════════════════════════════════════════════════════════════╣
    ║                                                            ║
    ║  📊 Test Execution Summary (Last 7 Days)                   ║
    ║  ───────────────────────────────────────────────────────── ║
    ║  ✓ Total Tests Executed: 1,247                             ║
    ║  ✓ Passed: 1,241 (99.5%)                                   ║
    ║  ✗ Failed: 6 (0.5%)                                        ║
    ║  ⏸ Skipped: 0                                              ║
    ║                                                            ║
    ║  📁 Test Suite Organization                                ║
    ║  ───────────────────────────────────────────────────────── ║
    ║  └─ Certification/                                         ║
    ║     └─ DO-178C/                                            ║
    ║        ├─ Unit/ (487 tests, 100% pass)                     ║
    ║        ├─ Integration/ (623 tests, 99.2% pass)             ║
    ║        └─ System/ (137 tests, 100% pass)                   ║
    ║                                                            ║
    ║  🔗 Traceability                                           ║
    ║  ───────────────────────────────────────────────────────── ║
    ║  Requirements Covered: 342/342 (100%)                      ║
    ║  Test Cases Linked: 1,247/1,247 (100%)                     ║
    ║  GitLab Pipeline Executions: 47 (automated)                ║
    ║                                                            ║
    ║  ⚠️  Action Items                                          ║
    ║  ───────────────────────────────────────────────────────── ║
    ║  • 6 failed tests require investigation                    ║
    ║  • Last execution: 2 minutes ago (Pipeline #1543)          ║
    ║  • GitLab Commit: a7f8c23 "Fix altitude hold logic"        ║
    ║                                                            ║
    ╚════════════════════════════════════════════════════════════╝

Compliance- und Audit-Vorteile

Für Finanzdienstleister (BaFin BAIT, PSD2, SOX):

1. Automatische Nachvollziehbarkeit: Regulatorische Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits verknüpft
2. Auditfähige Dokumentation: Vollständige Testausführungshistorie mit Zeitstempeln und Pipeline-Referenzen
3. Regulatorisches Reporting: Compliance-Reports direkt aus QMetry-Testdaten generieren

Für die Luft- und Raumfahrt-Zertifizierung (DO-178C, DO-254):

1. Automatische Nachverfolgbarkeitsmatrix: Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits
2. Unveränderlicher Audit-Trail: Pipeline-ID, Commit-SHA und Ausführer für jede Testausführung gestempelt
3. Zertifizierungspaket-Generierung: Konforme Dokumentation aus GitLab-Pipeline-Daten

Technische Umsetzung

Dieser Abschnitt orientiert Teams, die die Integration einrichten möchten. Die vollständige Schritt-für-Schritt-Anleitung mit allen Konfigurationsdetails – API-Credentials, CI/CD-Variablen, Testformate, erweiterte Optionen und Fehlerbehebung – ist im englischen Originalbeitrag verfügbar.

Voraussetzungen

• GitLab-Account mit einem Projekt, das automatisierte Tests enthält und Testergebnisdateien erzeugt (JUnit XML, TestNG XML usw.)
• QMetry Test Management Enterprise-Account mit aktiviertem API-Zugriff und generiertem API-Key
• QMetry-Projekt, bereits angelegt, in das Testergebnisse hochgeladen werden sollen
• Kenntnisse in GitLab CI/CD, einschließlich grundlegender .gitlab-ci.yml-Syntax

Ablauf der Testergebnis-Übertragung

1. Testausführung: Die GitLab CI/CD-Pipeline führt automatisierte Tests aus.
2. Ergebnisgenerierung: Tests erzeugen Ausgabedateien (JUnit XML, TestNG XML usw.).
3. Komponentenaufruf: Die QMetry-Komponente wird als Job in der Pipeline ausgeführt.
4. Automatischer Upload: Die Komponente liest die Testergebnisdateien und lädt sie via API nach QMetry hoch.
5. QMetry-Verarbeitung: QMetry empfängt die Ergebnisse und stellt sie für Reporting und Analyse bereit.

Basisintegration

Die Komponente in der .gitlab-ci.yml-Datei einbinden. Die Komponente sollte nach dem Abschluss der Tests ausgeführt werden:

    include:
      - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
        inputs:
          stage: test
          project: "Aerospace Flight Control System"
          file_name: "results.xml"
          testing_type: "JUNIT"
          instance_url: ${INSTANCE_URL}
          api_key: ${QMETRY_API_KEY}

Vollständiges Pipeline-Beispiel

    stages:
      - test
      - report

    variables:
      NODE_VERSION: "18"

    unit-tests:
      stage: test
      image: node:${NODE_VERSION}
      script:
        - npm ci
        - npm run test:unit -- --reporter=junit --reporter-options=output=results.xml
      artifacts:
        reports:
          junit: results.xml
        paths:
          - results.xml
        when: always
      tags:
        - docker

    include:
      - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
        inputs:
          stage: test
          project: "Aerospace Flight Control System"
          file_name: "results.xml"
          testing_type: "JUNIT"
          instance_url: ${INSTANCE_URL}
          api_key: ${QMETRY_API_KEY}

Vollständige Konfigurationsreferenz

Dokumentation und Support

• Komponentendokumentation: GitLab CI/CD Catalog
• Komponenten-Repository: gitlab.com/sb9945614/qtm-gitlab-component
• QMetry-Dokumentation: QMetry Support Portal
• SmartBear-Ressourcen: SmartBear Academy
• GitLab CI/CD-Dokumentation: GitLab CI/CD Documentation
• QMetry-Support: support@smartbear.com – QMetry Community Forum

Innerhalb von 12 Tagen haben vier separate Supply-Chain-Angriffe gezeigt, dass CI/CD-Pipelines zu einem bevorzugten Ziel für versierte Bedrohungsakteure geworden sind.

Zwischen dem 19. und 31. März 2026 kompromittierten Angreifer:

• einen Open-Source-Security-Scanner (Trivy)
• einen Infrastructure-as-Code-Scanner (Checkmarx KICS)
• ein AI-Model-Gateway (LiteLLM)
• einen JavaScript-HTTP-Client (axios)

Alle Angriffe teilten dieselbe Angriffsfläche: die Build-Pipeline.

Dieser Artikel zeigt, was passiert ist, warum Pipelines besonders anfällig sein können und wie zentrale Policy-Durchsetzung mit GitLab – mithilfe der unten beschriebenen Policies – diese Angriffsklassen blockieren, erkennen und eindämmen kann, bevor sie die Produktion erreichen.

Millionenfach vertraut, in Minuten kompromittiert

Hier die Zeitleiste der Supply-Chain-Angriffe:

19. März: Trivy-Security-Scanner wird zum Angriffsvektor

Trivy ist einer der weltweit am häufigsten eingesetzten Open-Source-Vulnerability-Scanner. Es ist das Tool, das Teams innerhalb ihrer Pipelines ausführen, um Schwachstellen zu finden.

Am 19. März nutzte eine Bedrohungsgruppe namens TeamPCP kompromittierte Zugangsdaten, um Schadcode per Force-Push in 76 von 77 Versions-Tags der GitHub Action aquasecurity/trivy-action sowie alle 7 Tags von aquasecurity/setup-trivy einzuschleusen. Gleichzeitig veröffentlichten sie ein trojanisiertes Trivy-Binary (v0.69.4) über offizielle Distributionskanäle. Die Payload war eine Credential-Stealing-Malware, die Umgebungsvariablen, Cloud-Tokens, SSH-Schlüssel und CI/CD-Secrets aus jeder Pipeline exfiltrierte, die einen Trivy-Scan ausführte.

Dem Vorfall wurde CVE-2026-33634 mit einem CVSS-Score von 9,4 zugewiesen. Die Cybersecurity and Infrastructure Security Agency (CISA) nahm ihn innerhalb weniger Tage in den Katalog der bekannten ausgenutzten Schwachstellen auf.

23. März: Checkmarx KICS als nächstes Ziel

Mit gestohlenen Zugangsdaten wandte sich TeamPCP dem Open-Source-Projekt KICS (Keeping Infrastructure as Code Secure) von Checkmarx zu. Sie kompromittierten die GitHub Actions ast-github-action und kics-github-action und schleusten dieselbe Credential-Stealing-Malware ein. Zwischen 12:58 und 16:50 UTC am 23. März exfiltrierte jede CI/CD-Pipeline, die diese Actions referenzierte, im Hintergrund sensible Daten – darunter API-Schlüssel, Datenbankpasswörter, Cloud-Access-Tokens, SSH-Schlüssel und Service-Account-Zugangsdaten.

24. März: LiteLLM über gestohlene Trivy-Zugangsdaten kompromittiert

LiteLLM, ein LLM-API-Proxy mit 95 Millionen monatlichen Downloads, war das nächste Ziel. TeamPCP veröffentlichte kompromittierte Versionen (1.82.7 und 1.82.8) auf PyPI – mithilfe von Zugangsdaten, die aus LiteLLMs eigener CI/CD-Pipeline erbeutet wurden, in der Trivy zum Scannen eingesetzt wurde.

Die Malware in Version 1.82.7 nutzte eine Base64-kodierte Payload, die direkt in litellm/proxy/proxy_server.py injiziert wurde und beim Import ausgeführt wurde. Die Version für 1.82.8 verwendete eine .pth-Datei – ein Python-Mechanismus, der automatisch beim Interpreter-Start ausgeführt wird. Allein die Installation von LiteLLM reichte aus, um die Payload auszulösen. Die Angreifer verschlüsselten die erbeuteten Daten (SSH-Schlüssel, Cloud-Tokens, .env-Dateien, Kryptowährungs-Wallets) und exfiltrierten sie an models.litellm.cloud, eine Lookalike-Domain.

31. März: Quellcode eines AI-Coding-Assistenten durch einfachen Packaging-Fehler geleakt

Während die TeamPCP-Kampagne noch andauerte, lieferte ein Softwareunternehmen ein npm-Paket mit einer 59,8 MB großen Source-Map-Datei aus – die den vollständigen, unminifizierten TypeScript-Quellcode seines AI-Coding-Assistenten referenzierte, gehostet im eigenen Cloudflare-R2-Bucket des Unternehmens.

Das Leak legte 1.900 TypeScript-Dateien, über 512.000 Codezeilen, 44 versteckte Feature-Flags, unveröffentlichte Modell-Codenamen und den vollständigen System-Prompt offen – für jeden, der wusste, wo er suchen musste. Wie der Entwickler Gabriel Anhaia erklärte: „Eine einzige falsch konfigurierte .npmignore- oder files-Angabe in der package.json kann alles offenlegen."

31. März: axios und ein weiterer Trojaner in der Supply Chain

Am selben Tag zielte eine weitere Kampagne auf das npm-Paket axios – einen JavaScript-HTTP-Client mit über 100 Millionen wöchentlichen Downloads.

Über ein kompromittiertes Maintainer-Konto wurden manipulierte Versionen (1.14.1 und 0.30.4) veröffentlicht. Eine eingeschleuste Dependency (plain-crypto-js@4.2.1) installierte einen Remote-Access-Trojaner, der unter macOS, Windows und Linux lauffähig war. Beide Release-Branches wurden innerhalb von 39 Minuten getroffen, und die Malware war so konzipiert, dass sie sich nach der Ausführung selbst löschte.

Die Muster hinter diesen Angriffen

Über alle fünf Vorfälle hinweg zeichnen sich drei Angriffsmuster ab – und alle nutzen das implizite Vertrauen aus, das CI/CD-Pipelines ihren Eingaben entgegenbringen.

Muster 1: Vergiftete Tools und Actions

Die TeamPCP-Kampagne nutzte eine grundlegende Annahme aus: dass die Sicherheitstools, die innerhalb der Pipeline laufen, selbst vertrauenswürdig sind. Wenn ein GitHub-Action-Tag oder eine PyPI-Paketversion auf Schadcode verweist, führt die Pipeline diesen mit vollem Zugriff auf Umgebungs-Secrets, Cloud-Zugangsdaten und Deployment-Tokens aus. Es gibt keinen Verifizierungsschritt, weil die Pipeline dem Tag vertraut.

Empfohlene Pipeline-Kontrolle: Tools und Actions an unveränderliche Referenzen (Commit-SHAs oder Image-Digests) pinnen statt an veränderliche Versions-Tags. Wo Pinning nicht praktikabel ist, die Integrität von Tools und Dependencies gegen bekannte Prüfsummen oder Signaturen verifizieren. Die Ausführung blockieren, wenn die Verifizierung fehlschlägt.

Muster 2: Packaging-Fehlkonfigurationen, die IP leaken

Eine fehlkonfigurierte Build-Pipeline lieferte Debugging-Artefakte direkt im Produktionspaket aus. Eine falsch konfigurierte .npmignore- oder files-Angabe in der package.json reicht dafür aus. Ein Validierungsschritt vor der Veröffentlichung sollte das jedes Mal abfangen.

Empfohlene Pipeline-Kontrolle: Vor jeder Paketveröffentlichung automatisierte Prüfungen ausführen, die den Paketinhalt gegen eine Allowlist validieren, unerwartete Dateien (Source Maps, interne Konfigurationen, .env-Dateien) kennzeichnen und den Publish-Schritt blockieren, wenn die Prüfungen fehlschlagen.

Muster 3: Schwachstellen in transitiven Dependencies

Der axios-Angriff zielte nicht nur auf direkte axios-Nutzer, sondern auf jeden, dessen Dependency-Tree auf die kompromittierte Version auflöste. Eine einzige vergiftete Dependency in einem Lockfile kann sich so über die gesamte Build-Infrastruktur einer Organisation ausbreiten.

Empfohlene Pipeline-Kontrolle: Dependency-Prüfsummen gegen den bekannten Lockfile-Stand vergleichen. Unerwartete neue Dependencies oder Versionsänderungen erkennen. Builds blockieren, die nicht verifizierte Pakete einführen.

Wie GitLab Pipeline Execution Policies jedes Angriffsmuster adressieren

GitLab Pipeline Execution Policies (PEPs) ermöglichen es Security- und Plattformteams, verpflichtende CI/CD-Jobs in jede Pipeline einer Organisation einzufügen – unabhängig davon, was in der .gitlab-ci.yml definiert ist. Durch PEPs definierte Jobs können nicht übersprungen werden, auch nicht mit den Direktiven [skip ci] oder [no_pipeline]. Jobs können in reservierten Stages (.pipeline-policy-pre und .pipeline-policy-post) ausgeführt werden, die die Pipeline des Entwicklungsteams einrahmen.

Wir haben einsatzbereite Pipeline Execution Policies für alle drei Muster als Open-Source-Projekt veröffentlicht: Supply Chain Policies. Diese Policies sind unabhängig voneinander deploybar, und jede wird mit Testdaten für Verstöße ausgeliefert, um sie vorab zu testen. So funktioniert jede einzelne.

Use Case 1: Versehentliche Offenlegung beim Package-Publishing verhindern

Problem: Eine Source-Map-Datei landete im npm-Paket eines AI-Coding-Tools, weil die Build-Pipeline die Validierung beim Publishing übersprungen hatte.

PEP-Ansatz: Wir haben eine Open-Source Pipeline Execution Policy für genau diese Fehlerklasse erstellt: Artifact Hygiene.

Die Policy injiziert .pipeline-policy-pre-Jobs, die den Artefakttyp (npm-Paket, Docker-Image oder Helm-Chart) automatisch erkennen und den Inhalt prüfen, bevor ein Publish-Schritt ausgeführt wird. Für npm-Pakete führt sie drei Prüfungen durch:

1. File-Pattern-Blocklist. Scannt die npm-pack-Ausgabe nach Source Maps (.map), Testverzeichnissen, Build-Konfigurationen, IDE-Einstellungen und src/-Verzeichnissen.
2. Package-Size-Gate. Blockiert Pakete über 50 MB – wie das 59,8-MB-Paket, das den AI-Tool-Quellcode leakte.
3. sourceMappingURL-Scan. Erkennt externe URLs (das R2-Bucket-Muster, das den Quellcode eines großen AI-Unternehmens offenlegte), Inline-data:-URIs und lokale Dateireferenzen in JavaScript-Bundles.

Wenn Verstöße gefunden werden, schlägt die Pipeline mit einem klaren Bericht in den CI-Job-Logs fehl:

=============================================
FAILED: 3 violation(s) found
=============================================
BLOCKED: dist/index.js.map (matched: \.map$)
BLOCKED: dist/index.js contains external sourceMappingURL
BLOCKED: dist/utils.js contains inline sourceMappingURL

This check is enforced by a Pipeline Execution Policy.
If this is a false positive, contact the security team to update the policy project or exclude this project.

Die Policy hat keine vom Nutzer konfigurierbaren CI-Variablen. Das Entwicklungsteam kann sie weder deaktivieren noch umgehen. Ausnahmen werden vom Security-Team auf Policy-Ebene verwaltet – das gewährleistet einen bewussten Prozess und einen lückenlosen Audit-Trail.

Das Repository enthält ein Testprojekt mit absichtlichen Verstößen (examples/leaky-npm-package/), um die Policy in Aktion zu sehen, bevor sie in der Organisation ausgerollt wird. Die README enthält eine vollständige Schnellstart-Anleitung für Einrichtung und Deployment.

Was das abfängt: Jede einzelne dieser Kontrollen hätte das Source-Code-Leak des AI-Unternehmens wahrscheinlich verhindert:

• Die Source-Map-Datei löst die File-Pattern-Blocklist aus.
• Die Größe von 59,8 MB löst das Size-Gate aus.
• Die sourceMappingURL mit Verweis auf einen externen R2-Bucket löst den URL-Scan aus.

Use Case 2: Dependency-Tampering und Lockfile-Manipulation erkennen

Problem: Der axios-Angriff führte eine bösartige transitive Dependency (plain-crypto-js) ein, die bei der Installation einen RAT ausführte. Jeder, der während des Kompromittierungsfensters npm install ausführte, zog den Trojaner mit.

PEP-Ansatz: Die Dependency Integrity Policy injiziert .pipeline-policy-pre-Jobs, die das Paket-Ökosystem (npm oder Python) automatisch erkennen und drei Prüfungen durchführen:

Für npm-Projekte (ausgelöst durch package-lock.json, yarn.lock oder pnpm-lock.yaml):

1. Lockfile-Integrität. Führt npm ci --ignore-scripts aus, was fehlschlägt, wenn sich node_modules vom Lockfile-Stand unterscheiden würden. Dies erkennt Fälle, in denen die package.json aktualisiert, aber das Lockfile nicht neu generiert wurde, und verifiziert gleichzeitig SRI-Integritäts-Hashes.
2. Blocked-Package-Scan. Gleicht den vollständigen Dependency-Tree des Lockfiles mit blocked-packages.yml ab – einer von GitLab gepflegten Liste bekannter kompromittierter Paketversionen. Die mitgelieferte Blocklist enthält axios@1.14.1, axios@0.30.4 und plain-crypto-js@4.2.1.
3. Erkennung nicht deklarierter Dependencies. Vergleicht nach der Installation den Inhalt von node_modules mit dem Lockfile. Jedes Paket, das auf der Festplatte vorhanden, aber nicht im Lockfile aufgeführt ist, deutet auf Manipulation hin (z. B. ein kompromittiertes postinstall-Skript, das zusätzliche Pakete nachlädt).

Für Python-Projekte (ausgelöst durch requirements.txt, Pipfile.lock, poetry.lock oder uv.lock):

1. Lockfile-Integrität. Installation in einer isolierten virtuellen Umgebung mit Verifizierung, dass die Installation aus dem Lockfile erfolgreich ist.
2. Blocked-Package-Scan. Derselbe Blocklist-Ansatz. Die mitgelieferte Liste enthält litellm==1.82.7 und litellm==1.82.8.
3. .pth-Datei-Erkennung. Scannt site-packages nach .pth-Dateien, die ausführbare Code-Muster enthalten (import os, exec(, eval(, __import__, subprocess, socket). Genau diesen Mechanismus nutzte die LiteLLM-Backdoor.

Bei einem erkannten Verstoß:

=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: axios@1.14.1 is a known-compromised package

This check is enforced by a Pipeline Execution Policy.

Die Policy läuft im Strict Mode: Jede Dependency, die nicht im committeten Lockfile vorhanden ist, blockiert die Pipeline. Wenn eine neue Dependency hinzugefügt werden soll, wird das aktualisierte Lockfile committet. Die Policy verifiziert, dass die installierte Version mit der committeten Version übereinstimmt. Wenn etwas auftaucht, das nicht committet wurde (z. B. eine transitive Dependency, die über ein kompromittiertes Upstream-Paket injiziert wurde), blockiert die Pipeline.

Was das abfängt: Die Einführung von plain-crypto-js als neue, bisher unbekannte Dependency würde durch die Erkennung nicht deklarierter Dependencies gemeldet. Die Version axios@1.14.1 wird durch den Blocked-Package-Scan erkannt. Die .pth-Datei von LiteLLM wird durch die .pth-Erkennung gefunden. Jeder Angriff hat mindestens ein – und oft zwei – unabhängige Erkennungssignale.

Use Case 3: Kompromittierte Tools vor der Ausführung erkennen und blockieren

Problem: TeamPCP ersetzte vertrauenswürdige Trivy- und Checkmarx-GitHub-Action-Tags durch bösartige Versionen. Jede Pipeline, die diese Tags referenzierte, führte Credential-Stealing-Malware aus.

PEP-Ansatz: Die Tool Integrity Policy injiziert einen .pipeline-policy-pre-Job, der die GitLab CI Lint API abfragt (oder als Fallback die .gitlab-ci.yml auswertet), die Container-Image-Referenzen extrahiert und mit einer vom Security-Team gepflegten Allowlist genehmigter Images abgleicht.

Die Allowlist (approved-images.yml) unterstützt drei Kontrollen pro Image:

Genehmigte Repositories: Nur Images aus gelisteten Repositories sind zulässig. Ein unbekanntes Repository blockiert die Pipeline.

Erlaubte Tags: Innerhalb eines genehmigten Repositorys sind nur bestimmte Tags zulässig. Das verhindert den Drift zu ungetesteten Versionen.

Blockierte Tags: Bekannte kompromittierte Versionen können explizit blockiert werden, selbst wenn das Repository genehmigt ist. Die mitgelieferte Allowlist blockiert aquasec/trivy:0.69.4 bis 0.69.6 – genau die Versionen, die TeamPCP trojanisiert hatte.

Bei einem erkannten Verstoß schlägt die Pipeline fehl, bevor ein anderer Job ausgeführt wird:

=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)
 - tag '0.69.4' is known-compromised
This check is enforced by a Pipeline Execution Policy.

Die Allowlist wird über Merge Requests gegen das Policy-Projekt gepflegt. Um ein neues genehmigtes Image hinzuzufügen, öffnet das Security-Team einen MR. Um auf eine neue Kompromittierung zu reagieren, wird ein blockierter Tag hinzugefügt. Keine Code-Änderungen nötig – nur YAML.

Was das abfängt: Wenn Images mit nicht genehmigten Tags erkannt werden, vergleicht die Policy die Image-Repository-Namen und Tags mit der Allowlist. Ein fehlgeschlagener Abgleich blockiert die Pipeline, bevor ein Scanner ausgeführt wird – und verhindert so die Exfiltration von Zugangsdaten.

Hinweis: Durch Erweiterung des obigen Beispiels können PEPs auch das Pinning auf Digests statt Tags erzwingen, was gegen Force-Pushes immun ist. Dieses Beispiel demonstriert ein einfacheres Tag-basiertes Enforcement-Muster.

Über PEPs hinaus: GitLabs Supply-Chain-Schutzmaßnahmen

Pipeline Execution Policies sind die Enforcement-Schicht – sie funktionieren aber am besten als Teil einer breiteren Defense-in-Depth-Strategie. GitLab bietet mehrere Funktionen, die PEPs beim Supply-Chain-Schutz ergänzen:

Secret Detection

GitLab Secret Detection verhindert, dass Zugangsdaten überhaupt im Repository landen, und reduziert so erheblich, was ein kompromittiertes Pipeline-Tool abgreifen kann. Im Kontext der Angriffe vom März 2026:

• In Repositories gespeicherte Zugangsdaten sind sowohl leichter für Angreifer auffindbar als auch langsamer zu rotieren. Der Trivy-Vorfall zeigte, dass selbst der Rotationsprozess ausgenutzt werden kann: Die Rotation von Aqua Security war nicht atomar, und der Angreifer erbeutete neu ausgestellte Tokens, bevor die alten vollständig widerrufen waren. GitLab Secret Detection umfasst die automatische Revokation geleakter GitLab-Tokens sowie eine Partner-API, die Drittanbieter benachrichtigt, damit diese ihre Zugangsdaten widerrufen – das beschleunigt die Reaktion im Falle eines Sicherheitsvorfalls.
• Secret Detection in Kombination mit ordnungsgemäßem Secret-Management (kurzlebige Tokens, Vault-gestützte Zugangsdaten, minimale Pipeline-Secret-Exposition) begrenzt, was ein Angreifer erreichen kann – selbst wenn ein vertrauenswürdiges Tool kompromittiert wird.

Dependency Scanning via Software Composition Analysis (SCA)

GitLab Dependency Scanning identifiziert bekannte Schwachstellen in Projektabhängigkeiten durch Analyse von Lockfiles und Manifests. Im Kontext der Angriffe vom März 2026:

• Für LiteLLM werden die kompromittierten Versionen (1.82.7, 1.82.8) in GitLabs Advisory-Datenbank geführt und betroffene Python-Projekte automatisch gemeldet.
• Für axios identifiziert Dependency Scanning die kompromittierten Versionen (1.14.1, 0.30.4) über alle Projekte der Organisation hinweg – das gibt Security-Teams eine zentrale Ansicht zur Bewertung des Blast-Radius und zur Priorisierung der Credential-Rotation.
• Ebenso werden alle npm-Pakete, die durch die CanisterWorm-Propagation von TeamPCP kompromittiert wurden, gemeldet, wenn sie in Verwendung sind.

GitLab Container Scanning erkennt verwundbare Container-Images in den Deployments. Für den Trivy-Vorfall meldet Container Scanning die trojanisierten Trivy-Docker-Images (0.69.4 bis 0.69.6), wenn sie in der Container Registry oder in Deployment-Manifests auftauchen.

Merge-Request-Approval-Policies

Merge-Request-Approval-Policies können die Genehmigung durch das Security-Team erfordern, bevor Änderungen an Dependency-Lockfiles oder CI/CD-Konfigurationen gemergt werden. Das stellt einen menschlichen Kontrollpunkt für genau die Art von Änderungen sicher, die Supply-Chain-Angriffe typischerweise einführen.

Demnächst: Dependency Firewall, Artifact Registry und SLSA Level 3 Attestation & Verification

Kommende Supply-Chain-Sicherheitsfunktionen in GitLab härten die Policy-Durchsetzung an zwei kritischen Kontrollpunkten: der Registry und der Pipeline. Die Dependency Firewall und Artifact Registry werden nicht-konforme Pakete blockieren, während die SLSA-Level-3-Attestation kryptografischen Nachweis liefert, dass Artefakte von genehmigten Pipelines erzeugt wurden und unverändert geblieben sind. Zusammen geben sie Security-Teams verifizierbare Kontrolle darüber, was in die Software-Supply-Chain eingeht und diese verlässt.

Was das für deine Organisation bedeutet

Inmitten zunehmender AI-gestützter Bedrohungen werden Angriffe auf CI/CD-Pipelines alltäglich. Die TeamPCP-Kampagne zeigt, wie ein einziges kompromittiertes Zugangsdaten-Set über ein Ökosystem vertrauenswürdiger Tools kaskadieren kann.

Wenn deine Organisation eine der betroffenen Komponenten eingesetzt hat, gehe davon aus, dass alle Pipeline-Secrets kompromittiert wurden: Rotiere sie umgehend und überprüfe Systeme auf persistente Backdoors. Unabhängig davon begrenzt die regelmäßige Rotation von Zugangsdaten und die Verwendung kurzlebiger Tokens den Blast-Radius jeder zukünftigen Kompromittierung.

Folgendes empfehlen wir:

1. Dependencies wenn möglich an Prüfsummen pinnen. Veränderliche Versions-Tags (wie die, die TeamPCP gekapert hat) sind keine Sicherheitsgrenze. SHA-gepinnte Referenzen für alle CI/CD-Komponenten oder Actions und Container-Images verwenden.
2. Pre-Execution-Integritätsprüfungen ausführen. Pipeline Execution Policies nutzen, um die Integrität von Tools und Dependencies vor der Ausführung jedes Pipeline-Jobs zu verifizieren. Das ist die .pipeline-policy-pre-Stage.
3. Prüfen, was veröffentlicht wird. Jeder Package-Publish-Schritt sollte eine automatisierte Validierung des Artefaktinhalts umfassen. Source Maps, Environment-Dateien und interne Konfigurationen sollten die Build-Umgebung niemals verlassen. Das Supply Chain Policy-Projekt bietet einen sofort einsetzbaren Ausgangspunkt für npm-, Docker- und Helm-Artefakte.
4. Dependency-Drift erkennen. Dependency-Auflösungen bei jedem Pipeline-Lauf gegen committete Lockfiles vergleichen. Auf unerwartete neue Dependencies achten.
5. Policy-Management zentralisieren. Sich nicht darauf verlassen, dass Entwicklungsteams daran denken, Security-Checks einzubinden. Diese auf Gruppen- oder Instanzebene über Policies durchsetzen, die nicht entfernt oder übersprungen werden können.
6. Davon ausgehen, dass Security-Tools selbst Ziele sind. Wenn dein Vulnerability-Scanner, SAST-Tool oder AI-Gateway kompromittiert werden kann, wird es das auch. Jedes Tool auf die minimal notwendigen Berechtigungen beschränken und sicherstellen, dass es auf nichts anderes zugreifen kann.

Schütze deine Pipelines mit GitLab

Innerhalb von zwei Wochen kompromittierten Angreifer Produktions-Pipelines bei Organisationen, die einige der am weitesten verbreiteten Tools im Software-Entwicklungs-Ökosystem einsetzten.

Die Lektion ist klar: Build-Pipelines brauchen denselben Grad an zentralem, Policy-gesteuertem Schutz, den wir auf Netzwerke und Cloud-Infrastruktur anwenden.

GitLab Pipeline Execution Policies bieten diese Enforcement-Schicht. Sie stellen sicher, dass Security-Checks in jeder Pipeline und in jedem Projekt ausgeführt werden – unabhängig von den einzelnen Projektkonfigurationen. In Kombination mit Dependency Scanning, Secret Detection und Merge-Request-Approval-Policies können sie die Angriffsklassen, die wir im März 2026 erlebt haben, blockieren, erkennen und eindämmen.

Das Supply Chain Policies-Projekt bietet eine funktionsfähige Pipeline Execution Policy, die genau die Fehlerklasse abfängt, die hinter dem Leak des großen AI-Unternehmens steckt – mit Abdeckung für npm-Pakete, Docker-Images und Helm-Charts. Klone es, deploye es in deiner Gruppe und stelle sicher, dass alle deine Pipelines für kommende Supply-Chain-Angriffe gewappnet sind.

Um mit zentralen Pipeline-Policies zu starten, registriere dich für eine kostenlose Testversion von GitLab Ultimate.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Abschnitt 27A des Securities Act von 1933 in der jeweils gültigen Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir davon ausgehen, dass die in diesen Aussagen wiedergegebenen Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren finden sich unter der Überschrift „Risk Factors" in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu revidieren, sofern dies nicht gesetzlich vorgeschrieben ist.

GitLab Duo CLI bringt die agentenbasierte KI der Duo Agent Platform ins Terminal – mit vollständiger Unterstützung für automatisierte Workflows und einem interaktiven Chat-Modus, wenn ein Mensch im Loop bleiben soll. Dieser Artikel beschreibt, was Duo CLI leistet, wie die beiden Betriebsmodi funktionieren und welches Sicherheitsmodell dahintersteht.

GitLab Duo CLI installieren

Wer GLab (die GitLab CLI) bereits installiert hat, führt folgenden Befehl aus:

glab duo cli

Anschließend einfach den Anweisungen folgen.

Ohne GLab: Hier installieren oder Duo CLI als eigenständiges Tool verwenden.

Warum das Terminal – und warum jetzt

Die erste Generation von KI-Assistenten für die Softwareentwicklung war auf die IDE ausgerichtet und konzentrierte sich ausschließlich auf Code-Erstellung. Das war sinnvoll, solange Autovervollständigung im Vordergrund stand. Sobald KI-Agenten jedoch eigenständig handeln – Tests ausführen, Pipelines auslösen, Vulnerability-Scans überwachen und mehr – reicht die IDE als einzige Abstraktionsebene nicht mehr aus.

Die besten Entwickler-Tools funktionieren sowohl für Menschen als auch für Maschinen. CLIs haben sich über Jahrzehnte in genau diese Richtung entwickelt. Sie sind komponierbar: Output lässt sich weiterleiten, Befehle verketten, Skripte einbetten. Sie sind nachvollziehbar: Wenn etwas schiefläuft, führt man denselben Befehl aus und sieht genau, was der Agent gesehen hat. Und sie sind transparent: keine Hintergrundprozesse, kein Initialisierungsaufwand, kein Protokoll, das beim Fehlerfall erst entschlüsselt werden muss.

Terminal-Interfaces eignen sich besser für Automatisierung, Scripting und portable Umgebungen. IDE-Interfaces bieten sich für interaktive, kontextreiche Entwicklung an. GitLab Duo CLI ist für ersteres ausgelegt – Duo Agentic Chat in IDE und UI deckt letzteres ab.

Was GitLab Duo CLI kann

Mit GitLab Duo CLI lässt sich Code erstellen, anpassen, refaktorieren und modernisieren – vergleichbar mit anderen KI-gestützten Coding-Assistenten für das Terminal. Darüber hinaus sind alle Agenten und Flows der GitLab Duo Agent Platform über Duo CLI zugänglich: von der Automatisierung von CI/CD-Konfigurationen und Pipeline-Optimierungen bis hin zur autonomen Ausführung mehrstufiger Entwicklungsaufgaben über den gesamten Software-Lebenszyklus.

GitLab Duo CLI läuft in zwei Modi:

• Interaktiver Modus – eine editor-unabhängige Terminal-Chat-Umgebung mit menschlicher Freigabe vor jeder Aktion. Geeignet für das Verstehen von Codebase-Strukturen, das Erstellen von Code, die Fehlersuche oder das Troubleshooting von Pipelines.
• Headless-Modus – nicht-interaktiv, ausgelegt für Runner, Skripte und automatisierte Workflows. Direkt in CI/CD einbinden, ohne manuelle Eingriffe.

KI mit Leitplanken

Agentenbasierte KI, die eigenständig Aktionen ausführen kann, birgt reale Sicherheitsrisiken. GitLab Duo CLI adressiert diese auf Plattformebene – nicht nachträglich:

• Human-in-the-Loop standardmäßig im interaktiven Modus: Keine Aktion wird ohne Freigabe ausgeführt.
• Prompt-Injection-Erkennung ist in der GitLab Duo Agent Platform integriert, nicht nachgerüstet.
• Composite Identity – eine kombinierte Identität, die sowohl den Nutzenden als auch den Agenten repräsentiert – begrenzt die Zugriffsrechte des Agenten und macht jede KI-gesteuerte Aktion nachvollziehbar.

GitLab Duo CLI unterstützt darüber hinaus benutzerdefinierte Instruktionsdateien – z. B. chat-rules.md, AGENTS.md und SKILL.md – die festlegen, welche Aufgaben, Ressourcen, Kontexte und Aktionen ein Agent ausführen darf. Das ist das Prinzip der minimalen Rechtevergabe auf KI angewendet: Der Agent tut genau das, wozu er autorisiert wurde – und nichts darüber hinaus.

GitLab Duo CLI in Aktion:

GitLab Duo CLI ausprobieren

Den Einstieg bietet ein kostenloser Test der GitLab Duo Agent Platform.

Wer GitLab bereits im Free Tier nutzt, kann GitLab Duo Agent Platform durch wenige einfache Schritte aktivieren.

Bestehende GitLab-Premium- oder -Ultimate-Abonnenten können Duo CLI nutzen, indem sie Duo Agent Platform aktivieren – die benötigten GitLab Credits sind im jeweiligen Abonnement bereits enthalten.

Wochen Entwicklungsarbeit, abgeschlossenes Code-Review, alle Tests grün. Das Feature gelangt in die Produktion – und innerhalb einer Stunde treffen Fehlerberichte ein. Der Code verhält sich für die meisten Nutzenden korrekt, aber bestimmte Produktions-Szenarien, die im Staging nicht aufgetreten sind, führen bei einem Teil der Nutzenden zu Ausfällen. Das Ergebnis: ungeplanter Rollback, Incident-Dokumentation, Ursachenanalyse.

Feature Flags verhindern genau das. Das Prinzip: Deployment und Release werden entkoppelt. Code gelangt in die Produktion, sobald er bereit ist – wer das neue Feature tatsächlich sieht, wird unabhängig davon über einen Schalter in GitLab gesteuert. Kein Redeployment, kein Hotfix, keine ungeplante Rollback-Prozedur.

Systematisch gesteuerte Rollouts

Der eigentliche Wert von Feature Flags liegt in der schrittweisen Freigabe. Ein typischer Ablauf:

1. QA-Team (User-IDs-Strategie): Das Feature ist nur für interne Tester sichtbar. Probleme werden erkannt, bevor externe Nutzende betroffen sind.
2. Prozentualer Rollout (z. B. 10 %): Das Feature wird für einen definierten Anteil der Nutzenden aktiviert. Metriken und Fehlerraten lassen sich unter realen Bedingungen beobachten.
3. Vollständige Freigabe: Erst wenn das Verhalten in der Produktion validiert ist, wird das Feature für alle aktiviert.

Tritt auf einer Stufe ein Problem auf, reicht ein Klick in der GitLab-Oberfläche, um das Feature zu deaktivieren – ohne Code-Änderung, ohne Pipeline.

Skalierung und Produktionsbetrieb

GitLab stellt für jedes Projekt eine Unleash-kompatible API bereit. Der Unleash-SDK pollt die Flag-Definitionen beim Start und danach in einem konfigurierbaren Intervall (im Demo-Projekt: 15 Sekunden). Die Auswertung erfolgt lokal aus dem Cache – kein Netzwerkaufruf pro Flag-Abfrage, kein Latenzeinfluss auf den Request.

Für kleinere Deployments ist das 15-Sekunden-Intervall gut geeignet. Bei Deployments mit vielen App-Instanzen von derselben IP-Adresse gilt: GitLab.com unterstützt bei diesem Intervall rund 125 Clients, bevor Rate-Limits greifen. Für größere Produktionsumgebungen empfiehlt sich ein vorgelagerter Unleash Proxy, der Anfragen mehrerer Instanzen bündelt.

Sicherheitsrelevante Aspekte

• Keine Credentials im Quellcode: Instance ID und alle Tokens gehören in Umgebungsvariablen, nicht in den Code.
• Instance ID ist read-only: Sie erlaubt ausschließlich das Abrufen von Flag-Zuständen, keine Änderungen. Trotzdem als Secret behandeln.
• Debug-Modus deaktiviert lassen: Flasks Debug-Modus ermöglicht Remote Code Execution – in der Produktion zwingend deaktiviert.
• Abhängigkeiten aktuell halten: Dependency Scanning in der CI/CD-Pipeline aktivieren, um Schwachstellen in gepinnten Versionen zu erkennen.

Schritt-für-Schritt: Integration in eine Python-Flask-App

Dieser Abschnitt gibt einen Überblick über die technische Integration. Die vollständige Implementierung – alle Schritte, der komplette Code und ein lauffähiges Demo-Projekt – ist im englischen Originalartikel beschrieben. Das Demo-Repository steht unter gitlab.com/omid-blogs/gitlab-feature-flags-demo zum Forken bereit.

SDK vs. GitLab REST API

Für eine App, die Flags bei jedem Request auswertet, ist der SDK die geeignete Wahl:

Kernmuster der Integration

Die gesamte Integration besteht aus einer Abhängigkeit (UnleashClient), drei Umgebungsvariablen und einem Methodenaufruf.

SDK initialisieren:

    url=UNLEASH_URL,
    app_name=UNLEASH_APP_NAME,
    instance_id=UNLEASH_INSTANCE_ID,
    refresh_interval=15,
    metrics_interval=60,
)
unleash_client.initialize_client() ```

**Flag abfragen:**

```python def is_flag_enabled(flag_name):
    return unleash_client.is_enabled(flag_name)

is_enabled() wertet lokal aus dem Cache aus – kein Netzwerkaufruf, kein Latenzeinfluss auf den Request.

Nutzerkontext für gezieltes Targeting übergeben:

    'new_layout',
    context={'userId': current_user.id}
) ```

Der SDK übernimmt das konsistente Hashing für prozentuale Rollouts. Für die vollständige Einrichtung – Flags in GitLab anlegen, Unleash-Credentials abrufen, App lokal ausführen und Flags in Echtzeit umschalten – siehe den [englischen Originalartikel](https://about.gitlab.com/blog/getting-started-with-gitlab-feature-flags-in-python/).

### Ressourcen

* [Demo-Projekt auf GitLab](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo)
* [GitLab Feature-Flags-Dokumentation](https://docs.gitlab.com/operations/feature_flags/)
* [Unleash Python SDK auf GitHub](https://github.com/Unleash/unleash-python-sdk)

Mit den Auto-Dismiss-Richtlinien für Schwachstellen lassen sich Triage-Entscheidungen einmalig in Richtlinien festlegen und automatisch auf jede Pipeline des Standard-Branches anwenden. Kriterien werden anhand von Dateipfad, Verzeichnis oder Schwachstellen-Kennung (CVE, CWE) definiert, ein Abweisungsgrund festgelegt – und GitLab übernimmt den Rest.

Warum Auto-Dismiss?

Auto-Dismiss-Richtlinien ermöglichen Security-Teams:

• Triage-Aufwand reduzieren: Findings in Testcode, eingebetteten Abhängigkeiten und generierten Dateien werden automatisch abgewiesen.
• Entscheidungen organisationsweit durchsetzen: Bekannte False Positives lassen sich zentral über die gesamte Organisation hinweg abweisen.
• Prüfnachweise sicherstellen: Jeder automatisch abgewiesene Fund enthält einen dokumentierten Abweisungsgrund mit Verweis auf die auslösende Richtlinie.
• Datenbasis erhalten: Im Gegensatz zu Scanner-Ausschlüssen verbleiben abgewiesene Schwachstellen im Report – Entscheidungen lassen sich bei veränderten Bedingungen jederzeit überprüfen.

So funktionieren Auto-Dismiss-Richtlinien

1. Richtlinie definieren: In einer YAML-Richtliniendatei Abgleichkriterien (Dateipfad, Verzeichnis oder Kennung) und einen Abweisungsgrund festlegen.
2. Zusammenführen und aktivieren: Richtlinie über Secure > Policies > New policy > Vulnerability management policy erstellen. Nach dem Merge des MR ist sie aktiv.
3. Pipeline ausführen: Bei jeder Pipeline des Standard-Branches werden übereinstimmende Schwachstellen automatisch auf „Dismissed" gesetzt und mit dem festgelegten Grund versehen. Pro Ausführung werden bis zu 1.000 Schwachstellen verarbeitet.
4. Ergebnis prüfen: Den Vulnerability-Report nach Status „Dismissed" filtern – so lässt sich nachvollziehen, welche Findings bereinigt wurden und ob die richtigen Einträge erfasst werden.

Anwendungsfälle mit einsatzbereiten Konfigurationen

Jedes Beispiel enthält eine Richtlinienkonfiguration, die direkt kopiert, angepasst und eingesetzt werden kann.

1. Schwachstellen in Testcode abweisen

SAST- und Dependency-Scanner melden hartcodierte Zugangsdaten, unsichere Fixtures und entwicklungsspezifische Abhängigkeiten in Testverzeichnissen. Diese stellen kein Produktionsrisiko dar.

vulnerability_management_policy:
  - name: "Dismiss test code vulnerabilities"
    description: "Auto-dismiss findings in test directories"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: file_path
            value: "test/**/*"
      - type: detected
        criteria:
          - type: file_path
            value: "tests/**/*"
      - type: detected
        criteria:
          - type: file_path
            value: "spec/**/*"
      - type: detected
        criteria:
          - type: directory
            value: "__tests__/*"
    actions:
      - type: auto_dismiss
        dismissal_reason: used_in_tests

2. Eingebetteten und Drittanbieter-Code abweisen

Schwachstellen in vendor/, third_party/ oder eingecheckten node_modules werden upstream verwaltet und sind für das eigene Team nicht direkt behebbar.

vulnerability_management_policy:
  - name: "Dismiss vendored dependency findings"
    description: "Findings in vendored code are managed upstream"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: directory
            value: "vendor/*"
      - type: detected
        criteria:
          - type: directory
            value: "third_party/*"
      - type: detected
        criteria:
          - type: directory
            value: "vendored/*"
    actions:
      - type: auto_dismiss
        dismissal_reason: not_applicable

3. Falsch-Positiv-CVEs abweisen

Bestimmte CVEs werden wiederholt gemeldet, gelten im eigenen Nutzungskontext aber als nicht zutreffend. Bisher wurden diese bei jedem Auftreten manuell abgewiesen. Die Beispiel-CVEs unten durch eigene ersetzen.

vulnerability_management_policy:
  - name: "Dismiss known false positive CVEs"
    description: "CVEs confirmed as false positives for our environment"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2023-44487"
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2024-29041"
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2023-26136"
    actions:
      - type: auto_dismiss
        dismissal_reason: false_positive

4. Generierten und automatisch erstellten Code abweisen

Protobuf-, gRPC-, OpenAPI-Generatoren und ORM-Scaffolding-Tools erzeugen Dateien mit gemeldeten Mustern, die vom eigenen Team nicht gepatcht werden können.

vulnerability_management_policy:
  - name: "Dismiss generated code findings"
    description: "Generated files are not authored by us"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: directory
            value: "generated/*"
      - type: detected
        criteria:
          - type: file_path
            value: "**/*.pb.go"
      - type: detected
        criteria:
          - type: file_path
            value: "**/*.generated.*"
    actions:
      - type: auto_dismiss
        dismissal_reason: not_applicable

5. Durch Infrastruktur abgemilderte Schwachstellen abweisen

Schwachstellenklassen wie XSS (CWE-79) oder SQL-Injection (CWE-89), die durch WAF-Regeln oder Laufzeitschutz bereits adressiert sind. Diese Konfiguration nur einsetzen, wenn die abmildernden Kontrollen nachweislich vorhanden und durchgängig durchgesetzt sind – eine lückenhafte Durchsetzung macht die Abweisung ungültig.

vulnerability_management_policy:
  - name: "Dismiss CWEs mitigated by WAF"
    description: "XSS and SQLi mitigated by WAF rules"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CWE-79"
      - type: detected
        criteria:
          - type: identifier
            value: "CWE-89"
    actions:
      - type: auto_dismiss
        dismissal_reason: mitigating_control

6. CVE-Familien organisationsweit abweisen

Bei einer Welle verwandter CVEs für eine weit verbreitete Bibliothek, die das Team bereits bewertet hat: Richtlinie auf Gruppenebene anwenden und über Dutzende Projekte hinweg abweisen. Das Wildcard-Muster (z. B. CVE-2021-44*) erfasst alle CVEs mit diesem Präfix.

vulnerability_management_policy:
  - name: "Accept risk for log4j CVE family"
    description: "Log4j CVEs mitigated by version pinning and WAF"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2021-44*"
    actions:
      - type: auto_dismiss
        dismissal_reason: acceptable_risk

Kurzübersicht

Erste Schritte

So lassen sich Auto-Dismiss-Richtlinien einrichten:

1. Rauschen identifizieren: Den Vulnerability-Report öffnen und nach „Needs triage" sortieren. Nach Mustern suchen: Testdateien, eingebetteter Code, CVEs, die in mehreren Projekten wiederholt auftauchen.
2. Anwendungsfall auswählen: Mit dem Anwendungsfall beginnen, der die meisten Findings abdeckt.
3. Ausgangslage festhalten: Anzahl der Schwachstellen mit Status „Needs triage" vor Erstellung der Richtlinie notieren.
4. Erstellen und aktivieren: Über Secure > Policies > New policy > Vulnerability management policy navigieren. Konfiguration aus dem gewählten Anwendungsfall einfügen, dann MR mergen.
5. Ergebnis validieren: Nach der nächsten Pipeline des Standard-Branches den Report nach Status „Dismissed" filtern und prüfen, ob die erwarteten Findings erfasst wurden.

Vollständige Konfigurationsdetails in der Dokumentation zu Vulnerability-Management-Richtlinien.

GitLab Ultimate kostenlos testen und erste Auto-Dismiss-Richtlinie konfigurieren.

Die Funktionen bieten Teams konkrete Vorteile:

• Kein wiederholtes Einrichten von Filtern für häufige Arbeitsabläufe
• Konsistente Ansichten für die gemeinsame Bewertung von Arbeit im Team
• Einheitliche Grundlage für Berichte und Statusübersichten

Was sind Work Items?

Bisher befinden sich Epics und Issues auf getrennten Listenseiten, was das Navigieren zwischen ihnen erfordert. Die Work-Items-Liste fasst Epics, Issues und andere Work Items in einer einheitlichen Listenansicht zusammen und macht das Wechseln zwischen getrennten Seiten überflüssig.

Dies ist zugleich die Grundlage für tiefergehende Planungsfunktionen. Die Zusammenführung aller Work-Item-Typen schafft die Voraussetzung für Hierarchieansichten – zum Beispiel eine Tabellenansicht –, die Beziehungen und Strukturen über Epics, Issues und andere Elemente hinweg auf einen Blick sichtbar machen.

Über Listen- und Hierarchieansichten hinaus ist geplant, weitere häufige Arbeitsabläufe – etwa Boards – in diese einheitliche Erfahrung zu integrieren. Das Ziel: alle wesentlichen Planungsansichten an einem Ort, über gespeicherte Ansichten mit dem Team teilbar, ohne durch verschiedene Produktbereiche navigieren zu müssen.

Vielleicht fragst du dich, warum wir von „Work Items" sprechen und nicht von Issues. Die kurze Antwort: „Issue" skaliert nicht dorthin, wo wir hinwollen. Bald lassen sich Work-Item-Typen vollständig konfigurieren – einschließlich ihrer Bezeichnungen –, um die Planungshierarchie der eigenen Organisation abzubilden. An der bestehenden Terminologie festzuhalten würde diese Flexibilität entgegenwirken. „Work Items" ist die Grundlage für ein Modell, das sich individuell anpassen lässt.

Was hat zur Änderung geführt?

2024 haben wir unsere Vision für eine neue Agile-Planungserfahrung in GitLab vorgestellt, die auf dem Work-Items-Framework basiert. Darin beschrieben wir das zentrale Problem: Epics und Issues existierten als getrennte Erfahrungen und erzeugten Reibung für Teams, die konsistente Funktionalität über Planungsobjekte hinweg erwarteten. Das Work-Items-Framework war unsere Antwort darauf – eine einheitliche Architektur für Konsistenz und neue Möglichkeiten in GitLabs Planungswerkzeugen. Work-Items-Liste und gespeicherte Ansichten sind ein Schritt auf diesem Weg.

Was sind gespeicherte Ansichten?

Gespeicherte Ansichten ermöglichen es, benutzerdefinierte Listenkonfigurationen – einschließlich Filter, Sortierung und Anzeigeoptionen – zu speichern und später aufzurufen. Damit lassen sich wiederkehrende Prüfungen strukturierter durchführen und einheitliche Arbeitsweisen im Team etablieren.

Wie geht es weiter?

Um zu verstehen, warum wir diese Änderungen vornehmen, lohnt sich ein Blick auf das Ziel.

Das Ziel ist nicht nur eine Work-Items-Liste, sondern eine Planungserfahrung, die es erlaubt, zwischen verschiedenen Ansichtstypen – Liste, Board, Tabelle und mehr – zu wechseln und dabei den aktuellen Filterbereich beizubehalten.

In Kombination mit gespeicherten Ansichten lässt sich für jeden Arbeitsablauf eine eigene Ansicht anlegen: Iterationsplanung, Backlog-Pflege, Portfolio-Planung mit verschachtelten Tabellenansichten und mehr.

Jede Ansicht ist sofort einsatzbereit, filtert und zeigt Arbeit konsistent an und lässt sich mit dem Team teilen. Das Framework ermöglicht künftig weitere Funktionen, darunter vollständige Swimlane-Unterstützung für beliebige Work-Item-Attribute in Boards.

Wir wissen, dass Änderungen an täglich genutzten Werkzeugen störend sein können. Wer Arbeitsabläufe rund um die bestehenden Epic- und Issue-Listenseiten aufgebaut hat, wird Unterschiede bemerken. Das nehmen wir nicht auf die leichte Schulter.

Diese Richtung war keine schnelle Entscheidung. Sie spiegelt jahrelanges Feedback, eine erhebliche Investition in die Architektur des Work-Items-Frameworks und die Überzeugung wider, dass eine einheitliche Erfahrung Teams langfristig besser dient. Wir rechnen damit, dass die Umstellung Anpassungen erfordert, und werden auf Basis eures Feedbacks nachjustieren.

Teilt euer Feedback

Probiert die neuen Funktionen aus und teilt eure Erfahrungen mit der Work-Items-Liste und gespeicherten Ansichten in unserem Feedback-Issue. Eure Kommentare helfen dabei, diese Funktionen weiterzuentwickeln.

Das ist neu:

• Erkennung von False Positives bei statischen Anwendungssicherheitstests (SAST) ist jetzt allgemein verfügbar. Dieser Flow nutzt ein LLM für agentisches Reasoning, um die Wahrscheinlichkeit zu bestimmen, ob eine Schwachstelle ein False Positive ist oder nicht. So können sich Sicherheits- und Entwicklungsteams zuerst auf die Behebung kritischer Schwachstellen konzentrieren.
• Agentische SAST-Schwachstellenbehebung ist jetzt als Beta verfügbar. Die agentische SAST-Schwachstellenbehebung erstellt automatisch einen Merge Request mit einem Lösungsvorschlag für verifizierte SAST-Schwachstellen. Das verkürzt die Zeit bis zur Behebung und reduziert den Bedarf an tiefgreifender Sicherheitsexpertise.
• Erkennung von False Positives bei Geheimnissen ist jetzt als Beta verfügbar. Dieser Flow bringt die gleiche KI-basierte Rauschreduzierung in die Erkennung von Geheimnissen und kennzeichnet Dummy- und Test-Geheimnisse, um den Prüfaufwand zu verringern.

Diese Flows stehen Kund(inn)en von GitLab Ultimate zur Verfügung, die GitLab Duo Agent Platform nutzen.

Triage-Zeit mit SAST-False-Positive-Erkennung verkürzen

Herkömmliche SAST-Scanner kennzeichnen jedes verdächtige Codemuster, das sie finden – unabhängig davon, ob Codepfade erreichbar sind oder Frameworks das Risiko bereits abfangen. Ohne Laufzeitkontext können sie eine echte Schwachstelle nicht von sicherem Code unterscheiden, der lediglich gefährlich aussieht.

Das bedeutet, dass Entwickler(innen) möglicherweise Stunden damit verbringen, Ergebnisse zu untersuchen, die sich als False Positives herausstellen. Mit der Zeit kann das das Vertrauen in den Bericht untergraben und die Teams verlangsamen, die für die Behebung echter Risiken verantwortlich sind.

Nach jedem SAST-Scan analysiert GitLab Duo Agent Platform automatisch neue kritische und hochgradig schwerwiegende Ergebnisse und fügt Folgendes hinzu:

• Einen Konfidenzwert, der angibt, wie wahrscheinlich es ist, dass das Ergebnis ein False Positive ist
• Eine KI-generierte Erklärung mit der Begründung
• Ein visuelles Badge, das „Wahrscheinlich False Positive“ und „Wahrscheinlich echt“ in der UI leicht erkennbar macht

Diese Ergebnisse erscheinen im Sicherheitslückenbericht, wie unten dargestellt. Der Bericht lässt sich filtern, um sich auf Ergebnisse zu konzentrieren, die als „Kein False Positive“ markiert sind. So können Teams ihre Zeit für die Behebung echter Schwachstellen nutzen, anstatt Rauschen zu sichten.

Die Bewertung von GitLab Duo Agent Platform ist eine Empfehlung. Die Kontrolle über jedes False Positive bleibt erhalten, und die Begründung des Agenten kann jederzeit überprüft werden, um Vertrauen in das Modell aufzubauen.

Schwachstellen in automatisierte Fixes umwandeln

Zu wissen, dass eine Schwachstelle echt ist, ist nur die halbe Arbeit. Die Behebung erfordert weiterhin das Verständnis des Codepfads, das Schreiben eines sicheren Patches und die Sicherstellung, dass nichts anderes beeinträchtigt wird.

Wenn die Schwachstelle durch den SAST-False-Positive-Erkennungsflow als wahrscheinlich kein False Positive identifiziert wird, führt der agentische SAST-Schwachstellenbehebungsflow automatisch folgende Schritte aus:

1. Liest den anfälligen Code und den umgebenden Kontext aus dem Repository
2. Generiert hochwertige Lösungsvorschläge
3. Validiert die Fixes durch automatisierte Tests
4. Öffnet einen Merge Request mit einem Lösungsvorschlag, der Folgendes enthält:
   • Konkrete Codeänderungen
   • Einen Konfidenzwert
   • Eine Erklärung, was geändert wurde und warum

In dieser Demo siehst du, wie GitLab eine SAST-Schwachstelle automatisch vom Erkennen bis hin zu einem prüfbereiten Merge Request verarbeiten kann. Beobachte, wie der Agent den Code liest, einen Fix generiert und validiert und einen MR mit klaren, nachvollziehbaren Änderungen öffnet – damit Entwickler(innen) schneller beheben können, ohne Sicherheitsexpert(inn)en sein zu müssen.

Wie bei jedem KI-generierten Vorschlag sollte der vorgeschlagene Merge Request vor dem Zusammenführen sorgfältig geprüft werden.

Echte Geheimnisse identifizieren

Die Erkennung von Geheimnissen ist nur dann nützlich, wenn Teams den Ergebnissen vertrauen. Wenn Berichte voller Test-Zugangsdaten, Platzhalterwerte und Beispiel-Token sind, verschwenden Entwickler(innen) möglicherweise Zeit mit der Überprüfung von Rauschen, anstatt echte Sicherheitslücken zu beheben. Das kann die Behebung verlangsamen und das Vertrauen in den Scan verringern.

Die False-Positive-Erkennung bei Geheimnissen hilft Teams, sich auf die relevanten Geheimnisse zu konzentrieren und Risiken schneller zu reduzieren. Bei der Ausführung auf dem Standard-Branch werden automatisch folgende Schritte durchgeführt:

1. Jedes Ergebnis wird analysiert, um wahrscheinliche Test-Zugangsdaten, Beispielwerte und Dummy-Geheimnisse zu identifizieren
2. Ein Konfidenzwert wird zugewiesen, ob das Ergebnis ein echtes Risiko oder wahrscheinlich ein False Positive ist
3. Eine Erklärung wird generiert, warum das Geheimnis als echt oder als Rauschen eingestuft wird
4. Ein Badge wird im Sicherheitslückenbericht hinzugefügt, damit Entwickler(innen) den Status auf einen Blick erkennen können

Entwickler(innen) können diese Analyse auch manuell über den Sicherheitslückenbericht auslösen, indem sie bei einem Ergebnis der Geheimniserkennung „Auf False Positive prüfen“ auswählen. So lassen sich Ergebnisse ohne Risiko aussortieren und echte Geheimnisse schneller adressieren.

KI-basierte Sicherheit jetzt testen

GitLab 18.10 führt Funktionen ein, die den gesamten Schwachstellen-Workflow abdecken – von der Reduzierung von False-Positive-Rauschen bei SAST und der Erkennung von Geheimnissen bis hin zur automatischen Generierung von Merge Requests mit Lösungsvorschlägen.

Um zu erfahren, wie KI-basierte Sicherheit die Prüfzeit verkürzen und Ergebnisse in zusammenführbare Fixes umwandeln kann, starte jetzt eine kostenlose Testversion von GitLab Duo Agent Platform.