Dieser Artikel bietet einen umfassenden Einstieg in Kubernetes.

Was ist Kubernetes?

Kubernetes ist ein Open-Source-System zur effizienten Orchestrierung von Containern einer Softwareanwendung. Containerisierung ist ein weit verbreiteter Ansatz in der Anwendungsentwicklung – besonders im Bereich der digitalen Transformation und der Cloud.

Zur Erinnerung: Containerisierung ist eine Methode der Anwendungsentwicklung, bei der die Komponenten einer Anwendung in standardisierte, geräte- und betriebssystemunabhängige Einheiten – sogenannte Container – zusammengefasst werden. Durch die Isolierung von Anwendungen von ihrer Umgebung erleichtert diese Technologie die Bereitstellung und Portabilität und reduziert Kompatibilitätsprobleme.

Hier kommt Kubernetes ins Spiel. Container ermöglichen zwar die Aufteilung von Anwendungen in kleinere, eigenständige Module, die leichter bereitzustellen sind. Damit Container jedoch innerhalb einer Anwendung zusammenarbeiten können, ist ein übergeordnetes Verwaltungssystem erforderlich. Genau das leistet Kubernetes: Die Plattform steuert, wo und wie Container ausgeführt werden, und ermöglicht so die Orchestrierung und Planung containerisierter Anwendungen in großem Maßstab.

Weitere GitLab-Artikel zu Kubernetes.

Wie funktioniert eine Kubernetes-Architektur?

Um die Kubernetes-Architektur zu verstehen, sind einige grundlegende Konzepte wichtig – allen voran das des Clusters, der die umfassendste Einheit innerhalb der Architektur darstellt. Ein Kubernetes-Cluster ist die Gesamtheit der virtuellen oder physischen Maschinen, auf denen eine containerisierte Anwendung betrieben wird.

Quelle: Kubernetes.

Ein Cluster besteht aus verschiedenen Elementen:

• Node: Eine Arbeitseinheit im Kubernetes-Cluster – eine virtuelle oder physische Maschine, die Aufgaben im Auftrag der Anwendung übernimmt.
• Pod: Der kleinste bereitstellbare Baustein in Kubernetes. Ein Pod ist eine Gruppe von Containern, die gemeinsam auf demselben Node ausgeführt werden. Container innerhalb eines Pods teilen dasselbe Netzwerk und kommunizieren über localhost miteinander.
• Service: Ein Kubernetes-Service macht einen Pod für das Netzwerk oder andere Pods zugänglich und bietet einen stabilen, klar definierten Zugangspunkt zu den in Pods gehosteten Anwendungen.
• Volume: Eine Ordnerabstraktion, die Probleme beim Teilen und Abrufen von Dateien innerhalb eines Containers löst.
• Namespace: Ein Namespace ermöglicht die Gruppierung und Isolierung von Ressourcen zu einem virtuellen Cluster.

Die Kubernetes-Architektur basiert auf zwei Knotentypen: dem Master Node und den Worker Nodes. Der Master Node ist für die übergeordnete Verwaltung des Kubernetes-Clusters und die Kommunikation mit den Worker Nodes zuständig. Zu seinen zentralen Komponenten zählt die API als Kommunikationszentrum zwischen Nutzenden und Cluster. Das etcd ist die Key-Value-Datenbank, in der Konfigurationen, Systemzustand und Objekt-Metadaten gespeichert werden. Der Controller Manager koordiniert Hintergrundoperationen wie die Pod-Replikation, der Scheduler platziert Pods auf Nodes entsprechend der verfügbaren Ressourcen.

Worker Nodes hingegen sind die Maschinen, auf denen die in den Pods enthaltenen Anwendungen ausgeführt und verwaltet werden. Das kubelet ist der Agent, der auf jedem Node läuft und mit dem Master kommuniziert, um Befehle zu empfangen und den Status der Pods zu übermitteln. Der Netzwerk-Proxy kube-proxy pflegt die Netzwerkregeln auf den Nodes und ermöglicht so den Zugriff auf Services von außerhalb des Kubernetes-Clusters. Die Container-Runtime schließlich ist die Software, die für die Ausführung und Verwaltung der Container innerhalb der Pods verantwortlich ist.

Die Rolle von Docker

Bei allen Komponenten eines K8s-Clusters ist die Wahl der Runtime innerhalb der Worker Nodes von Bedeutung. Verschiedene Softwarelösungen stehen dafür zur Verfügung, etwa CRI-O – Docker ist jedoch das am häufigsten eingesetzte Werkzeug.

Was ist der Unterschied zwischen Docker und Kubernetes?

Docker ist eine Open-Source-Lösung, die speziell auf Container-Ebene eingesetzt wird. Sie ermöglicht die Paketierung von Containern in einem standardisierten und schlanken Format, was ihre Portabilität in verschiedenen Umgebungen erhöht. Docker ist damit ein ergänzendes Werkzeug zu K8s: Es vereinfacht die Verwaltung der Container selbst, während Kubernetes deren Integration und Kommunikation innerhalb der Anwendung erleichtert.

Welche Vorteile bietet Kubernetes?

Seit dem Start durch Google im Jahr 2014 und der ersten stabilen Version im Juli 2015 hat sich Kubernetes als Referenz im Bereich der Container-Orchestrierung etabliert – insbesondere für Microservice-orientierte Architekturen. Diese Verbreitung ist vor allem auf die Leistungsfähigkeit von K8s in der Container-Orchestrierung zurückzuführen.

Die Vorteile von Kubernetes im Überblick:

• Automatisierung: Kubernetes erleichtert die Automatisierung von Aufgaben rund um Bereitstellung, Skalierung und Aktualisierung containerisierter Anwendungen.
• Flexibilität: Die Software passt sich an unterschiedliche Container-Technologien sowie verschiedene Hardware-Architekturen und Betriebssysteme an.
• Skalierbarkeit: K8s ermöglicht die Bereitstellung und Verwaltung tausender Container – unabhängig von deren Status: laufend, pausiert oder gestoppt.
• Migration: Anwendungen lassen sich zu Kubernetes migrieren, ohne den Quellcode ändern zu müssen.
• Multi-Cluster-Unterstützung: Kubernetes verwaltet zentral mehrere Container-Cluster, die über verschiedene Infrastrukturen verteilt sind.
• Update-Management: Die Software unterstützt Rolling-Update-Deployments, um Anwendungen ohne Serviceunterbrechung zu aktualisieren.

Ein robustes und skalierbares Ökosystem

Kubernetes zeichnet sich durch die Fähigkeit aus, Container effizient und zuverlässig zu verwalten und dabei unabhängig von Cloud-Infrastrukturanbietern zu bleiben. Die modulare Architektur passt sich den spezifischen Anforderungen jedes Unternehmens an und unterstützt ein breites Spektrum an Anwendungen und Diensten – von Webservices über Datenverarbeitung bis hin zu mobilen Anwendungen.

Kubernetes profitiert dabei von einem umfangreichen und aktiven Open-Source-Ökosystem. Verwaltet von der Cloud Native Computing Foundation (CNCF), wird K8s von tausenden Entwicklerinnen und Entwicklern weltweit unterstützt, die kontinuierlich zur Weiterentwicklung des Projekts und seiner Funktionen beitragen.

Was sind die Grenzen von Kubernetes?

Die Stärken von Kubernetes machen es für viele Entwicklungsteams im Cloud-nativen Bereich zur soliden Grundlage. Dennoch lohnt es sich, einige Einschränkungen zu benennen. Kubernetes erfordert fundierte technische Kenntnisse sowie die Einarbeitung in neue Entwicklungskonzepte und -methoden. Die Konfiguration kann zu Beginn eines Projekts komplex sein – ist dabei aber entscheidend, insbesondere für die Absicherung der Plattform. Ein erfahrenes Entwicklungsteam mit K8s-Kenntnissen ist daher ein wesentlicher Vorteil.

Eine weitere Herausforderung ist die Implementierung und Wartung einer K8s-Architektur, die Zeit und Ressourcen erfordert – vor allem für die Aktualisierung der verschiedenen Komponenten und Softwareteile. Dabei stellt sich auch die Frage nach möglichem Oversizing: Bei kleineren Anwendungen oder Projekten ohne besondere Skalierungsanforderungen kann eine einfachere Architektur ausreichend und wirtschaftlicher sein.

Kubernetes im Unternehmenseinsatz

Zehntausende Unternehmen haben eine Kubernetes-Architektur für ihre digitale Transformation übernommen. K8s wird von Organisationen aller Größen genutzt – von Startups bis zu multinationalen Konzernen.

Ein Beispiel für eine erfolgreiche Integration ist Haven Technologies. Das Unternehmen hat seine SaaS-Dienste zu K8s migriert. Dabei setzt es auf eine Kubernetes-Strategie mit der GitLab-DevSecOps-Plattform – mit messbaren Verbesserungen bei Effizienz, Sicherheit und Entwicklungsgeschwindigkeit. Weitere Details in der Kundenreferenz.

Kubernetes, Git und GitLab

Kubernetes, Git und GitLab sind zentrale Bausteine der DevOps-Landschaft. Kubernetes bietet hohe Flexibilität bei der Bereitstellung und Verwaltung der verschiedenen Anwendungskomponenten. GitLab – aufgebaut auf Git und dessen nativer Versionskontrolle – ermöglicht eine präzise Nachverfolgung von Quellcode und Änderungen und stellt eine umfassende Werkzeugsammlung für den gesamten Software-Entwicklungslebenszyklus bereit.

Diese Kombination schafft gemeinsam mit einem GitOps-Ansatz, der die Automatisierung moderner Cloud-Infrastrukturen zum Ziel hat, eine agile Umgebung für Anwendungsentwicklung und -bereitstellung. Alle GitLab-Lösungen für den Einsatz mit Kubernetes im Überblick.

Kubernetes FAQ

Welche Alternativen zu K8s gibt es?

Es gibt verschiedene Alternativen zu Kubernetes, darunter Docker Swarm und Marathon. Kubernetes gilt jedoch als die ausgereifteste und am weitesten verbreitete Lösung auf dem Markt. Die große Nutzerbasis, umfangreiche Dokumentation und eine aktive Community machen K8s zur soliden Wahl für alle, die ein Container-Orchestrierungssystem einsetzen möchten.

Was ist ein Kubernetes-Cluster?

Ein Kubernetes-Cluster besteht aus einem Master Node und mehreren Worker Nodes. Der Master Node koordiniert die Aufgaben im Cluster, während die Worker Nodes diese Orchestrierungsaufgaben ausführen und die Container hosten. K8s-Cluster sind hoch skalierbar – Nodes lassen sich hinzufügen oder entfernen, um die Clusterressourcen an die Anforderungen der Anwendung anzupassen.

Wie startet man mit Kubernetes?

Zunächst ist die Installation der Kubernetes-Software in einer kompatiblen Umgebung (Linux, macOS oder Windows) erforderlich. Kubernetes lässt sich sowohl in einer klassischen Hosting-Umgebung als auch in der Cloud installieren – etwa auf Google Kubernetes Engine oder Amazon EKS. Nach dem Download und der Installation von der offiziellen Website folgt die Erstkonfiguration zur Verbindung von Master und Worker Nodes. Danach ist die erste Anwendung mit Kubernetes einsatzbereit.

Warum Kubernetes wählen?

Kubernetes bietet hohe Flexibilität und vollständige Portabilität zwischen verschiedenen Cloud-Plattformen oder On-Premises-Infrastrukturen. Durch die Automatisierung von Orchestrierungsaufgaben lassen sich Ressourcen optimieren und Betriebskosten senken. Das Kubernetes-Ökosystem ist umfangreich und wird von einer großen Open-Source-Community kontinuierlich weiterentwickelt.

Mehr erfahren

• Logs über das GitLab Dashboard für Kubernetes streamen
• Kubernetes-Überblick: Cluster-Daten im Frontend verwalten
• Cloud-Account-Management für Kubernetes-Zugriff vereinfachen

Wenn Sicherheit nur das Scannen von Code bedeutete, wäre die Antwort vielleicht ja. Aber Enterprise-Sicherheit war noch nie auf Erkennung allein ausgerichtet.

Unternehmen fragen nicht, ob KI Schwachstellen finden kann. Sie stellen drei weitaus schwieriger zu beantwortende Fragen:

• Ist das, was wir ausliefern wollen, sicher?
• Hat sich unsere Risikolage verändert, während sich Umgebungen, Abhängigkeiten, Drittanbieter-Services, Tools und Infrastruktur kontinuierlich wandeln?
• Wie lässt sich eine Codebasis steuern, die zunehmend von KI und Drittquellen zusammengestellt wird – für die wir aber weiterhin verantwortlich sind?

Diese Fragen erfordern eine Plattformantwort: Erkennung macht Risiken sichtbar, aber Governance bestimmt, was als nächstes passiert.

GitLab ist die Orchestrierungsschicht, die den Software-Lebenszyklus durchgängig steuert und Teams die Durchsetzung, Transparenz und Nachvollziehbarkeit gibt, die sie brauchen, um mit der Geschwindigkeit KI-gestützter Entwicklung Schritt zu halten.

KI vertrauen erfordert Governance

KI-Systeme werden zunehmend besser darin, Schwachstellen zu identifizieren und Korrekturen vorzuschlagen. Das ist ein bedeutender Fortschritt – aber Analyse ist keine Verantwortung.

KI kann Unternehmensrichtlinien nicht eigenständig durchsetzen oder akzeptables Risiko definieren. Menschen müssen die Grenzen, Richtlinien und Leitplanken festlegen, innerhalb derer Agenten operieren: Funktionstrennung sicherstellen, Audit-Trails gewährleisten und konsistente Kontrollen über Tausende von Repositories und Teams hinweg aufrechterhalten. Vertrauen in Agenten entsteht nicht durch Autonomie allein, sondern durch klar definierte Governance durch Menschen.

In einer agentischen Welt, in der Software zunehmend von autonomen Systemen geschrieben und verändert wird, wird Governance wichtiger, nicht unwichtiger. Je mehr Autonomie Unternehmen KI gewähren, desto stärker muss die Governance sein.

Governance ist keine Bremse. Sie ist das Fundament, das KI-gestützte Entwicklung im Unternehmensmaßstab vertrauenswürdig macht.

LLMs sehen Code, Plattformen sehen Kontext

Ein Large Language Model (LLM) bewertet Code isoliert. Eine Enterprise Application Security-Plattform versteht Kontext. Dieser Unterschied ist entscheidend, weil Risikoentscheidungen kontextabhängig sind:

• Wer hat die Änderung vorgenommen?
• Wie kritisch ist die Anwendung für das Unternehmen?
• Wie interagiert sie mit Infrastruktur und Abhängigkeiten?
• Liegt die Schwachstelle in Code, der tatsächlich in der Produktion erreichbar ist, oder in einer Abhängigkeit, die nie ausgeführt wird?
• Ist sie in der Produktion tatsächlich ausnutzbar – angesichts der Art, wie die Anwendung läuft, ihrer APIs und der sie umgebenden Umgebung?

Sicherheitsentscheidungen hängen von diesem Kontext ab. Fehlt er, produziert Erkennung laute Alarme, die die Entwicklung verlangsamen, anstatt Risiken zu reduzieren. Mit ihm können Unternehmen schnell priorisieren und Risiken gezielt managen. Da sich Kontext mit jeder Softwareänderung weiterentwickelt, kann Governance keine einmalige Entscheidung sein.

Statische Scans halten mit dynamischem Risiko nicht Schritt

Software-Risiko ist dynamisch. Abhängigkeiten ändern sich, Umgebungen entwickeln sich, und Systeme interagieren auf Weisen, die keine einzelne Analyse vollständig vorhersehen kann. Ein sauberer Scan zu einem Zeitpunkt garantiert keine Sicherheit beim Release.

Enterprise-Sicherheit setzt auf kontinuierliche Absicherung: Kontrollen, die direkt in Entwicklungs-Workflows eingebettet sind und Risiken bewerten, während Software entwickelt, getestet und bereitgestellt wird.

Erkennung liefert Erkenntnisse. Governance schafft Vertrauen. Kontinuierliche Governance ermöglicht es Unternehmen, im Unternehmensmaßstab sicher auszuliefern.

Die agentische Zukunft steuern

KI verändert, wie Software entsteht. Die Frage lautet nicht mehr, ob Teams KI einsetzen werden, sondern wie sicher sie dabei skalieren können.

Software wird heute ebenso zusammengestellt wie geschrieben – aus KI-generiertem Code, Open-Source-Bibliotheken und Drittanbieter-Abhängigkeiten, die sich über Tausende von Projekten erstrecken. Zu steuern, was über all diese Quellen hinweg ausgeliefert wird, ist der anspruchsvollste Teil der Anwendungssicherheit – und jener, für den kein entwicklerseitiges Tool ausgelegt ist.

Als intelligente Orchestrierungsplattform ist GitLab darauf ausgerichtet, dieses Problem zu lösen. GitLab Ultimate bettet Governance, Richtliniendurchsetzung, Security Scanning und Nachvollziehbarkeit direkt in die Workflows ein, in denen Software geplant, entwickelt und ausgeliefert wird – damit Security-Teams im Tempo von KI steuern können.

KI wird die Entwicklung erheblich beschleunigen. Den größten Nutzen werden nicht die Unternehmen ziehen, die die leistungsfähigsten KI-Assistenten einsetzen, sondern jene, die Vertrauen durch starke Governance aufbauen.

Wie GitLab Unternehmen dabei hilft, KI-generierten Code zu steuern und sicher auszuliefern: Jetzt mit unserem Team sprechen.

Weiterführende Beiträge

• KI und DevOps für verbesserte Sicherheit integrieren
• Das GitLab KI-Sicherheits-Framework für Security-Verantwortliche
• KI-Sicherheit in GitLab mit Composite Identities verbessern

Für deutsche Unternehmen: Governance als regulatorische Anforderung

Die in diesem Beitrag beschriebenen Governance-Prinzipien adressieren Anforderungen, die regulierte Unternehmen in Deutschland unmittelbar betreffen könnten.

Die NIS-2-Richtlinie (umgesetzt durch das NIS2UmsuCG) verpflichtet betroffene Unternehmen zu Maßnahmen im Bereich Risikoanalyse und Informationssicherheit (Artikel 21 Abs. 2 lit. a), Incident-Handling (Artikel 21 Abs. 2 lit. b) sowie zur Sicherheit in der Software-Lieferkette (Artikel 21 Abs. 2 lit. d) und bei der sicheren Entwicklung (Artikel 21 Abs. 2 lit. e). Die hier beschriebene Unterscheidung zwischen Erkennung und Governance spiegelt genau diese regulatorische Logik wider: Schwachstellen zu finden reicht nicht – entscheidend ist, wer die Reaktion darauf steuert, dokumentiert und verantwortet.

ISO 27001 adressiert ähnliche Anforderungen: Zugriffskontrolle (A.5.15–18), Logging und Monitoring (A.8.15–16), Schwachstellenmanagement (A.8.8) sowie Änderungsmanagement (A.8.32) setzen voraus, dass Governance-Prozesse in Entwicklungs-Workflows eingebettet sind – nicht nachgelagert.

Für Unternehmen in regulierten Branchen wie Finanzdienstleistungen (BaFin BAIT §6–7), Automotive (TISAX) oder kritischer Infrastruktur (BSI KRITIS) könnten diese Anforderungen besonders relevant sein. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.

Viele Unternehmen wissen, dass sie eine moderne DevSecOps-Plattform benötigen. Was ihnen oft fehlt, sind die Kapazitäten, eine solche Plattform bereitzustellen, zu betreiben und kontinuierlich zu optimieren – und gleichzeitig Software im Tempo der Geschäftsanforderungen zu liefern. Für MSPs ist das eine konkrete Chance, und GitLab stellt jetzt ein definiertes Programm zur Verfügung, um sie dabei zu unterstützen.

Vorgestellt wird das GitLab MSP Partner-Programm – ein neues globales Programm, das qualifizierten MSPs ermöglicht, GitLab als vollständig verwalteten Service für ihre Kunden bereitzustellen.

Was das für Partner und Kunden bedeutet

GitLab bietet erstmals ein formal definiertes, global verfügbares Programm, das speziell für MSPs entwickelt wurde. Das bedeutet klare Anforderungen, strukturierte Enablement-Maßnahmen, dedizierten Support und finanzielle Vorteile – damit Partner sicher in den Aufbau einer GitLab Managed Services-Praxis investieren können.

Der Zeitpunkt ist günstig. Unternehmen treiben ihre DevSecOps-Transformation voran, navigieren dabei jedoch oft komplexe Migrationen, fragmentierte Toolchains und wachsende Sicherheitsanforderungen – zusätzlich zu ihrer Kernaufgabe, Software zu entwickeln und auszuliefern.

GitLab MSP-Partner übernehmen den operativen Betrieb der Plattform, einschließlich Deployment, Migration, Administration und laufendem Support, damit sich Entwicklungsteams auf ihre eigentliche Arbeit konzentrieren können.

Was MSP-Partner erhalten

Finanzielle Vorteile: MSP-Partner erzielen GitLab Partner-Margen zuzüglich einer zusätzlichen MSP-Prämie auf alle Transaktionen, Neugeschäfte und Verlängerungen. 100 % der Servicegebühren für Deployment, Migration, Training, Enablement und strategische Beratung verbleiben beim Partner. Das ergibt mehrere wiederkehrende Einnahmequellen rund um eine einzige Plattform.

Enablement und Weiterbildung: Partner haben Zugang zu vierteljährlichen technischen Bootcamps, die Versions-Updates, neue Funktionen, Best Practices, laufende Roadmap-Updates und Peer-Sharing abdecken. Empfohlene Cloud-Zertifizierungen (AWS Solutions Architect Associate, GCP Associate Cloud Engineer) ergänzen die technische Grundlage.

Go-to-Market-Unterstützung: MSPs erhalten ein GitLab Certified MSP Partner-Badge, co-brandingfähige Assets, die Möglichkeit zur Teilnahme an gemeinsamen Kundenfallstudien, einen Eintrag im Partner Locator sowie Zugang zu Marketing Development Funds (MDF) für qualifizierte Demand-Generation-Aktivitäten.

Was Kunden erwarten können

Kunden, die mit einem GitLab MSP-Partner arbeiten, erhalten eine strukturierte, verwaltete DevSecOps-Erfahrung, dokumentierte und reproduzierbare Implementierungsmethoden, regelmäßige Business Reviews sowie Support mit klar definierten Reaktions- und Eskalationspfaden.

Das Ergebnis: Entwicklungsteams können sich auf die Softwareentwicklung konzentrieren, während der MSP-Partner den Betrieb und die Optimierung der Plattform verantwortet.

Neue Möglichkeiten rund um KI

Unternehmen suchen zunehmend nach Wegen, KI strukturiert in ihre Softwareentwicklungs-Workflows einzuführen. GitLab MSP-Partner sind gut positioniert, um Kunden im Rahmen eines umfassenderen Managed Services-Angebots durch die GitLab Duo Agent Platform zu begleiten.

Durch die Kombination der GitLab DevSecOps-Plattform mit der operativen Expertise von MSPs können Kunden KI-gestützte Workflows in einer kontrollierten Umgebung erproben, Anforderungen an Datenhaltung und Compliance erfüllen und die KI-Nutzung teamübergreifend skalieren.

Passt dieses Programm zum eigenen Geschäftsmodell?

Das GitLab MSP Partner-Programm ist gut geeignet, wenn:

• bereits Managed Services in den Bereichen Cloud, Infrastruktur oder Application Operations angeboten werden
• DevSecOps als hochwertiger Portfoliobaustein hinzugefügt werden soll
• technisches Know-how für moderne Entwicklungsplattformen vorhanden ist oder aufgebaut werden soll
• langfristige Kundenbeziehungen gegenüber Einzeltransaktionen bevorzugt werden

Für bestehende GitLab Select- und Professional Services-Partner bietet das MSP-Programm einen strukturierten Weg, vorhandene Expertise in ein reproduzierbares Managed-Services-Angebot zu überführen.

Erste Schritte

Das Programm startet mit der Bezeichnung Certified MSP Partner. Es gibt keine Mindest-ARR- oder Kundenanzahl-Anforderungen für den Beitritt. So sieht der Weg aus:

1. Eignung prüfen – Überprüfen, ob die geschäftlichen und technischen Anforderungen auf der Handbook-Seite erfüllt sind.
2. Über das GitLab Partner Portal bewerben – Bewerbung mit geschäftlicher und technischer Dokumentation einreichen.
3. 90-tägiges Onboarding absolvieren – Ein strukturierter Onboarding-Prozess umfasst Verträge, technisches Enablement, Vertriebstraining und das erste Kundenprojekt.
4. Managed-Services-Angebot aufbauen – Services paketieren, SLAs festlegen und erste Kunden gewinnen.

Vollständige Bewerbungen werden innerhalb von etwa drei Werktagen geprüft.

Interesse am Aufbau einer GitLab Managed Services-Praxis? Neue Partner können sich als GitLab Partner bewerben. Bestehende Partner wenden sich an ihren GitLab-Ansprechpartner, um mehr über das Programm zu erfahren.

Die GitLab Duo Agent Platform schließt diese Lücke: Externe KI-Modelle wie Anthropics Claude oder OpenAIs Codex lassen sich direkt in GitLab einbinden und als Agenten konfigurieren, die den Projektkontext kennen, Coding-Standards einhalten und komplexe Aufgaben eigenständig erledigen.

Cesar Saavedra, Developer Advocate bei GitLab, zeigt in seinem Video drei aufeinander aufbauende Anwendungsfälle – vom leeren Projekt bis zum Container-Image in der Registry.

Von der Idee zum Code

Ausgangspunkt ist ein leeres GitLab-Projekt mit einem Issue, das die Anforderungen an eine Java-Webanwendung beschreibt. Der externe Agent liest den Issue, analysiert die Spezifikationen und generiert eine vollständige Full-Stack-Anwendung: Backend-Java-Klassen, Frontend-Dateien (HTML/CSS/JavaScript) und Build-Konfiguration. Das Ergebnis landet als Merge Request mit vollständigem Code – bereit zur Überprüfung.

Code-Review durch denselben Agenten

Im zweiten Schritt übernimmt derselbe Agent die Code-Review des soeben erstellten Merge Requests. Per Erwähnung im MR-Kommentar liefert er eine strukturierte Analyse: Stärken, kritische Probleme, mittlere und kleinere Verbesserungspunkte, Security-Assessment, Testhinweise, Code-Metriken und einen Approval-Status. Senior-Entwicklungsteams werden von Routineprüfungen entlastet und können sich auf Architekturentscheidungen konzentrieren.

Pipeline und Container-Image auf Anfrage

Der generierte Code enthält noch keine CI/CD-Pipeline. Eine Anfrage im Merge Request genügt: Der Agent erstellt ein Dockerfile mit passenden Basis-Images für die im pom.xml definierte Java-Version, eine vollständige Pipeline mit Build-, Docker- und Deploy-Stages sowie das fertige Container-Image im integrierten GitLab Container Registry – ohne manuelle Konfiguration.

Mehr erfahren

Die vollständige Videodemonstration mit Screenshots aller Schritte ist im englischen Originalbeitrag verfügbar. Einen Einstieg in die GitLab Duo Agent Platform bietet außerdem der Getting Started Guide.

Um einen Passkey zu registrieren, in den Profileinstellungen Konto > Authentifizierung verwalten aufrufen.

Passkeys basieren auf WebAuthn-Technologie und Public-Key-Kryptographie, bestehend aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel verbleibt sicher auf dem Gerät und verlässt es nie, während der öffentliche Schlüssel bei GitLab gespeichert wird. Selbst bei einer Kompromittierung von GitLab können Angreifer die gespeicherten Zugangsdaten nicht nutzen, um auf das Konto zuzugreifen. Passkeys funktionieren in Desktop-Browsern (Chrome, Firefox, Safari, Edge), auf Mobilgeräten (iOS 16+, Android 9+) und mit FIDO2-Hardware-Sicherheitsschlüsseln. Mehrere Passkeys lassen sich geräteübergreifend registrieren.

GitLab hat das CISA Secure by Design Pledge unterzeichnet und sich damit verpflichtet, die eigene Sicherheitslage zu verbessern und Kunden bei der Entwicklung sicherer Software zu unterstützen. Ein zentrales Ziel des Pledges ist die verstärkte Nutzung von Multi-Faktor-Authentifizierung (MFA) in den eigenen Produkten. Passkeys sind ein wesentlicher Bestandteil dieses Ziels und bieten eine Phishing-resistente MFA-Methode, die die Anmeldung bei GitLab sicherer macht.

Bei Fragen, Erfahrungsberichten oder Verbesserungsvorschlägen steht das Feedback-Issue zur Verfügung.

Zwei neue GitLab-Funktionen, derzeit in der Beta, gehen dieses Problem aus unterschiedlichen Richtungen an – mit demselben Ziel: Praktikern direkte Kontrolle über die CI/CD-Infrastruktur zu geben, auf die sie angewiesen sind, ohne ein weiteres Drittanbieter-Tool einzuführen. Die eine Funktion liefert Job-Performance-Daten direkt dort, wo Pipelines überwacht werden. Die andere vereinfacht das Abrufen von Container-Images aus mehreren Registries mit integriertem Caching.

Beide Funktionen sind jetzt für Feedback offen. Rückmeldungen helfen dabei, die nächsten Entwicklungsschritte zu gestalten.

CI/CD Job Performance Metrics

• Verfügbare Tiers: GitLab Premium, GitLab Ultimate
• Status: Beta mit eingeschränkter Verfügbarkeit auf GitLab.com; verfügbar auf GitLab Self-Managed und GitLab Dedicated bei konfiguriertem ClickHouse

Bislang gibt es keine einfache Möglichkeit zu erkennen, wenn die Laufzeit eines bestimmten Jobs zunimmt oder welche Jobs die Pipeline-Laufzeiten im Hintergrund verlangsamen. Die meisten Teams erstellen entweder eigene Dashboards oder durchsuchen manuell Logs, um grundlegende Fragen zu beantworten:

• Welche Jobs sind am langsamsten?
• Wo steigen die Fehlerquoten?
• Welche Stage ist der eigentliche Engpass?

CI/CD Job Performance Metrics löst das durch ein neues job-fokussiertes Panel auf der CI/CD-Analytics-Seite auf Projektebene.

Für jeden Job in den Pipelines sind folgende Informationen einsehbar:

• Typische (P50, Median) und ungünstigste (P95) Job-Laufzeit für einen schnellen Vergleich zwischen normalem und langsamstem Lauf
• Fehlerquote zur Erkennung instabiler oder unzuverlässiger Jobs
• Job-Name und Stage, standardmäßig für die letzten 30 Tage

Die Tabelle ist sortierbar, nach Job-Name durchsuchbar und paginiert – Plattform-Teams erhalten so eine einheitliche Ansicht für Fragen, die bisher separate Tools oder eigene Berichte erforderten.

Jetzt ausprobieren

• Im Projekt Analysieren > CI/CD-Analyse aufrufen.
• Das CI/CD Job Performance Metrics-Panel suchen und nach Laufzeit oder Fehlerquote sortieren, um die langsamsten oder unzuverlässigsten Jobs zu finden.

Dokumentation

• CI/CD-Analyse – CI/CD Job Performance Metrics

Was als Nächstes kommt

Aktuell wird an einer Stage-Level-Gruppierung gearbeitet, mit der aggregierte Metriken über Build-, Test- und Deploy-Stages hinweg einsehbar sein werden – für ein schnelles Verständnis davon, wo Optimierungsbedarf besteht.

Feedback geben:

• CI/CD Job Performance Metrics Epic

Container Virtual Registry

Tier: GitLab Premium Status: Beta, API-ready in 18.9

Die meisten Unternehmen, die Container-Images in CI/CD-Pipelines abrufen, sind auf mehrere Registries angewiesen: Docker Hub, Harbor, Quay und interne Registries, um nur einige zu nennen. Authentifizierung, Verfügbarkeit und Caching für all diese Registries zu verwalten, ist operativer Aufwand, der Pipelines verlangsamt und Fehleranfälligkeit erhöht.

Die Container Virtual Registry ermöglicht die Erstellung eines einzigen GitLab-Endpunkts, der Images aus mehreren vorgelagerten Container-Quellen mit integriertem Caching abruft.

Statt Zugangsdaten und Verfügbarkeit für jede Registry einzeln in der Pipeline-Konfiguration einzurichten, lässt sich:

• Eine einzelne virtuelle GitLab-Registry als Endpunkt für alle Pipelines konfigurieren
• Mehrere vorgelagerte Registries einbinden (Docker Hub, Harbor, Quay und andere mit Long-Lived-Token-Authentifizierung)
• GitLab Image-Pulls automatisch auflösen lassen, mit Pull-Through-Caching zur Reduzierung von Bandbreitenkosten und verbesserter Zuverlässigkeit

Für Teams, die GitLab als Container-Registry-Ersatz evaluieren, schließt dies eine wesentliche Funktionslücke. Für Teams, die bereits Multi-Registry-Container-Workflows verwalten, zentralisiert es das Image-Management in GitLab und reduziert wiederholte Pulls.

Was die Beta heute unterstützt

• Vorgelagerte Registries mit Long-Lived-Token-Authentifizierung: Docker Hub, Harbor, Quay und andere kompatible Registries
• Pull-Through-Caching, sodass häufig verwendete Images nach dem ersten Abruf von GitLab bereitgestellt werden
• API-first-Konfiguration, UI-Verwaltung in Entwicklung

Cloud-Provider-Registries mit IAM-Authentifizierung (wie Amazon Elastic Container Registry, Google Artifact Registry und Azure Container Registry) werden für zukünftige Iterationen berücksichtigt.

Heute testen

• Die Container Virtual Registry ist in 18.9 API-ready.
• SaaS (GitLab.com): Zugang über den CSM anfragen oder im unten verlinkten Feedback-Issue kommentieren, um das Feature-Flag für die eigene Gruppe zu aktivieren.
• Self-managed: Feature-Flag aktivieren und die virtuelle Registry über die API konfigurieren.

Dokumentation

• Container Virtual Registry API
• Container-Images aus der virtuellen Registry abrufen

Walkthrough der Container Virtual Registry Beta:

Feedback geben:

• Feedback-Issue zur Container Virtual Registry

Mitgestalten

Alle in der GitLab-Community sind Mitwirkende. Diese Betas wurden auf Basis von Community-Anfragen entwickelt.

• CI/CD Job Performance Metrics entstand aus dem Bedarf von Teams, die keine einfache Möglichkeit hatten zu erkennen, wenn Build-Zeiten in die falsche Richtung tendierten oder welche Jobs die Pipeline-Zuverlässigkeit beeinträchtigten.
• Container Virtual Registry entstand aus Anfragen von Enterprise-Kunden, die mehrere Registries verwalteten und Tool-Sprawl sowie Bandbreitenkosten reduzieren wollten, während sie GitLab als zentrale Registry evaluierten.

Rückmeldungen gestalten, was als nächstes entwickelt wird. Eine oder beide Betas ausprobieren und Erfahrungen in den verlinkten Feedback-Issues teilen.

Dies ist der erste Beitrag in einer Reihe von Core-DevOps-Betas, die im Laufe des Jahres vorgestellt werden.

Der aktuell für die Metadaten-Signierung verwendete Schlüssel mit dem Fingerabdruck F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F läuft am 27. Feb. 2026 ab und wurde bis zum 6. Feb. 2028 verlängert.

Warum wird die Laufzeit verlängert?

Die Laufzeit des Repository-Metadaten-Signierungsschlüssels wird regelmäßig verlängert, um den GitLab-Sicherheitsrichtlinien zu entsprechen und das Risiko im Falle einer Kompromittierung des Schlüssels zu begrenzen. Statt einer Rotation auf einen neuen Schlüssel wird die Laufzeit verlängert, um den Aufwand für Nutzende zu minimieren – eine Rotation würde erfordern, dass alle Nutzenden ihren vertrauenswürdigen Schlüssel ersetzen.

Was ist zu tun?

Wer GitLab-Repositories bereits vor dem 17. Feb. 2026 auf dem eigenen System konfiguriert hat, findet in der offiziellen Dokumentation Hinweise dazu, wie der neue Schlüssel abgerufen und hinzugefügt werden kann. Für neue Nutzende ist keine weitere Aktion erforderlich – es genügt, der GitLab-Installationsseite oder der Installationsdokumentation für gitlab-runner zu folgen. Weitere Informationen zur Überprüfung der Repository-Metadaten-Signaturen sind in der Omnibus-Dokumentation verfügbar. Den öffentlichen Schlüssel lässt sich auf jedem GPG-Keyserver über die Suche nach support@gitlab.com oder die Schlüssel-ID F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F finden.

Alternativ kann der Schlüssel direkt von packages.gitlab.com unter folgender URL heruntergeladen werden: https://packages.gitlab.com/gpg.key.

Weitere Unterstützung benötigt?

Eine Issue im omnibus-gitlab Issue Tracker öffnen.

Unternehmen benötigen schnelle, sichere Software-Delivery, kämpfen jedoch häufig mit fragmentierten Toolchains, uneinheitlichen Sicherheitskontrollen und manuellen Compliance-Prozessen. KI-generierter Code und KI-gestützte Bedrohungen erhöhen die Komplexität zusätzlich.

Die GitLab- und TCS Center of Excellence (CoE)-Acceleratoren reduzieren gemeinsam Migrationsaufwände, kodifizieren Leitplanken und industrialisieren die DevSecOps-Einführung im Unternehmensmaßstab. Gemeinsam ermöglichen sie einen Weg von der Standardisierung zur Intelligent Orchestration – mit den notwendigen prüfbaren Leitplanken während der Entwicklung.

Für das zukunftsfähige Unternehmen

Unternehmen suchen eine DevSecOps-Plattform mit langfristiger Stabilität, die keine regelmäßige Neuarchitektur im großen Maßstab erfordert. GitLabs einheitliches Datenmodell verbindet den gesamten Software-Lebenszyklus zu einer einzigen Kontextquelle. Das ermöglicht Unternehmen, Pipelines, Kontrollen und Metriken im Unternehmensmaßstab zu standardisieren. GitLabs kontinuierliche Weiterentwicklung KI-gestützter Funktionen ist darauf ausgelegt, die Plattform auch bei der Einführung agentischer Workflows langfristig relevant zu halten.

GitLab und TCS synchronisieren Multi-Agent-Orchestrierung, dynamische Planung, konfidenzbasierte Entscheidungsfindung und kontinuierliche Lernzyklen, um Coding, Reviews, Tests, Security und CI/CD-Workflows zu automatisieren.

Die GitLab Duo Agent Platform stellt Intelligent Orchestration über den gesamten Software-Lebenszyklus bereit – durch kontextbewusste autonome Aktionen, mehrstufiges Reasoning, Code-Modernisierung, Security Scanning und Flow-Automatisierung, gesteuert durch GitLabs KI-native DevSecOps-Kontrollen. Dies ist kompatibel mit TCS' strukturierter Agent-Hierarchie für IT-Operationen: Reasoning-, Planungs- und Domain-Agenten rufen die spezialisierten Agenten der GitLab Duo Platform (z. B. Planner, Security Analyst, Code Review) über MCP-gesteuerte Integrationen und umfangreiche Projektkontextflüsse auf.

DevSecOps mit Platform Engineering skalieren

Platform Engineering verlagert den Fokus vom Management einzelner Pipelines und Toolchains hin zum Aufbau einer Internal Developer Platform (IDP), die standardisiert, wie Software entwickelt, abgesichert, getestet und bereitgestellt wird.

Unternehmen skalieren durch die Produktisierung der Developer Experience über Platform Engineering und den Betrieb von IDPs mit Self-Service Golden Paths. Sicherheit, Compliance und Governance sind standardmäßig durch Policy-as-Code eingebettet und standardisieren den Day-2-Betrieb. GitLab übernimmt die Rolle der IDP-Kontrollebene; TCS industrialisiert das Design und rollt Self-Service als Schicht auf der Kontrollebene aus. Als Solution Architects baut TCS Self-Service-Pfade, während die GitLab Duo Agent Platform Agentic AI hinzufügt, um die Entwicklung über den gesamten SDLC zu automatisieren.

Von DevSecOps zu Intelligent Orchestration

Eine einheitliche DevSecOps-Plattform bietet Unternehmen eine solide Grundlage. Wenn KI-Agenten jedoch zu aktiven Teilnehmern im Software-Lebenszyklus werden, muss die Plattform mehr leisten als Code und Pipelines verwalten: Sie muss die Zusammenarbeit von Menschen und KI-Agenten orchestrieren – mit vollständigem Lebenszykluskontext und integrierten Leitplanken. Das ist der Übergang von DevSecOps zu Intelligent Orchestration, den die GitLab Duo Agent Platform ermöglicht.

GitLab Duo Agent Platform

Die GitLab Duo Agent Platform integriert KI-Agenten in den Software-Entwicklungslebenszyklus, die Entwicklungsteams als Mitarbeiter unterstützen. Mehrere KI-Agenten bearbeiten Aufgaben parallel – von der Code-Generierung und Tests bis hin zu CI/CD-Korrekturen – und reduzieren dabei Engpässe. Entwicklungsteams steuern diese Agenten über definierte Regeln und behalten die Kontrolle, während Routineaufgaben delegiert werden. Diese Agent-Orchestrierung bewältigt komplexe Workflows (z. B. die automatische Behebung fehlerhafter Pipelines) und gibt Teams Kapazität für höherwertige Aufgaben frei.

KI-Agenten arbeiten innerhalb von GitLabs einheitlichem Datenmodell: Sie erstellen Merge Requests, verbessern Code und unterstützen Compliance-Anforderungen. Da jede Agentenaktion über vollständigen Projektkontext verfügt, prüfbar und richtlinienkonform ist, lässt sich KI über tausende von Entwicklungsteams hinweg skalieren – mit durchgehender Sicherheit und regulatorischer Compliance in allen automatisierten Workflows. Dies reduziert den operativen Aufwand für Application Engineers, DevSecOps Engineers, Scrum Master und Product Manager.

Referenzarchitektur

GitLab + TCS

GitLab stellt eine Intelligent Orchestration-Plattform für DevSecOps bereit, auf der Entwicklungsteams und KI-Agenten über den gesamten Entwicklungslebenszyklus hinweg zusammenarbeiten. TCS bringt industrialisierte Einführungs-Engines, erprobte Referenzarchitekturen, Migrations-Factories im Unternehmensmaßstab, Enterprise-Security-Baselines, Enterprise-KI-Kompetenz, AI Trust- und Risk-Management-Frameworks sowie einen produktorientierten Ansatz für den Plattformbetrieb ein.

TCS verfügt über umfangreiche Erfahrung aus der Arbeit mit Kunden unterschiedlichster Branchen, Regionen und regulatorischer Anforderungen. Diese Erfahrung ermöglicht es TCS, GitLab-Funktionen auf konkrete Enterprise-Rahmenbedingungen anzupassen – darunter gewachsene IT-Landschaften, Compliance-Anforderungen, Betriebsmodelle und Skalierungsherausforderungen – anstatt Tooling isoliert einzuführen. Gemeinsam ermöglichen GitLab und TCS eine schnelle, verlässliche Delivery im Unternehmensmaßstab über verschiedene Cloud-Umgebungen hinweg – mit integrierter Compliance.

Um mehr über GitLab + TCSzu erfahren, schicke uns eine Email an: ecosystem@gitlab.com

Behebung messen, nicht nur Erkennung

Application-Security-Teams haben selten Schwierigkeiten, Schwachstellen zu finden – die Herausforderung liegt im Einordnen. Die meisten Dashboards zeigen rohe Zählwerte ohne Kontext und zwingen Teams dazu, stundenlang Behebungsmaßnahmen nachzuverfolgen, ohne zu verstehen, welche Schwachstellen das größte Risiko darstellen.

Das GitLab Security Dashboard fasst alle Schwachstellendaten in einer Ansicht zusammen, die Projekte, Gruppen und Geschäftsbereiche übergreift.

In Version 18.6 wurde die erste Version des aktualisierten Security Dashboards eingeführt, mit der Teams Schwachstellen im Zeitverlauf anzeigen und nach Projekt oder Berichtstyp filtern können. Mit dem 18.9-Release stehen neue Filter und Diagramme zur Verfügung, die es erleichtern, Daten nach Schweregrad, Status, Scanner oder Projekt aufzuschlüsseln und Trends wie offene Schwachstellen, Behebungsgeschwindigkeit, Altersverteilung von Schwachstellen und Risiko-Score im Zeitverlauf zu visualisieren.

Risiko-Scores helfen dabei, die kritischsten Schwachstellen vorrangig zu beheben. Der Risiko-Score wird anhand von Faktoren wie dem Alter der Schwachstelle, dem Exploit Prediction Scoring System (EPSS) und Known Exploited Vulnerability (KEV)-Scores für die betreffenden Repositories und deren Sicherheitsstatus berechnet. Auf dieser Grundlage lassen sich die Bereiche identifizieren, die am dringendsten Aufmerksamkeit benötigen.

Das GitLab Security Dashboard unterstützt Application-Security- und Entwicklungsteams dabei:

• Programm-Effektivität verfolgen: Behebungsgeschwindigkeit, Scanner-Nutzung und Risikostatus überwachen, um messbare Verbesserungen nachzuweisen.
• Gezielte Behebung priorisieren: Schwachstellen beheben, die das größte Risiko für Produktionssysteme darstellen.
• Schulungsbedarf identifizieren: Teams erkennen, die bei der Behebung von Schwachstellen gemäß unternehmensinterner Richtlinien Schwierigkeiten haben, und gezielt in Weiterbildung investieren.
• Manuelles Reporting reduzieren: Externe Dashboards und Tabellen ersetzen, indem alles direkt in GitLab nachverfolgt wird.

Dieses Update unterstreicht GitLabs Ansatz, Sicherheit messbar, kontextbezogen und in die täglichen Entwicklungsabläufe integriert zu gestalten. Das GitLab Security Dashboard verwandelt rohe Befunde in handlungsrelevante Erkenntnisse und gibt Security- und Entwicklungsteams die Grundlage, um zu priorisieren, Risiken zu reduzieren und den Fortschritt zu belegen.

Das Security Dashboard in der Praxis

Eine Application-Security-Führungskraft, die ein Executive Briefing vorbereitet, kann nun anhand klarer Trendlinien zeigen, ob Investitionen die Risikolage verbessern: sinkende Anzahl offener Schwachstellen, abnehmendes Schwachstellenalter, rückläufige ehemals häufige CWE-Typen und ein stabiler Risiko-Score. Statt roher Zählwerte lässt sich demonstrieren, wie der Rückstand abgebaut wird und wie sich die Sicherheitslage Quartal für Quartal verbessert.

Gleichzeitig sehen Entwicklungsteams im selben Dashboard die kritischen Schwachstellen in ihren aktiven Projekten – und können Behebungsmaßnahmen priorisieren, ohne Daten zu exportieren oder zwischen mehreren Tools zu wechseln.

Weitere Informationen zum Einstieg in das GitLab Security Dashboard in der Dokumentation.

Mit GitLab 18.9 werden zwei Funktionen bereitgestellt, die eine strategische Lücke für diese Enterprise-Kunden schließen: Die GitLab Duo Agent Platform wird zur deployment-fähigen, steuerbaren KI-Kontrollschicht für streng regulierte Umgebungen.

GitLab Duo Agent Platform Self-Hosted für Online-Cloud-Lizenzen

Mit der GitLab Duo Agent Platform erstellen Entwicklungsteams KI-gestützte Abläufe, die Aufgabensequenzen automatisieren – vom Refactoring von Services und der Härtung von CI/CD-Pipelines bis zur Triage von Schwachstellen. Bislang war die Nutzung der Duo Agent Platform in der Produktion mit selbst gehosteten Modellen hauptsächlich auf Offline- oder Add-on-Lizenzpfade ausgerichtet und nicht für Online-Cloud-Lizenzkunden konzipiert, die unter strengen Regulierungsanforderungen arbeiten.

Ab sofort allgemein verfügbar: Self-Hosted für Online-Cloud-Lizenzen führt ein nutzungsbasiertes Abrechnungsmodell auf Basis von GitLab Credits ein. Dieses Modell bietet die transparente und planbare Verbrauchsmessung, die Unternehmen für interne Kostenzuordnung und Nachvollziehbarkeit benötigen.

• Datenhaltung und Kontrolle: Die Duo Agent Platform lässt sich nun in der Produktion mit Online-Cloud-Lizenzen betreiben – mit Modellen, die auf eigener Infrastruktur oder in genehmigten Cloud-Umgebungen gehostet werden. Damit bleibt die Kontrolle darüber, wo Modelle laufen und wie Inferenz-Traffic geroutet wird, vollständig im eigenen Einflussbereich.
• Kostentransparenz und interne Verrechnung: GitLab Credits und die Abrechnung pro Anfrage ermöglichen eine detaillierte Kostentransparenz – eine Voraussetzung für präzise interne Kostenverrechnung und regulatorische Berichtspflichten.
• Schnellere Einführung: Für Sektoren wie Finanzdienstleistungen, öffentliche Verwaltung und kritische Infrastruktur, in denen die Weitergabe von Daten an externe KI-Anbieter keine Option ist, entfällt damit ein wesentliches Einführungshindernis für Agentic AI. GitLab 18.9 macht die Duo Agent Platform zur vollwertigen Deployment-Option für Online-Cloud-Lizenzen.

Bring Your Own Model

Das Self-Hosting der Orchestrierungsschicht ist nur ein Teil der Lösung. Viele regulierte Kunden haben bereits erheblich in eigene Modelle investiert: domänenspezifisch trainierte LLMs, regional oder per Luftspalt betriebene Deployments für Datensouveränität sowie interne Closed-Source-Modelle, die auf das jeweilige Risikoprofil zugeschnitten sind.

Bring Your Own Model erweitert die Flexibilität der GitLab Duo Agent Platform: Administratoren können Drittanbieter- oder selbst gehostete Modelle über das GitLab AI Gateway einbinden und behalten damit die volle Modellauswahl und -kontrolle.

• Integration und Governance: BYOM-Modelle erscheinen neben GitLab-verwalteten Modellen innerhalb der KI-Kontrollschicht von GitLab – die Duo Agent Platform behandelt sie als vollwertige Enterprise-Optionen.
• Granulares Mapping: Nach der Registrierung über das AI Gateway lassen sich Modelle spezifischen Duo Agent Platform-Abläufen oder -Funktionen zuordnen, was eine feingranulare Steuerung darüber ermöglicht, welche Agenten und Abläufe welche Modelle verwenden. Administratoren tragen die Verantwortung für Modellvalidierung, Performance und Risikobewertung der eingebundenen Modelle.

Zusammen geben diese Funktionen Engineering-Verantwortlichen in Enterprise-Unternehmen umfassende Kontrolle über Agentic AI. Das Ergebnis ist eine einheitliche, verwaltete KI-Kontrollschicht – als Ersatz für den fragmentierten Mix aus Einzellösungen und unkontrollierten KI-Tools, auf den viele Engineering-Organisationen heute noch angewiesen sind. Modellfreiheit und starke Governance, innerhalb derselben DevSecOps-Plattform.

Die GitLab Duo Agent Platform ausprobieren? Jetzt Kontakt aufnehmen oder kostenlose Testversion starten.

Dieser Blogpost enthält zukunftsgerichtete Aussagen, die mit Risiken und Unsicherheiten verbunden sind. Tatsächliche Ergebnisse können wesentlich von den beschriebenen Erwartungen abweichen. Weitere Informationen zu Risikofaktoren finden sich in den Unterlagen von GitLab bei der US-Börsenaufsicht SEC.

Vertrauen durch Verbindlichkeit

Moderne Softwarebereitstellung arbeitet in einem Tempo, in dem Teams kontinuierlich Code pushen, Merge Requests öffnen und Issues verfolgen. Git-Operationen – Push, Pull, Clone – finden tausende Male pro Stunde über verteilte Teams hinweg statt. Wenn einer dieser zentralen Dienste nicht verfügbar ist, steht der gesamte Software-Delivery-Workflow still.

Das 99,9-%-Verfügbarkeits-SLA (Service-Level-Agreement) stellt sicher, dass ein hohes Entwicklungstempo nicht an Infrastruktur-Grenzen scheitert. Service Credits unterstreichen die Verantwortlichkeit – GitLabs Erfolg wird an die Plattformzuverlässigkeit gekoppelt. GitLab misst sich an den Geschäftsergebnissen der Kund(inn)en, nicht nur an Verfügbarkeitszielen.

Das SLA von GitLab deckt die zentralen Plattformdienste ab, die für DevSecOps-Workflows wesentlich sind.

Zum Start sind folgende Dienste abgedeckt:

* Issues und Merge Requests

* Git-Operationen (Push, Pull, Clone via HTTPS und SSH)

* Container-Registry-Operationen

* Package-Registry-Operationen

* API-Requests (beschränkt auf die oben genannten Dienste)

Die aktuelle Liste der abgedeckten und ausgeschlossenen Dienste ist im GitLab-Handbuch verfügbar.

Die Dienstverfügbarkeit wird durch automatisiertes Monitoring an mehreren geografischen Standorten gemessen und bildet die tatsächlich von Kund(inn)en erlebte Verfügbarkeit ab. Wenn die Verfügbarkeit unter 99,9 % fällt, können Kund(inn)en je nach Schwere des Ausfalls Credits beanspruchen.

Downtime Minutes verstehen

Wenn der GitLab-Dienst eine Verfügbarkeitseinschränkung von 5 % oder mehr der validen Kundenanfragen für abgedeckte Dienste innerhalb einer Minute aufweist und dies zu Server-Fehlern führt, wird dies als Downtime Minute bezeichnet. Server-Fehler sind definiert als HTTP-5xx-Statuscodes oder Verbindungs-Timeouts von mehr als 30 Sekunden, gemessen durch GitLabs interne und externe Monitoring-Systeme.

Das SLA erfasst serverseitige Fehler, aber bestimmte Probleme lösen keine 5xx-Fehler aus – beispielsweise Anwendungsfehler, die Features unbenutzbar machen, Sidekiq-Job-Processing-Ausfälle oder Infrastrukturprobleme, die die Performance beeinträchtigen, ohne dass Requests fehlschlagen.

So lassen sich Service Credits bei Bedarf beanspruchen:

1. Einen Support-Request auf support.gitlab.com innerhalb von dreißig (30) Tagen nach Ende des betroffenen Monats einreichen.
2. Das GitLab-Team prüft den Anspruch, validiert die Downtime und verarbeitet die Gutschrift, falls zutreffend.
3. Service Credits werden mit der nächsten Rechnung verrechnet.

Im Handbuch finden sich weitere Details zur Berechnung der monatlichen Verfügbarkeit, den angebotenen Service Credits und dem Anspruchsverfahren.

Das Monitoring ist darauf ausgelegt, die große Mehrheit der Dienstunterbrechungen zu erfassen. Falls die eigene Erfahrung nicht mit der gemeldeten Verfügbarkeit übereinstimmt, empfiehlt es sich, einen Service-Credit-Anspruch einzureichen. GitLab prüft den Anspruch ganzheitlich, einschließlich der Untersuchung von Problemen, die möglicherweise nicht im automatisierten Monitoring erfasst wurden.

Zuverlässigkeit mit Verbindlichkeit

Das 99,9-%-Verfügbarkeits-SLA mit Service Credits steht für GitLabs Anspruch, eine zuverlässige Grundlage für Software-Delivery-Workflows zu bieten. Teams verlassen sich auf GitLab – und GitLab steht dafür ein.

Fragen zum SLA? Das GitLab-Account-Team kontaktieren oder einen Request über GitLab Support einreichen.

Claude Opus 4.6 lässt sich neben anderen führenden Modellen in GitLab Duo Agent Platform auswählen und erweitert die agentische Entwicklungserfahrung um Frontier-Intelligenz für anspruchsvolle Aufgaben. Claude Opus 4.6 ist Anthropics bisher agentischstes Modell – es ergreift proaktiv Maßnahmen und treibt Aufgaben mit weniger manueller Steuerung voran als frühere Modelle, was es besonders für komplexe Entwicklungs-Workflows geeignet macht.

GitLab Duo Agent Platform + Claude Opus 4.6

Mit einem Kontextfenster von 1 Million Token (5-mal größer als bei Claude Opus 4.5) kann Opus 4.6 vollständige Codebases, umfangreiche Dokumentation und komplexe Projekthistorien in einer einzigen Interaktion verarbeiten – und GitLab Duo Agent Platform liefert reichhaltigen Kontext mit DevSecOps-Daten aus Repositories, Merge Requests, Pipelines und Security-Findings.

Durch die native Integration in die einheitliche GitLab-Plattform, Human-in-the-Loop-Kontrollen, Agent-Transparenz und gruppenbasierte Zugriffskontrollen lässt sich Claude Opus 4.6 auch für anspruchsvolle Workflows einsetzen. Das Ergebnis: KI mit Zugriff auf den vollständigen Projektkontext – Teams erzielen hochwertigere Ergebnisse, ohne den gewohnten GitLab-Workflow zu verlassen.

Einsatzbereiche für Claude Opus 4.6

Claude Opus 4.6 steht als Modelloption in GitLab Duo Agent Platform auf GitLab.com zur Verfügung für:

• Alle Agents
• Agentic Chat

Die erweiterten Fähigkeiten von Claude Opus 4.6 eignen sich für anspruchsvolle Entwicklungsaufgaben.

Hinweis: Claude Opus 4.6 ist nicht für GitLab Duo Classic Features verfügbar. Die Auswahl von Claude Opus 4.6 in unterstützten IDEs wird in Kürze möglich sein.

Zentrale Fähigkeiten:

• Hochgradig agentisch: Ergreift proaktiv Maßnahmen und treibt Aufgaben voran, startet Sub-Agents und parallelisiert Tool-Aufrufe für komplexe Workflows.
• Tiefes Reasoning: Profitiert von erweiterten Denkfähigkeiten für Test-Time Compute und durchdenkt komplexe Probleme gründlicher.
• Adaptives Denken: Kalibriert den Denkaufwand basierend auf der Komplexität der Anfrage – schnelle Antworten bei einfachen Aufgaben, erweitertes Denken bei anspruchsvollen Problemen.
• Multi-Agent-Orchestrierung: Erstellt proaktiv Sub-Agents und koordiniert parallele Arbeitsströme für komplexe, mehrstufige Aufgaben.
• Entwicklergesteuerte Workflows: Ermöglicht es, Arbeit an Sub-Agents zu delegieren, die parallele Arbeitsströme für komplexe, mehrstufige Aufgaben koordinieren – und so die Agent-Architektur von GitLab Duo Agent Platform optimal nutzen.
• Erweitertes Kontextfenster: Mit 1 Million Token Kontext (5-mal größer als Claude Opus 4.5) kann Claude Opus 4.6 vollständige Codebases, umfangreiche Dokumentation und komplexe Projekthistorien in einer einzigen Interaktion verarbeiten.

Credit-Verbrauch von Claude Opus 4.6

Claude Opus 4.6 nutzt GitLab Credits mit unterschiedlichen Multiplikatoren je nach Prompt-Größe:

• Prompts ≤200k Token: 1,2 Requests pro Credit
• Prompts >200k Token: 0,7 Requests pro Credit

Detaillierte Informationen zu Credit-Verbrauch und Multiplikatoren finden sich in der GitLab-Credits-Dokumentation.

Erste Schritte

GitLab Duo Agent Platform-Kunden können Claude Opus 4.6 ab sofort in der Modellauswahl nutzen. Die GitLab Duo Agent Platform-Dokumentation bietet weitere Informationen zu verfügbaren Agents, Workflows und Modellen.

Fragen oder Feedback? Erfahrungen gerne über die GitLab-Community teilen.

GitLab Duo Agent Platform testen? Jetzt kostenlose Testversion starten.

💡 Am 10. Februar hat GitLab auf der Transcend gezeigt, wie Agentic AI Software Delivery transformiert – mit Kunden-Einblicken und Impulsen zur Modernisierung. Mehr erfahren.

Was ist neu in 2025?

Die Verschiebung von 2021 (als die Liste zuletzt erschien) zu 2025 stellt mehr als kleine Anpassungen dar – es ist ein fundamentaler Wandel in der Applikationssicherheit. Zwei vollständig neue Kategorien wurden in die Liste aufgenommen und eine Kategorie in eine andere konsolidiert, was aufkommende Risiken hervorhebt, die traditionelle Tests oft übersehen.

Diese Ergänzungen und Verschiebungen sind in der folgenden Grafik zu sehen:

Zwei neue Kategorien

• A03: Software Supply Chain Failures: Erweitert die 2021-Kategorie „Vulnerable and Outdated Components" um die gesamte Software-Supply-Chain, einschließlich Dependencies, Build-Systeme und Distributions-Infrastruktur. Trotz der geringsten Vorkommen in Testdaten hat diese Kategorie die höchsten durchschnittlichen Exploit- und Impact-Scores aus CVEs.
• A10: Mishandling of Exceptional Conditions: Fokussiert auf fehlerhafte Error-Behandlung, logische Fehler und Failing-Open-Szenarien. Diese Kategorie adressiert, wie Systeme auf abnormale Bedingungen reagieren.

Wesentliche Ranking-Änderungen

• Security Misconfiguration stieg von #5 (2021) auf #2 (2025) und betrifft nun 3 % der getesteten Applikationen.
• Server-Side Request Forgery (SSRF) wurde in A01: Broken Access Control konsolidiert.
• Cryptographic Failures fielen von #2 auf #4.
• Injection fiel von #3 auf #5.
• Insecure Design verschob sich von #4 auf #6.

Warum diese Änderungen vorgenommen wurden

Die OWASP-Methodik kombiniert datengetriebene Analyse mit Community-Einblicken. Die 2025-Edition analysierte 589 Common Weakness Enumerations (CWEs) – eine substanzielle Steigerung gegenüber den etwa 400 CWEs in 2021. Diese Erweiterung reflektiert die wachsende Komplexität moderner Software-Systeme und die Notwendigkeit, aufkommende Bedrohungen zu erfassen.

Die Community-Survey-Komponente adressiert eine fundamentale Einschränkung: Testdaten schauen im Wesentlichen in die Vergangenheit. Bis Security-Forschende Testmethoden entwickeln und in automatisierte Tools integrieren, können Jahre vergangen sein. Die beiden community-voted Kategorien stellen sicher, dass aufkommende Risiken, die von Praktikern an vorderster Front identifiziert wurden, eingeschlossen werden – selbst wenn sie noch nicht in automatisierten Testdaten verbreitet sind.

Der Anstieg von Security Misconfiguration hebt einen Branchentrend zur konfigurationsbasierten Sicherheit hervor, während Software Supply Chain Failures den Anstieg ausgefeilter Angriffe auf kompromittierte Packages widerspiegelt.

GitLab Ultimate für Vulnerability-Detection und -Management nutzen

GitLab Ultimate bietet umfassendes Security-Scanning zur Erkennung von Risiken über alle OWASP-Top-10-2025-Kategorien hinweg. Die End-to-End-Plattform analysiert Quellcode, Dependencies und Infrastrukturdefinitionen von Projekten. Advanced Static Application Security Testing (SAST) erkennt Injection-Schwachstellen, Cryptographic Failures und unsichere Design-Patterns im Quellcode. Infrastructure as Code (IaC) Scanning findet Security-Fehlkonfigurationen in Deployment-Definitionen. Secret Detection verhindert das Leaken von Credentials, und Dependency Scanning deckt Bibliotheken mit bekannten Schwachstellen in der Software-Supply-Chain auf – und adressiert damit direkt die neue A03-Kategorie für Software Supply Chain Failures.

Darüber hinaus:

• Dynamic Application Security Testing (DAST) testet die deployten Applikationen auf Broken Access Control, Authentication Failures und Injection-Schwachstellen durch Simulation von Angriffsvektoren.
• API Security Testing prüft API-Endpoints auf Input-Validation-Schwächen und Authentication-Bypasses.
• Web API Fuzz Testing deckt auf, wie Applikationen mit Ausnahmebedingungen umgehen, indem unerwartete Inputs generiert werden – und adressiert damit direkt die neue A10-Kategorie für Mishandling of Exceptional Conditions.

Security-Scanning integriert sich nahtlos in die CI/CD-Pipeline und läuft beim Push von einem Feature-Branch, sodass Entwicklungsteams Schwachstellen beheben können, bevor sie Production erreichen. Security-Ergebnisse werden im Vulnerability Report konsolidiert, wo Security-Teams triagieren, analysieren und die Behebung nachverfolgen können. GitLab ermöglicht außerdem den Einsatz von KI-Agents wie dem Security Analyst Agent in der GitLab Duo Agent Platform, um die kritischsten Schwachstellen und die erforderlichen Maßnahmen schnell zu identifizieren.

Zusätzliche Kontrollen lassen sich über Merge-Request-Approval-Policies und Pipeline-Execution-Policies durchsetzen, um sicherzustellen, dass Security-Scanning konsistent in der gesamten Organisation ausgeführt wird. Customer-Success- und Professional-Services-Teams bei GitLab unterstützen dabei, den Wert einer GitLab-Investition zeitnah zu realisieren.

Sichere Software mit Security-Testing in derselben Plattform bereitstellen, die Entwicklungsteams bereits nutzen. Mehr dazu auf der Application Security Testing Solutions-Seite.

Die OWASP Top 10 2025: Vollständige Aufschlüsselung

A01: Broken Access Control

Was es ist

Fehler bei der Durchsetzung von Richtlinien, die verhindern, dass Nutzende außerhalb ihrer vorgesehenen Berechtigungen handeln – was zu unbefugtem Zugriff führt.

Auswirkungen auf das System

• Unbefugte Informationsoffenlegung
• Vollständige Datenzerstörung oder -modifikation
• Privilege Escalation (Nutzende erlangen Admin-Rechte)
• Einsehen oder Bearbeiten der Accounts anderer Nutzender
• API-Zugriff von nicht autorisierten oder nicht vertrauenswürdigen Quellen

Relevante CWEs

• CWE-22: Path Traversal
• CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
• CWE-352: Cross-Site Request Forgery (CSRF)

A02: Security Misconfiguration

Was es ist

Systeme, Applikationen oder Cloud-Services, die aus Security-Perspektive fehlerhaft konfiguriert sind.

Auswirkungen auf das System

• Offenlegung sensibler Informationen durch Fehlermeldungen
• Unbefugter Zugriff über Default-Accounts
• Unnötige Services oder Features aktiviert
• Veraltete Security-Patches
• Server sendet keine Security-Header oder -Direktiven

Relevante CWEs

• CWE-16: Configuration
• CWE-521: Weak Password Requirements
• CWE-798: Use of Hard-coded Credentials

A03: Software Supply Chain Failures

Was es ist

Ausfälle oder Kompromittierungen beim Erstellen, Verteilen oder Aktualisieren von Software – durch Schwachstellen oder böswillige Änderungen in Dependencies, Tools oder Build-Prozessen.

Auswirkungen auf das System

• Kompromittierte Packages, die Backdoors einschleusen
• Schädlicher Code, der während Build-Prozessen injiziert wird
• Verwundbare Dependencies, die sich durch die Applikation kaskadieren
• Nutzung von Komponenten aus nicht vertrauenswürdigen Quellen in Production
• Änderungen in der Supply Chain werden nicht nachverfolgt

Relevante CWEs

• CWE-1395: Dependency on Vulnerable Third-Party Component
• CWE-1104: Use of Unmaintained Third Party Components

A04: Cryptographic Failures

Was es ist

Fehler im Zusammenhang mit fehlender Kryptographie, unzureichend starker Kryptographie, Leaking von kryptographischen Schlüsseln und verwandten Fehlern.

Auswirkungen auf das System

• Offenlegung sensibler Daten (Passwörter, Kreditkarten, Gesundheitsdaten)
• Man-in-the-Middle-Angriffe
• Datenpanne durch schwache Verschlüsselung
• Schlüssel-Kompromittierung mit systemweiter Exposition
• Verstoß gegen regulatorische Compliance-Anforderungen (DSGVO, PCI DSS)

Relevante CWEs

• CWE-327: Use of a Broken or Risky Cryptographic Algorithm
• CWE-330: Use of Insufficiently Random Values

A05: Injection

Was es ist

Systemschwachstellen, die es Angreifenden ermöglichen, Schadcode oder -befehle (SQL, NoSQL, OS-Befehle, LDAP usw.) in Programme einzuschleusen.

Auswirkungen auf das System

• Datenverlust oder -korruption durch SQL-Injection
• Vollständige Datenbank-Kompromittierung
• Server-Übernahme durch Command-Injection
• Cross-Site-Scripting-(XSS)-Angriffe
• Informationsoffenlegung
• Denial of Service

Relevante CWEs

• CWE-89: SQL Injection
• CWE-78: OS Command Injection

A06: Insecure Design

Was es ist

Schwächen im Design, die verschiedene Fehler repräsentieren – ausgedrückt als fehlendes oder unwirksames Kontrolldesign. Architekturelle Mängel statt Implementierungs-Bugs.

Auswirkungen auf das System

• Schwache Passwort-Reset-Flows
• Fehlende Autorisierungsschritte
• Fehlerhafte Business-Logik, die Umgehungen ermöglicht
• Unzureichendes Threat Modeling, das blinde Flecken erzeugt
• Design-Patterns, die unter Angriffsszenarien versagen

Relevante CWEs

• CWE-209: Generation of Error Messages Containing Sensitive Information
• CWE-522: Insufficiently Protected Credentials
• CWE-656: Reliance on Security Through Obscurity

A07: Authentication Failures

Was es ist

Schwachstellen, die es Angreifenden ermöglichen, Systeme dazu zu bringen, ungültige oder fehlerhafte Identitäten als legitim zu erkennen.

Auswirkungen auf das System

• Account-Übernahme und Credential Stuffing
• Session Hijacking
• Erfolgreiche Brute-Force-Angriffe
• Ausnutzung schwacher Passwort-Recovery-Mechanismen
• Multi-Faktor-Authentifizierungs-Bypass

Relevante CWEs

• CWE-287: Improper Authentication
• CWE-306: Missing Authentication for Critical Function
• CWE-521: Weak Password Requirements

A08: Software or Data Integrity Failures

Was es ist

Code und Infrastruktur, die nicht verhindern, dass ungültiger oder nicht vertrauenswürdiger Code/Daten als vertrauenswürdig und valide behandelt werden.

Auswirkungen auf das System

• Unsignierte Updates, die Schadcode-Injection ermöglichen
• Insecure Deserialization, die zu Remote Code Execution führt
• CI/CD-Pipeline-Kompromittierung
• Ausnutzung von Auto-Update-Mechanismen
• Manipulierte Software-Artefakte

Relevante CWEs

• CWE-345: Insufficient Verification of Data Authenticity
• CWE-346: Origin Validation Error
• CWE-347: Improper Verification of Cryptographic Signature

A09: Security Logging & Alerting Failures

Was es ist

Unzureichendes Logging und Monitoring mit inadäquatem Alerting, was schnelle Reaktion erschwert.

Auswirkungen auf das System

• Angriffe bleiben über längere Zeiträume unentdeckt
• Breach-Investigation wird unmöglich
• Compliance-Verstöße durch fehlende Audit-Trails
• Verzögerte Incident-Response
• Unfähigkeit, das Ausmaß einer Kompromittierung zu bestimmen

Relevante CWEs

• CWE-117: Improper Output Neutralization for Logs
• CWE-532: Insertion of Sensitive Information into Log File
• CWE-778: Insufficient Logging

A10: Mishandling of Exceptional Conditions

Was es ist

Programme, die ungewöhnliche und unvorhersehbare Situationen nicht verhindern, erkennen und darauf reagieren – was zu Abstürzen, unerwartetem Verhalten oder Schwachstellen führt.

Auswirkungen auf das System

• Informationsoffenlegung durch zu detaillierte Fehlermeldungen
• Denial of Service durch unbehandelte Exceptions
• Zustandskorruption durch fehlerhafte Error-Behandlung
• Ausnutzung von Race Conditions
• Systeme, die bei Fehlern offen statt geschlossen schalten
• Applikationsabstürze, die sensible Daten exponieren

Relevante CWEs

• CWE-248: Uncaught Exception
• CWE-390: Detection of Error Condition Without Action
• CWE-391: Unchecked Error Condition

Best Practices für Prävention und Remediation

GitLab bietet Tools, die nicht nur das schnelle Finden und Beheben von Schwachstellen innerhalb der OWASP Top 10 ermöglichen, sondern auch deren Eintritt in das Production-System verhindern. Durch Befolgen dieser Best Practices lässt sich die Security-Posture verbessern und aufrechterhalten:

Automatisiertes Security-Scanning für alle Repositories

• SAST-Scanning durchführen, um unsichere Design-Patterns wie Klartext-Passwortspeicherung, inadäquates Error-Handling und fehlende Verschlüsselung während Code-Reviews zu erkennen – Design-Fehler werden früh im Entwicklungszyklus aufgefangen.
• Secret Detection durchführen, um Credentials in Konfigurationsdateien, Umgebungsvariablen und Code zu identifizieren – dies verhindert Klartext-Passwortspeicherung und stellt sicher, dass Secrets ordnungsgemäß über GitLab-CI/CD-Variablen mit Masking und Verschlüsselung verwaltet werden.
• DAST-Scanning durchführen, um Broken-Access-Control-Schwachstellen zu erkennen.
• Dependency Scanning durchführen, um Projekt-Dependencies gegen Schwachstellen-Datenbanken zu scannen und bekannte CVEs in direkten und transitiven Dependencies über mehrere Package-Manager (npm, pip, Maven usw.) zu identifizieren.
• Container Scanning durchführen, um Docker-Images auf verwundbare Base-Layer und Packages zu analysieren und die Container-Supply-Chain-Sicherheit vor dem Deployment sicherzustellen.
• IaC-Scanning durchführen, um Infrastruktur-Definitionsdateien auf bekannte Schwachstellen zu prüfen.
• API-Security-Tools nutzen, um Web-APIs vor unbefugtem Zugriff, Missbrauch und Angriffen zu schützen.
• Web API Fuzz Testing durchführen, um Bugs und potenzielle Schwachstellen zu entdecken, die andere QA-Prozesse übersehen könnten.

Die Security-Posture verstehen

• Eine Software Bill of Materials (SBOM) generieren für vollständige Dependency-Transparenz und Compliance-Anforderungen.
• Den Vulnerability Report nutzen, um Schwachstellen über eine konsolidierte Ansicht der im Codebase gefundenen Security-Vulnerabilities zu triagieren.
• Mit detaillierter Remediation-Anleitung und Risk-Assessment-Daten schnell auf Schwachstellen reagieren.
• Security Inventory nutzen, um zu visualisieren, welche Assets geschützt werden müssen und welche Maßnahmen zur Verbesserung der Sicherheit erforderlich sind.
• Compliance Center nutzen, um Compliance-Standards-Adherence-Reporting, Violations-Reporting und Compliance-Frameworks zu verwalten.

Prävention einrichten und Dokumentation pflegen

• Security Policies konfigurieren, um Merges oder Deployments zu blockieren, wenn hochgradig kritische Schwachstellen in Dependencies erkannt werden – Security-Standards werden automatisch durchgesetzt.
• Compliance Frameworks nutzen, um organisationsweite Security-Standards durch automatisierte Policy-Checks durchzusetzen, die Verschlüsselungsanforderungen, Credential-Management-Praktiken und sichere Workflow-Implementierungen verifizieren.
• GitLab Wiki und Repository-Dokumentation nutzen, um Security-Design-Prinzipien, genehmigte Patterns und Architectural Decision Records zu pflegen, die Entwicklungsteams zu Secure-by-Design-Implementierungen anleiten.
• Merge-Request-Approval-Rules implementieren, die ein Security-Architect-Review für Features erfordern, die Authentication, Authorization, Verschlüsselung oder sensible Datenverarbeitung betreffen – so wird Security-Validierung auf Design-Ebene sichergestellt.
• Tests erstellen, um Input-Validation und Allowlist-Ansätze für Dateipfade zu verifizieren.
• GitLab Issues und Epics nutzen, um Security-Anforderungen und Threat Models in der Design-Phase zu dokumentieren – dies schafft eine nachvollziehbare Aufzeichnung von Security-Entscheidungen und stellt sicher, dass Security-Überlegungen vor Implementierungsbeginn adressiert werden.

KI nutzen

• Code Suggestions für proaktive Guidance während der Entwicklung nutzen – mit Vorschlägen für sichere Design-Patterns wie korrektes Password-Hashing (bcrypt, Argon2), verschlüsselte Speichermechanismen und angemessenes Error-Handling, das keine sensiblen Informationen preisgibt.
• Security Analyst Agent nutzen, um erkannte Insecure-Design-Schwachstellen im Kontext zu bewerten – mit Erklärung der architekturellen Implikationen, Risikobewertung basierend auf dem Threat Model der Applikation und Remediation-Strategien, die grundlegende Design-Fehler statt nur Symptome adressieren.
• Code mit KI reviewen lassen, um konsistente Code-Review-Standards im Projekt sicherzustellen.

Kernaussagen für Entwicklungsteams

• Supply-Chain-Sicherheit ist entscheidend: Mit der Aufnahme von A03 und den hohen Impact-Scores ist die Absicherung der Software-Supply-Chain keine Option mehr. SBOM-Tracking, Dependency-Scanning und Integritätsprüfung sollten durchgängig in der Pipeline implementiert werden.
• Konfiguration ist wichtiger denn je: Der Aufstieg auf #2 zeigt, dass konfigurationsbasierte Sicherheit nun ein primärer Angriffsvektor ist. Konfigurationsverifizierung automatisieren und IaC mit integrierter Security implementieren.
• Traditionelle Bedrohungen bestehen fort: Obwohl Injection und Cryptographic Failures im Ranking gefallen sind, bleiben sie kritisch. Die Priorisierung nicht reduzieren, nur weil sie in der Liste gefallen sind.
• Error-Handling ist Security: Die neue A10-Kategorie unterstreicht, dass der Umgang der Applikation mit Fehlern ein Security-Thema ist. Sicheres Error-Handling von Beginn an implementieren.
• Testing muss sich weiterentwickeln: Die erweiterte CWE-Abdeckung (589 vs. 400 in 2021) bedeutet, dass Testing-Strategien umfassend sein müssen. SAST, DAST, Quellcode-Analyse und manuelles Penetration-Testing für effektive Abdeckung kombinieren.

Die GitLab Security and Governance Solutions und die Security-Scanning-Dokumentation bieten weitere Informationen zur Stärkung der Security-Posture.

Aus diesem Grund arbeitet GitLab mit Oracle Cloud Infrastructure (OCI) und Data Intensity, einem Oracle Managed Services Provider, zusammen, um eine neue Managed-Service-Option anzubieten: DevSecOps-as-a-Service. Der Dienst verbindet die Kontrolle von GitLab Self-Managed mit dem Betriebskomfort eines vollständig verwalteten Service.

Warum GitLab Self-Managed?

GitLab Self-Managed bietet die vollständige Kontrolle über die eigene DevSecOps-Plattform. Datenstandort, Instanzkonfiguration und Anpassungen an spezifische Compliance-, Sicherheits- oder Betriebsanforderungen lassen sich frei bestimmen. Dieses Maß an Kontrolle ist für Unternehmen mit strengen regulatorischen Anforderungen, Anforderungen an die Datenresidenz oder spezifischen Integrationsanforderungen relevant.

Gleichzeitig bedeutet der Betrieb von GitLab Self-Managed die Verwaltung von Servern, die Durchführung von Upgrades, die Sicherstellung der Hochverfügbarkeit und die Implementierung von Disaster Recovery – alles Aufgaben, die spezialisiertes Know-how und dedizierte Ressourcen erfordern.

Ein verwalteter Weg zu GitLab Self-Managed

DevSecOps-as-a-Service von Data Intensity auf OCI übernimmt diese betrieblichen Aufgaben, während die Kontrollvorteile von GitLab Self-Managed erhalten bleiben. Anstatt die Infrastruktur selbst aufzubauen und zu warten, steht eine eigenständige GitLab-Instanz bereit, die vom Data-Intensity-Team verwaltet wird und auf der Cloud-Infrastruktur von OCI läuft.

Der Service umfasst:

• Eigenständige GitLab-Instanz auf OCI-Infrastruktur
• 24/7-Monitoring, Alarmierung und Support
• Vierteljährliches Patching in festgelegten Wartungsfenstern
• Automatisierte Backups und Disaster-Recovery-Schutz

Skalierung mit dem Unternehmen

Der Managed Service von Data Intensity bietet abgestufte Architekturen, die sich an Benutzerkapazität und Recovery-Anforderungen anpassen lassen:

Weitere Informationen sind auf der Website von Data Intensity verfügbar: DevSecOps-as-a-Service.

Warum OCI für GitLab?

Oracle Cloud Infrastructure (OCI) bietet eine stabile Grundlage für den Betrieb von GitLab Self-Managed – mit einer sicheren, leistungsfähigen Umgebung zu geringeren Kosten als bei anderen Hyperscalern. Unternehmen, die Workloads zu OCI migrieren, berichten von Infrastrukturkostensenkungen von 40–50 %.

OCI unterstützt verschiedene Deployment-Modelle: von öffentlichen Cloud-Regionen über spezialisierte Umgebungen wie Government und EU Sovereign Clouds bis hin zu dedizierter Infrastruktur hinter der eigenen Firewall. Diese Optionen bieten einheitliches Pricing, Tooling und Betriebserfahrung, sodass sich GitLab-Deployments über regulierte, hybride und globale Umgebungen hinweg standardisieren lassen.

Die Kombination aus GitLabs DevSecOps-Plattform, OCI-Infrastruktur und dem Managed-Services-Know-how von Data Intensity ergibt eine Lösung, die es Teams ermöglicht, sich auf die Softwareentwicklung zu konzentrieren.

Passt dieser Service?

DevSecOps-as-a-Service von Data Intensity eignet sich für Unternehmen, die:

• GitLab Self-Managed nutzen, aber den Betriebsaufwand minimieren möchten
• Spezifische Compliance-, Sicherheits- oder Datenresidenz-Anforderungen erfüllen müssen
• Garantierte SLAs und professionelle Disaster-Recovery-Fähigkeiten benötigen
• Planbare Kosten und professionelles Management gegenüber dem Aufbau interner Infrastrukturexpertise bevorzugen
• OCI bereits nutzen oder den Einsatz planen
• Flexibilität und Kontrolle priorisieren
• Eine dedizierte, extern verwaltete Instanz mit Self-Managed-Kontrolle wünschen

Erste Schritte

Unternehmen, die GitLab Self-Managed auf OCI über DevSecOps-as-a-Service von Data Intensity betreiben möchten, können über die Data-Intensity-Website Kontakt aufnehmen, um spezifische Anforderungen zu besprechen und die Deployment-Planung zu starten.

Data Intensity bietet optional auch die Migration von Code-Repositorys und Anpassungen an, um einen reibungslosen Übergang zu OCI sicherzustellen.

GitLab baut das Partnerökosystem weiter aus. Lösungen wie diese unterstreichen das Ziel, Unternehmen die Wahl zu geben, wie sie GitLab einsetzen und verwalten – ob als SaaS, Self-Managed oder Managed Service über Partner.

Unterstützung für geometrisches Repacking mit Promisor Remotes

Neu geschriebene Objekte in einem Git-Repository werden oft als einzelne Loose Files gespeichert. Um gute Performance und optimale Nutzung des Speicherplatzes zu gewährleisten, werden diese Loose Objects regelmäßig in sogenannte Packfiles komprimiert. Die Anzahl der Packfiles in einem Repository wächst im Laufe der Zeit durch die Aktivitäten des Users, wie das Schreiben neuer Commits oder das Fetchen von einem Remote. Je mehr Packfiles sich in einem Repository befinden, desto mehr Arbeit hat Git beim Nachschlagen einzelner Objekte. Um die optimale Repository-Performance zu erhalten, werden Packfiles daher regelmäßig über git-repack(1) neu gepackt, um die Objekte in weniger Packfiles zu konsolidieren. Beim Repacking gibt es zwei Strategien: „All-into-One" und „Geometric".

Die All-into-One-Strategie ist relativ unkompliziert und derzeit der Standard. Wie der Name schon sagt, werden alle Objekte im Repository in ein einziges Packfile gepackt. Aus Performance-Sicht ist das großartig für das Repository, da Git nur ein einzelnes Packfile durchsuchen muss, um Objekte nachzuschlagen. Der Hauptnachteil dieser Repacking-Strategie ist, dass die Berechnung eines einzigen Packfiles für ein Repository bei großen Repositories erheblich viel Zeit in Anspruch nehmen kann.

Die Geometric-Strategie hilft, dieses Problem zu entschärfen, indem sie eine geometrische Progression von Packfiles basierend auf ihrer Größe beibehält, anstatt immer in ein einziges Packfile neu zu packen. Also: Beim Repacking pflegt Git eine Reihe von Packfiles, die nach Größe geordnet sind, wobei jedes Packfile in der Sequenz mindestens doppelt so groß sein soll wie das vorhergehende Packfile. Wenn ein Packfile in der Sequenz diese Eigenschaft verletzt, werden Packfiles bei Bedarf kombiniert, bis die Progression wiederhergestellt ist. Diese Strategie hat den Vorteil, dass sie die Anzahl der Packfiles in einem Repository minimiert und gleichzeitig den Arbeitsaufwand für die meisten Repacking-Operationen minimiert.

Ein Problem mit der geometrischen Repacking-Strategie war, dass sie nicht mit Partial Clones kompatibel war. Partial Clones ermöglichen es dir, nur Teile eines Repositorys zu klonen, indem du zum Beispiel alle Blobs größer als 1 Megabyte überspringst. Das kann die Größe eines Repositorys erheblich reduzieren, und Git weiß, wie es fehlende Objekte nachträglich abrufen kann, auf die es zu einem späteren Zeitpunkt zugreifen muss.

Das Ergebnis ist ein Repository, dem einige Objekte fehlen, und jedes Objekt, das möglicherweise nicht vollständig verbunden ist, wird in einem „Promisor"-Packfile gespeichert. Beim Repacking muss diese Promisor-Eigenschaft für Packfiles, die ein Promisor-Objekt enthalten, beibehalten werden, damit bekannt ist, ob ein fehlendes Objekt erwartet wird und vom Promisor Remote nachgeladen werden kann.

Bei einem All-into-One-Repack weiß Git, wie es Promisor-Objekte richtig behandelt und speichert sie in einem separaten Promisor-Packfile. Leider wusste die geometrische Repacking-Strategie nicht, Promisor-Packfiles eine Sonderbehandlung zu geben, und würde sie stattdessen mit normalen Packfiles zusammenführen, ohne zu berücksichtigen, ob sie auf Promisor-Objekte verweisen. Glücklicherweise schlägt aufgrund eines Bugs das zugrunde liegende git-pack-objects(1) fehl, wenn geometrisches Repacking in einem Partial-Clone-Repository verwendet wird. Das bedeutet, dass Repositories in dieser Konfiguration sowieso nicht neu gepackt werden konnten, was nicht großartig ist, aber besser als Repository-Korruption.

Mit dem Release von Git 2.53 funktioniert geometrisches Repacking jetzt mit Partial-Clone-Repositories. Bei einem geometrischen Repack werden Promisor-Packfiles separat behandelt, um die Promisor-Markierung zu erhalten, und nach einer separaten geometrischen Progression neu gepackt. Mit diesem Fix rückt die geometrische Strategie näher daran, die Standard-Repacking-Strategie zu werden. Für weitere Informationen schau dir den entsprechenden Mailing-List-Thread an.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

git-fast-import(1) hat gelernt, nur gültige Signaturen zu erhalten

In unserem Git 2.52 Release-Artikel haben wir signatur-bezogene Verbesserungen an git-fast-import(1) und git-fast-export(1) behandelt. Schau dir diesen Post unbedingt an für eine detailliertere Erklärung dieser Befehle, wie sie verwendet werden und welche Änderungen in Bezug auf Signaturen vorgenommen werden.

Um es kurz zusammenzufassen: git-fast-import(1) bietet ein Backend zum effizienten Importieren von Daten in ein Repository und wird von Tools wie git-filter-repo(1) verwendet, um die History eines Repositorys in großem Umfang neu zu schreiben. Im Git 2.52 Release hat git-fast-import(1) die Option --signed-commits=<mode> gelernt, ähnlich wie die gleiche Option in git-fast-export(1). Mit dieser Option wurde es möglich, Signaturen von Commits/Tags ohne Bedingung beizubehalten oder zu entfernen.

In Situationen, in denen nur ein Teil der Repository-History neu geschrieben wurde, wird jede Signatur für neu geschriebene Commits/Tags ungültig. Das bedeutet, dass git-fast-import(1) darauf beschränkt ist, entweder alle Signaturen zu entfernen oder alle Signaturen zu behalten, selbst wenn sie ungültig geworden sind. Aber ungültige Signaturen zu behalten, macht nicht viel Sinn, daher führt das Neuschreiben der History mit git-filter-repo(1) dazu, dass alle Signaturen entfernt werden, selbst wenn der zugrunde liegende Commit/Tag nicht neu geschrieben wurde. Das ist schade, denn wenn der Commit/Tag unverändert ist, ist seine Signatur noch gültig, und es gibt daher keinen wirklichen Grund, sie zu entfernen. Was wirklich benötigt wird, ist eine Möglichkeit, Signaturen für unveränderte Objekte zu erhalten, aber ungültige zu entfernen.

Mit dem Release von Git 2.53 hat die Option --signed-commits=<mode> von git-fast-import(1) einen neuen Modus strip-if-invalid gelernt, der, wenn angegeben, nur Signaturen von Commits entfernt, die durch das Neuschreiben ungültig werden. Mit dieser Option wird es also möglich, einige Commit-Signaturen bei der Verwendung von git-fast-import(1) zu erhalten. Das ist ein entscheidender Schritt zur Bereitstellung der Grundlage für Tools wie git-filter-repo(1), um gültige Signaturen zu erhalten und schließlich ungültige Signaturen neu zu signieren.

Dieses Projekt wurde von Christian Couder geleitet.

Mehr Daten in git-repo-structure gesammelt

Im Git 2.52 Release wurde der „structure"-Subcommand zu git-repo(1) eingeführt. Die Absicht dieses Befehls war es, Informationen über das Repository zu sammeln und schließlich ein nativer Ersatz für Tools wie git-sizer(1) zu werden. Bei GitLab hosten wir einige extrem große Repositories, und Einblicke in die allgemeine Struktur eines Repositorys sind entscheidend, um seine Performance-Charakteristiken zu verstehen. In diesem Release sammelt der Befehl jetzt auch Informationen zur Gesamtgröße von erreichbaren Objekten in einem Repository, um die Gesamtgröße des Repositorys zu verstehen. In der folgenden Ausgabe kannst du sehen, dass der Befehl jetzt sowohl die gesamten Inflated- als auch Disk-Größen von erreichbaren Objekten nach Objekttyp sammelt.

$ git repo structure

| Repository structure | Value      |
| -------------------- | ---------- |
| * References         |            |
|   * Count            |   1.78 k   |
|     * Branches       |      5     |
|     * Tags           |   1.03 k   |
|     * Remotes        |    749     |
|     * Others         |      0     |
|                      |            |
| * Reachable objects  |            |
|   * Count            | 421.37 k   |
|     * Commits        |  88.03 k   |
|     * Trees          | 169.95 k   |
|     * Blobs          | 162.40 k   |
|     * Tags           |    994     |
|   * Inflated size    |   7.61 GiB |
|     * Commits        |  60.95 MiB |
|     * Trees          |   2.44 GiB |
|     * Blobs          |   5.11 GiB |
|     * Tags           | 731.73 KiB |
|   * Disk size        | 301.50 MiB |
|     * Commits        |  33.57 MiB |
|     * Trees          |  77.92 MiB |
|     * Blobs          | 189.44 MiB |
|     * Tags           | 578.13 KiB |

Wer genau hinschaut, dem fällt vielleicht auch auf, dass die Größenwerte in der Tabellenausgabe jetzt auch benutzerfreundlicher mit angehängten Einheiten aufgelistet werden. In zukünftigen Releases hoffen wir, die Ausgabe dieses Befehls weiter zu erweitern, um zusätzliche Datenpunkte bereitzustellen, wie zum Beispiel die größten einzelnen Objekte im Repository.

Dieses Projekt wurde von Justin Tobler geleitet.

Mehr erfahren

Dieser Artikel hat nur einige der Beiträge von GitLab und der breiteren Git-Community für dieses neueste Release hervorgehoben. Du kannst mehr über diese aus der offiziellen Release-Ankündigung des Git-Projekts erfahren. Schau dir auch unsere früheren Git-Release-Blogposts an, um andere vergangene Highlights von Beiträgen der GitLab-Teammitglieder zu sehen.

GitLab hat zusammen mit The Harris Poll 251 deutsche DevSecOps-Profis aus verschiedenen Branchen zur Rolle von Künstlicher Intelligenz im IT-Bereich befragt. Die Ergebnisse der Studie zeigen, wie KI-Integration, Rollenveränderungen und neue Risiken die Arbeitswelt im DevSecOps-Umfeld in Deutschland prägen und welche Implikationen sich daraus für Unternehmen ergeben.

Den vollständigen Report zu KI im DevSecOps in Deutschland findest du hier.

Kennzahlen unserer Studie

Der aktuelle Stand von DevSecOps und Softwareentwicklung

• DevSecOps-Profis verbringen dennoch nur einen kleinen Teil ihrer Arbeitszeit mit neuer Softwareentwicklung: Im Schnitt entfallen lediglich 16 % auf das Schreiben von neuem Code, während Meetings und administrative Aufgaben mit 18 % den größten Anteil ausmachen. Weitere relevante Zeitfresser sind Security-Arbeit (13 %), die Verbesserung bestehenden Codes (12 %), Tests und Qualitätssicherung (12 %) sowie Codeverständnis und -pflege mit jeweils 10 %.
• Als wichtigsten Faktoren, die die Zusammenarbeit im SDLC einschränken, geben 32 % der Befragten organisatorische Silos und veraltete Dokumentationen an. Ein fehlender Wissensaustausch (30 %) und unklare/ineffiziente Prozesse bzw. Tool-Fragmentierung (jeweils 29 %) spielen ebenfalls eine große Rolle. Insgesamt gehen dadurch im Schnitt sieben Arbeitsstunden pro Woche verloren.
• Trotz moderner Entwicklungsansätze ist kontinuierliches Deployment noch nicht flächendeckend etabliert: Nur 27 % der Unternehmen deployen täglich oder mehrmals täglich. Gleichzeitig zeigen sich im Bereich Compliance-Anforderungen große strukturelle Bremsen, die für Verzögerungen bei 13 % der Releases verantwortlich sind.

Der Einsatz von KI im Software Development Lifecycle

• Künstliche Intelligenz ist bereits im Status quo der Softwareentwicklung angekommen. 68 % der Befragten verwenden KI bereits im Lebenszyklus der Softwareentwicklung, bei 17 % steht die Etablierung von KI im Jahr 2026 an.
• Dabei kommt KI derzeit bei 63 % der Befragten in der Dokumentation zum Einsatz. Aber auch für Tests (62 %) und die Programmierung selbst (60 %) wird sie bereits genutzt.
• 76 % der Befragten stimmen zu, dass die Integration von KI in den SDLC ihres Unternehmens schneller voranschreitet als zunächst angenommen.
• 98 % der DevSecOps-Profis berichten dabei, dass ihnen KI-Tools bereits Effizienzgewinne gebracht haben. Die größten Effekte entstehen durch die Automatisierung repetitiver Aufgaben (41 %), Unterstützung bei Tests und Qualitätssicherung (39 %), beim Erkennen von Bugs (38 %) sowie beim Erstellen von Code (36 %).
• Im Durchschnitt arbeiten die Befragten der Studie an einem Codebestand, der zu 32 % KI-generiert ist. 38 % des Codes werden noch immer von Grund auf neu geschrieben, während 30 % aus bestehenden externen Quellen wie Foren oder Suchergebnissen (ohne KI) kopiert werden.

Sicherheit, Compliance und Risiken im Zeitalter von KI

• In deutschen Unternehmen tragen vor allem Sicherheitsingenieur(innen) (38 %) und IT-Betriebsteams (33 %) die Hauptverantwortung für Application Security. Platform Engineers werden von 12 %, Entwickler(innen) selbst nur von 10 % der Befragten genannt.
• Zu den größten Sorgen im Zusammenhang mit KI- und agentischen Systemen zählen Security-Risiken (40 %), Qualitätskontrollen und die Einhaltung gesetzlicher Vorschriften (38 %), aber auch Datenschutz- und Datensicherheitsfragen (33 %).
• In Compliance-Aktivitäten investieren DevSecOps-Teams derzeit im Durchschnitt elf Stunden pro Monat und weitere zehn Stunden in die Behebung von Sicherheitsproblemen nach dem Release. Im Schnitt sind die Teams an acht Compliance-Audits pro Jahr beteiligt.
• Mit 76 % wird aktuell noch ein Großteil der Compliance-Anforderungen in der Softwareentwicklung manuell umgesetzt – 77 % erwarten aber, dass sich bis 2027 „Compliance as Code“ etabliert, bei dem Vorgaben automatisiert im Entwicklungsprozess verankert sind.

Der Blick nach vorn: DevSecOps, KI und Arbeit ab 2026

• DevSecOps-Profis stehen künstlicher Intelligenz trotz bewusster Risiken positiv gegenüber: 78 % der Befragten geben an, sich grundsätzlich zuversichtlich in Bezug auf den Ansatz ihres Unternehmens zur Anwendungssicherheit zu fühlen. Der gleiche Anteil meint allerdings auch, dass agentische KI „beispiellose Sicherheitsherausforderungen“ mit sich bringt.
• Zudem vertrauen DevSecOps-Teams darauf, dass KI etwa ein Drittel der täglichen Aufgaben ohne menschliche Überprüfung übernehmen kann. Am häufigsten gaben Befragte dafür Tätigkeiten wie die Dokumentation (53 %), das Schreiben von Tests (51 %) und Code-Reviews (49 %) an.
• Als Tätigkeiten, die dauerhaft in Menschenhand bleiben werden, gelten hingegen vorrangig Zusammenarbeit (43 %), Innovation (42 %) und strategisches Denken sowie Kommunikation (37 %). Daran anknüpfend erwarten 80 % der DevSecOps-Profis, dass KI ihre Rolle in den kommenden fünf Jahren erheblich verändern wird.

KI wird zum festen Bestandteil moderner Softwareentwicklung

Der Report macht deutlich, dass künstliche Intelligenz die Softwareentwicklung bereits heute messbar verändert und im DevSecOps-Alltag eingebunden ist. Unternehmen nutzen KI, um Effizienzverluste auszugleichen und Entwicklungsprozesse zu beschleunigen – gleichzeitig stoßen sie jedoch zunehmend auf neue Anforderungen in den Bereichen Sicherheit, Compliance und Governance.

Der Erfolg von KI ist dabei weniger von einzelnen Tools als von ihrer strategischen Einbettung abhängig. Rollen verschieben sich, menschliche Kontrolle bleibt in vielen Belangen aber zentral, und Platform Engineering entwickelt sich zur Voraussetzung für skalierbare KI-Nutzung.

Langfristig entscheidet also nicht der Einsatz von KI an sich über Wettbewerbsfähigkeit – denn sie ist längst etabliert. Vielmehr wird die Fähigkeit richtungsweisend, künstliche Intelligenz strukturiert und verantwortungsvoll in das eigene Unternehmen zu integrieren.

Lade den vollständigen Report zu KI im DevSecOps in Deutschland jetzt herunter.

Hinzu kommt, dass GitLab Duo Agent Platform sich von Duo Pro, Duo Enterprise und anderen KI-Entwicklertools auf dem Markt unterscheidet. Agenten und Agenten-Workflows können von deinem Team aufgerufen werden, wenn sie KI-Unterstützung benötigen, und durch SDLC-Events im Hintergrund ausgelöst werden. Mit Duo Agent Platform ist KI mit Agenten nicht mehr nur an Nutzer-Seats gebunden.

GitLab Credits löst diese Probleme als unsere neue virtuelle Währung für nutzungsbasierte Preise, beginnend mit GitLab Duo Agent Platform. Das bedeutet, dass jedes Mitglied deiner Organisation mit einem GitLab-Konto (Premium oder Ultimate) jetzt KI-Agenten-Fähigkeiten nutzen kann, ohne dass du für einen KI-Seat bezahlst – egal ob von ihnen aufgerufen oder als Hintergrund-Agenten eingerichtet.

Wie GitLab Credits funktionieren

GitLab Credits werden über deine gesamte Organisation gepoolt. Deine GitLab Duo Agent Platform-Nutzung wird von GitLab Credits abgezogen. Das umfasst sowohl synchrone als auch asynchrone Nutzung von Agenten und Agenten-Flows. Dazu gehören:

• Grundlegende Agenten wie Security Analyst, Planner und Data Analyst
• Grundlegende Flows wie Code Review, Developer und Fix CI/CD Pipeline
• Externe Agenten wie Anthropic Claude Code und OpenAI Codex
• Benutzerdefinierte Agenten und Flows, die du in deinem GitLab AI Catalog erstellst und veröffentlichst
• Agentic Chat in der GitLab-UI und in der IDE, die von deinen Entwicklungsteams genutzt wird

Hinweis: Externe Agenten können in 18.8 kostenlos getestet werden und verbrauchen keine GitLab Credits. Wir werden nächsten Monat mit unserem 18.9 Release Preise einführen. Benutzerdefinierte Flows befinden sich derzeit in der Beta-Phase und verbrauchen keine GitLab Credits.

Die Anzahl der abgezogenen Credits basiert auf der Anzahl der Agenten-Anfragen an große Sprachmodelle (weitere Details hier). Wenn weitere LLMs verfügbar werden, werden wir sie für die Nutzung mit GitLab Duo Agent Platform zertifizieren und zu dieser Liste hinzufügen, um Kunden einen transparenten Überblick über deren Verbrauch zu geben.

Die Gesamtzahl der GitLab Credits wird am Ende des Monats basierend auf der tatsächlichen Nutzung berechnet. Dieses Modell gleicht auch automatisch die Nutzung von Power-Usern mit der von leichteren Nutzern aus, wodurch deine Gesamtkosten für KI für jede Person effektiv gesenkt werden (im Vergleich zur Zahlung pro Seat für jede Person).

Der Einfachheit halber hat jeder GitLab Credit einen On-Demand-Listenpreis von $1. Du kannst GitLab Duo Agent Platform ohne Verpflichtungen nutzen und die Nutzung wird monatlich abgerechnet (am Ende jedes Monats). Für Unternehmenskunden, die sich für Jahresverpflichtungen anmelden, bieten wir Mengenrabatte für monatliche Credits.

Als zeitlich begrenzte Aktion* erhalten alle GitLab-Kunden mit aktiven Premium- und Ultimate-Abonnements automatisch $12 bzw. $24 an inkludierten Credits pro Nutzer(in). Diese Credits werden jeden Monat bis zum Ende des Aktionszeitraums erneuert und geben deinem Team kostenlos Zugang zu allen GitLab Duo Agent Platform Features. Wenn du unsere Abrechnungsbedingungen akzeptierst, wird jede Nutzung über diese inkludierten Credits hinaus über zugesagte monatliche Credits oder On-Demand-Credits abgerechnet.

Kostenkontrolle mit GitLab Credits

GitLab Credits dimensionieren: Dein Account-Team hat einen Dimensionierungsrechner als Teil der GA von GitLab Duo Agent Platform, um die Anzahl der GitLab Credits zu schätzen, die du jeden Monat benötigst. Dieser Rechner wurde mit Nutzungsmustern erstellt, die wir während der Beta-Phase beobachtet haben. Zusätzlich kannst du als Bestands- oder Neukunde eine kostenlose Testversion anfordern, um deine geschätzte tatsächliche Nutzung zu bestätigen.

Nutzungssichtbarkeit: Mit dem 18.8 Release hast du detaillierte Nutzungsinformationen über zwei sich ergänzende Dashboards – eines im GitLab Customers Portal für Abrechnungsmanager mit Fokus auf finanzielle Übersicht und eines im Produkt für Administrator(inn)en mit Fokus auf operative Überwachung. Beide bieten Zuordnung der Nutzung, Kostenaufschlüsselung und historische Trends, sodass du immer genau weißt, wie deine Credits verbraucht werden. Wenn du intern eine Querverrechnung praktizierst, kannst du Projekt- und Gruppenebenen-Rollups für Kostenzuordnungen verwenden.

Nutzungskontrollen: Du kannst den Zugriff auf GitLab Duo Agent Platform für bestimmte Teams oder Projekte aktivieren oder deaktivieren und sicherstellen, dass nur genehmigte Nutzung zu deinen Credits gezählt wird. Wir planen auch, kurz nach GA Kontrollen auf Nutzerebene hinzuzufügen, um dir zu helfen zu verwalten, wer GitLab Duo Agent Platform-Fähigkeiten nutzen und Credits verbrauchen kann.

Automatisierte Nutzungsbenachrichtigungen: Wir halten dich proaktiv über deine GitLab Credit-Nutzung per E-Mail-Benachrichtigungen auf dem Laufenden, wenn du 50 %, 80 % und 100 % deiner zugesagten monatlichen Credits erreichst, was dir Zeit gibt, die Nutzung anzupassen, zusätzliche Verpflichtungen zu kaufen oder für On-Demand-Abrechnung zu planen.

Upgrade von Seat-basierten GitLab Duo Pro/Enterprise zu GitLab Credits für Duo Agent Platform

Wenn du GitLab Duo Pro und Duo Enterprise gekauft hast und nutzt, kannst du diese Funktionen als unterstützte Optionen weiterhin verwenden. Du kannst jederzeit auf GitLab Duo Agent Platform upgraden und das tun, was du mit „klassischem" Duo kannst, und auf neue Funktionen wie Agentic Chat, zusätzliche grundlegende Agenten, benutzerdefinierte Agenten und Flows, externe Agenten und mehr zugreifen.

Zum Zeitpunkt des Upgrades übertragen wir deine Investition in Seats für GitLab Duo Pro und Duo Enterprise auf GitLab Credits für Duo Agent Platform. Der verbleibende Dollar-Betrag der Seat-Verpflichtungen wird gegen monatliche GitLab Credits mit volumenbasierten Rabatten getauscht. Die monatlichen GitLab Credits können dann von jedem Teammitglied in deiner Organisation geteilt werden, das du zulässt, nicht nur von den Nutzern, die vorher zugewiesene Duo Seats hatten.

Wettbewerbsvergleich: GitLab Credits vs. Seat-basierte Preise

Erste Schritte

1. Für bestehende Premium/Ultimate-Kunden: Mit GA wird GitLab Duo Agent Platform für Kunden mit aktiven Premium- und Ultimate-Lizenzen verfügbar sein**. GitLab.com SaaS-Kunden erhalten automatisch Zugriff. GitLab Self-Managed-Kunden erhalten Zugriff, wenn sie auf GitLab 18.8 Release upgraden (mit der geplanten allgemeinen Verfügbarkeit von Duo Agent Platform). GitLab Dedicated-Kunden werden während ihres geplanten Wartungsfensters im Februar auf GitLab 18.8 aktualisiert und können Duo Agent Platform ab diesem Zeitpunkt nutzen.
2. GitLab Duo aktivieren: Stelle sicher, dass GitLab Duo Agent Platform in deinen Namespace-Einstellungen aktiviert ist.
3. Mit der Erkundung beginnen: Nutze deine inkludierten monatlichen GitLab Credits, um GitLab Duo Agent Platform-Funktionen auszuprobieren.
4. Über inkludierte Credits hinausgehen: Du kannst dich für GitLab Credits für erweiterte Nutzung über inkludierte Credits hinaus zum On-Demand-Listenpreis anmelden. Für Mengenrabatte mit Verpflichtung kontaktiere uns, um ein Angebot für dein spezifisches Nutzungsniveau zu erhalten.

Besuche unsere GitLab Duo Agent Platform Dokumentation, um mehr über die ersten Schritte zu erfahren.

Hinweise

* Diese inkludierten Aktions-Credits sind für begrenzte Zeit bei GA verfügbar und können nach GitLabs Ermessen geändert werden.

** Ausgenommen sind GitLab Duo mit Amazon Q und GitLab Dedicated für Regierungskunden.

Um mehr über GitLab Duo Agent Platform zu erfahren und alle Möglichkeiten, wie KI-Agenten die Arbeitsweise deines Teams transformieren können, besuche unsere GitLab Duo Agent Platform Seite. Wenn du bestehender GitLab-Kunde bist, wende dich an deinen GitLab Account Manager oder Partner, um eine Live-Demonstration unserer Plattform-Funktionen zu vereinbaren.

GitLab Credits FAQ

1. Was sind GitLab Credits und warum hat GitLab sie eingeführt?

GitLab Credits ist eine neue virtuelle Währung für nutzungsbasierte GitLab-Funktionen, beginnend mit GitLab Duo Agent Platform. GitLab hat dieses Modell eingeführt, weil Seat-basierte Preise Organisationen zwangen, KI-Zugriff innerhalb von Engineering-Teams zu rationieren, und die Nutzung von Duo Agent Platform nicht nur an Seats gebunden ist. Credits werden über deine gesamte Organisation gepoolt, sodass du jedem Teammitglied Zugriff auf KI-Funktionen geben oder Hintergrund-Agenten-Workflows einrichten kannst, ohne individuelle Seat-Käufe im Voraus zu benötigen.

2. Wie funktioniert der Credit-Verbrauch?

Credits werden basierend auf der Anzahl der gestellten Agenten-Anfragen abgezogen, mit unterschiedlichen Raten je nachdem, welches LLM verwendet wird. Zum Beispiel erhältst du zwei Modell-Anfragen pro Credit für Claude-sonnet-4.5 (der Standard für die meisten Features) und 20 Anfragen pro Credit für Modelle wie gpt-5-mini oder claude-3-haiku.

3. Was ist für bestehende Premium- und Ultimate-Kunden enthalten?

Als zeitlich begrenzte Aktion erhalten Kunden mit aktiven Premium- und Ultimate-Abonnements automatisch inkludierte Credits kostenlos zusammen mit der GA-Veröffentlichung von Duo Agent Platform in GitLab 18.8:

• $12 an Credits pro Nutzer/in pro Monat für Premium * $24 an Credits pro Nutzer/in pro Monat für Ultimate

Inkludierte Credits sind auf Pro-Nutzer-Ebene, werden monatlich erneuert und ermöglichen Zugriff auf alle GitLab Duo Agent Platform Features ohne zusätzliche Kosten. Die Nutzung über diese inkludierten Credits hinaus wird separat abgerechnet. Diese inkludierten Aktions-Credits sind für begrenzte Zeit nach GA verfügbar und können nach GitLabs Ermessen geändert werden.

4. Wie kann ich den Credit-Verbrauch kontrollieren und überwachen?

GitLab bietet mehrere Governance-Tools: detaillierte Nutzungs-Dashboards sowohl im Customers Portal als auch im Produkt, die Möglichkeit, den Zugriff für bestimmte Teams oder Projekte zu aktivieren/deaktivieren, kommende Kontrollen auf Nutzerebene und automatisierte E-Mail-Benachrichtigungen bei 50%, 80% und 100% der zugesagten monatlichen Credits. Wir erwarten auch, einen Dimensionierungsrechner anzubieten, um deinen monatlichen Credit-Bedarf zu schätzen.

5. Wie beginne ich mit GitLab Duo Agent Platform?

Sobald GA, ist der Zugriff für bestehende Premium/Ultimate-Kunden automatisch auf GitLab.com SaaS. Self-Managed-Kunden erhalten Zugriff beim Upgrade auf GitLab 18.8 mit der geplanten allgemeinen Verfügbarkeit von Duo Agent Platform. Aktiviere einfach GitLab Duo Agent Platform in deinen Namespace-Einstellungen und beginne mit der Erkundung unter Verwendung deiner inkludierten monatlichen Credits. Für die Nutzung über inkludierte Credits hinaus kannst du dich für On-Demand-Abrechnung anmelden oder GitLab für Mengenrabatte mit jährlichen Verpflichtungen kontaktieren.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in diesen Aussagen widergespiegelten 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 oder Resultate wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren finden sich unter der Überschrift „Risikofaktoren" in unseren Einreichungen bei der SEC. Wir verpflichten uns nicht, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu überarbeiten, es sei denn, dies ist gesetzlich vorgeschrieben.

KI-Tools verbessern rapide die Fähigkeit von Entwicklungsteams, Code zu schreiben, und in einigen Fällen berichten Teams von 10-facher Produktivitätssteigerung. Leider verbringen Entwickelnde nur etwa 20 % ihrer Zeit mit dem Schreiben von Code, sodass die damit verbundene Verbesserung der gesamten Innovationsgeschwindigkeit und Lieferung durch KI nur inkrementell ist. Dies wird oft als KI-Paradoxon in der Softwarebereitstellung beschrieben.

Außerdem hat die erhöhte Geschwindigkeit beim Code-Schreiben für viele Teams zu neuen Engpässen geführt, darunter ein größerer Rückstand an Code-Reviews, Sicherheitslücken, Compliance-Prüfungen und nachgelagerten Fehlerbehebungen.

GitLab Duo Agent Platform löst das KI-Paradoxon durch intelligente Orchestrierung und KI-Automatisierung mit Agenten im gesamten Software-Lebenszyklus.

Erfahre mehr in diesem Video und lies unten weiter.

💡 Nimm am 10. Februar an GitLab Transcend teil und erfahre, wie KI mit Agenten die Softwarebereitstellung transformiert. Höre von Kunden und entdecke, wie du deine eigene Modernisierungsreise starten kannst. Jetzt registrieren.

Wir freuen uns außerdem bekannt zu geben, dass GitLab-Kunden mit aktiven GitLab Premium- und Ultimate-Abonnements ohne zusätzliche Kosten $12 bzw. $24 in GitLab Credits pro Nutzer(in) gutgeschrieben bekommen.* Diese Credits werden jeden Monat erneuert und geben Zugang zu allen GitLab Duo Agent Platform Features.

Hier ist eine einfache Erklärung, wie GitLab Credits funktionieren: Ein GitLab Credit ist eine virtuelle Währung für GitLabs nutzungsbasierte Produkte. Die Nutzung der GitLab Duo Agent Platform verbraucht verfügbare Credits, beginnend mit den oben genannten inkludierten Credits. Von dort aus können Kunden entscheiden, sich zu einem gemeinsamen Credit-Pool für ihre gesamte Organisation zu verpflichten oder sie monatlich nach Bedarf zu bezahlen. Für weitere Informationen lies unseren Artikel zur Einführung von GitLab Credits.

Kunden von GitLab Duo Pro oder Duo Enterprise Abonnements können diese Produkte weiterhin nutzen oder jederzeit zu Duo Agent Platform migrieren. Der verbleibende Wert deines Duo Enterprise Vertrags kann jederzeit in GitLab Credits umgewandelt werden. Kontaktiere deine GitLab-Ansprechperson, um mehr zu erfahren.

Hier sind spannende Anwendungsfälle und Funktionen, die du heute ausprobieren kannst:

Eine einheitliche Erfahrung für die Zusammenarbeit von Menschen und Agenten

GitLab Duo Agent Platform führt eine einheitliche Benutzererfahrung ein, die für nahtlose Integration zwischen Menschen und ihren KI-Agenten innerhalb von GitLab entwickelt wurde. Entwicklungsteams können Duo Agentic Chat auf fast jeder Seite nutzen, kontextbezogene Fragen stellen, asynchrone Agenten-Sessions verfolgen und mit Agenten innerhalb vertrauter Workflows wie Issues, Merge Requests und Pipeline-Aktivitäten interagieren – wodurch KI-Aktionen transparent und einfach durch alltägliche Arbeit zu steuern sind.

Agentic Chat: Intelligente, kontextbewusste Unterstützung

GitLab Duo Agentic Chat bringt echtes mehrstufiges Reasoning über die GitLab Web-UI und IDEs, unter Nutzung des vollständigen Lebenszyklus-Kontexts aus Issues, Merge Requests, Pipelines, Sicherheitsfunden und mehr. Aufbauend auf dem zuvor veröffentlichten Duo Chat kann Agentic Chat autonom Aktionen in deinem Namen ausführen und dir helfen, komplexe Fragen umfassender zu beantworten. Es gibt jedem Mitglied des Software-Teams genaue, kontextbewusste Anleitung, die hilft, Onboarding, Code-Qualität und Liefergeschwindigkeit zu verbessern.

GitLab Duo Agentic Chat unterstützt zahlreiche Anwendungsfälle, um die Zusammenarbeit zwischen Entwickelnden und KI zu ermöglichen. Für weitere Details zum Einstieg siehe unseren „Erste Schritte mit GitLab Duo Agent Platform" Leitfaden und schau dir diese wachsende Sammlung vorgeschlagener Prompts an.

• Analysieren In der Web-UI kann Agentic Chat Issues, Epics, Merge Requests erstellen und Zusammenfassungen bereitstellen, wichtige Erkenntnisse hervorheben und umsetzbare Anleitungen basierend auf Echtzeit-Kontext aus dem spezifischen Projekt, Issue, Epic, Merge Request und mehr bieten. Agentic Chat hilft Entwicklungsteams, unbekannten Code, Abhängigkeiten, Architektur und Projektstruktur zu verstehen, in der IDE oder innerhalb eines GitLab-Repos.
• Programmieren Agentic Chat kann Code, Konfigurationen und Infrastructure-as-Code über eine breite Palette von Sprachen und Frameworks generieren. Es kann helfen, Bugs zu beheben, Architektur und Code zu modernisieren, Tests zu generieren und Dokumentation für schnelleres Onboarding zu erstellen. Direkt zur Hand haben Entwickelnde Agentic Chat als Kollaborationspartner in VS Code, JetBrains IDEs, Cursor und Windsurf, mit optionalen Regeln auf Nutzer- und Workspace-Ebene zur Anpassung von Antworten.
• CI/CD Agentic Chat kann dir helfen, bestehende Pipelines besser zu verstehen, zu konfigurieren und Fehler zu beheben oder neue von Grund auf zu erstellen.
• Sichern Agentic Chat kann Schwachstellen erklären, Issues basierend auf Erreichbarkeit priorisieren und Fixes empfehlen, die dir Zeit sparen können.

Agenten: Spezialisten, die bei Bedarf zusammenarbeiten

GitLab Duo Agent Platform ermöglicht es Entwicklungsteams, Aufgaben an spezialisierte Agenten zu delegieren. Die Plattform bietet eine einzigartige Kombination aus grundlegenden, benutzerdefinierten und externen Agenten, die alle nahtlos in die GitLab-Benutzeroberfläche integriert sind, wodurch es einfach wird, den richtigen Agenten für jede Aufgabe zu wählen.

Grundlegende Agenten werden von GitLab-Expert(innen) vorgefertigt und sind sofort einsatzbereit, um die komplexesten Aufgaben im Software-Lieferzyklus zu bewältigen. Die folgenden grundlegenden Agenten sind als Teil der allgemeinen Verfügbarkeit von GitLab Duo Agent Platform enthalten, weitere befinden sich derzeit in der Beta-Phase und kommen bald.

• Planner Agent hilft Teams, Arbeit direkt in GitLab zu strukturieren, zu priorisieren und aufzuteilen, sodass die Planung klarer, schneller und einfacher umzusetzen wird.
• Security Analyst Agent überprüft Schwachstellen und Sicherheitssignale, erklärt ihre Auswirkungen in verständlicher Sprache und hilft Teams zu verstehen, was zuerst angegangen werden sollte.

Benutzerdefinierte Agenten können mit dem AI Catalog erstellt werden, einem zentralen Repository, in dem Teams benutzerdefinierte Agenten und Flows erstellen, veröffentlichen, verwalten und in der gesamten Organisation teilen können. Teams können Agenten und Flows mit spezifischem Kontext und Fähigkeiten erstellen, um die Arbeitsweise ihres Engineering-Teams zu replizieren – und Probleme mit den Engineering-Standards und Leitplanken lösen, die ihre Teams verwenden.

Externe Agenten sind nahtlos in GitLab integriert und umfassen einige der besten verfügbaren KI-Tools, darunter Claude Code von Anthropic und Codex CLI von OpenAI. Nutzer(innen) erhalten nativen GitLab-Zugang zu diesen Tools für Anwendungsfälle wie Code-Generierung, Code-Review und Analyse mit transparenter Sicherheit und eingebetteten LLM-Abonnements.

Zusammen geben diese Ansätze Teams Flexibilität bei der Einführung von KI mit Agenten, von spezialisierten Agenten über organisationsspezifische Automatisierung bis hin zur Integration externer KI-Tools – alles innerhalb einer einzigen, verwalteten Plattform.

Flows: Mehrstufige Arbeit in wiederholbaren, geführten Fortschritt verwandeln

Flows automatisieren komplexe Aufgaben mit mehreren Agenten-Workflows von Anfang bis Ende.

Unser Engineering-Team hat mehrere Flows erstellt, die bei GA enthalten sind, weitere sind unterwegs:

• Developer (Issue to Merge Request) Flow erstellt einen strukturierten MR aus einem gut definierten Issue, sodass Teams sofort mit der Arbeit beginnen können.
• Convert to GitLab CI/CD Flow hilft Teams, Pipeline-Konfigurationen ohne manuelles Umschreiben zu migrieren oder zu modernisieren.
• Fix CI/CD pipeline Flow analysiert Fehler, identifiziert wahrscheinliche Ursachen und bereitet empfohlene Änderungen vor.
• Code Review Flow analysiert Code-Änderungen, Merge Request Kommentare und mehr, um Code-Reviews mit KI-nativer Analyse und Feedback zu optimieren.
• Software development in IDE Flow führt durch alltägliche Entwicklungs- und Review-Phasen.

MCP Client: Verbinde GitLab Duo Agent Platform mit den Tools, die deine Teams bereits nutzen

Der MCP Client ermöglicht GitLab Duo Agent Platform in IDEs, sich sicher mit externen Systemen wie Jira, Slack, Confluence und anderen MCP-kompatiblen Tools zu verbinden, um Kontext einzuholen und Aktionen über deine DevSecOps-Toolchain hinweg auszuführen.

Anstatt dass KI-Unterstützung in einzelnen Tools isoliert ist, ermöglicht der MCP Client GitLab Duo Agent Platform, über die Systeme hinweg zu verstehen und zu arbeiten, in denen Planung, Zusammenarbeit und Ausführung tatsächlich stattfinden. Dies reduziert manuelles Kontextwechseln und ermöglicht vollständigere, durchgängige KI-gestützte Workflows, die widerspiegeln, wie Teams in der Praxis arbeiten.

Bei GA enthalten:

• Verbindung zu externen MCP-kompatiblen Systemen wie Jira, Confluence, Slack, Playwright und Grafana
• Konfiguration auf Workspace- und Nutzerebene
• Kontrollen auf Gruppenebene zur Aktivierung oder Einschränkung der MCP-Nutzung
• Nutzer-Genehmigungsflow für Tool-Zugriff
• Unterstützung über Agentic Chat in den IDE-Erweiterungen

Wir planen, weitere Features zur GitLab MCP Server-Funktion hinzuzufügen, die sich derzeit in der Beta-Phase befindet, und sie in kommenden Releases allgemein verfügbar zu machen.

Wähle das richtige Modell für dein Team und deine Workloads

GitLab Duo Agent Platform basiert auf einem flexiblen Modellauswahl-Framework, das es Teams ermöglicht, die Plattform an ihre Datenschutz-, Sicherheits- und Compliance-Anforderungen anzupassen. GitLab verwendet standardmäßig ein optimales LLM für jede Funktion, aber Administrator(inn)en haben die Möglichkeit, aus unterstützten Modellen wie OpenAI GPT-5 Varianten, Mistral, Meta Llama und Anthropic Claude zu wählen. Dies gibt Teams präzisere Kontrolle und Flexibilität darüber, was für Chat, Programmieraufgaben und Agenten-Interaktionen für jeden spezifischen Anwendungsfall verwendet wird, basierend auf den Standards deiner Organisation. Für eine vollständige Liste unterstützter Modelle und Details zur Modellauswahl-Konfiguration siehe den Abschnitt Model Selection unserer Dokumentation.

Governance, Sichtbarkeit und Deployment-Flexibilität

Die GitLab Duo Agent Platform gibt Organisationen die Kontrolle und Transparenz, die sie benötigen, um KI verantwortungsvoll einzuführen, während sie flexible Deployment-Optionen bietet, die in verschiedenen Umgebungen funktionieren.

Bei GA enthalten:

• Auf allen Plattformen verfügbar: GitLab.com, GitLab Self-Managed und GitLab Dedicated als Teil des GitLab 18.8 Release-Zyklus.
• Governance und Sichtbarkeit: Teams können sehen, wie Agenten genutzt werden, welche Aktionen sie ausführen und wie sie zur Arbeit beitragen. Nutzungs- und Aktivitätsdetails helfen Führungskräften, die Einführung zu verstehen, Auswirkungen zu messen und sicherzustellen, dass KI angemessen genutzt wird. Diese Kontrollen erleichtern die KI-Einführung im großen Maßstab mit Vertrauen.
• Gruppenbasierte Zugriffskontrollen: Administrator(inn)en können Namespace-basierte Regeln definieren, die steuern, welche Nutzer(innen) auf GitLab Duo Agent Platform Features zugreifen können, und unterstützen flexible Einführung von sofortiger organisationsweiter Aktivierung bis zu phasenweisen Rollouts. Mit LDAP- und SAML-Integration können sie Governance im großen Maßstab ohne manuelle Konfiguration ermöglichen.
• Modellauswahl und selbst-gehostete Optionen: LLM-Auswahl ist für alle GA-Features über GitLab.com, Self-Managed und Dedicated verfügbar. Top-Level-Namespace-Besitzer(innen) wählen das Modell, und Untergruppen erben diese Einstellungen automatisch. Für Organisationen, die mehr Kontrolle wünschen, unterstützt die Plattform selbst-gehostete Modelle für GitLab Self-Managed Deployments.

Sieh dir eine Demo von GitLab Duo Agent Platform in Aktion an:

Bleibe auf dem neuesten Stand mit GitLab

Um sicherzustellen, dass du die neuesten Features, Sicherheitsupdates und Leistungsverbesserungen erhältst, empfehlen wir, deine GitLab-Instanz auf dem neuesten Stand zu halten. Die folgenden Ressourcen können dir bei der Planung und Durchführung deines Upgrades helfen:

• Upgrade Path Tool – gib deine aktuelle Version ein und sieh die genauen Upgrade-Schritte für deine Instanz
• Upgrade Documentation – detaillierte Anleitungen für jede unterstützte Version, einschließlich Anforderungen, Schritt-für-Schritt-Anleitungen und Best Practices

Durch regelmäßige Upgrades stellst du sicher, dass dein Team von den neuesten GitLab-Funktionen profitiert und sicher und unterstützt bleibt.

Für Organisationen, die einen wartungsfreien Ansatz wünschen, solltest du GitLabs Managed Maintenance Service in Betracht ziehen. Managed Maintenance kann deinem Team helfen, sich auf Innovation zu konzentrieren, während GitLab-Expert(inn)en deine Self-Managed-Instanz zuverlässig aktualisiert, sicher und bereit halten, in DevSecOps zu führen. Frage deine Account-Manager(in) für weitere Informationen.

* GitLab-Kunden mit aktiven Premium- und Ultimate-Abonnements erhalten automatisch $12 bzw. $24 an inkludierten Credits pro Nutzer(in), die jeden Monat zurückgesetzt werden. Diese Credits sind für begrenzte Zeit verfügbar und können sich ändern (siehe Promo-Bedingungen).

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in diesen Aussagen widergespiegelten 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 oder Resultate wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren finden sich unter der Überschrift „Risikofaktoren" in unseren Einreichungen bei der SEC. Wir verpflichten uns nicht, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu überarbeiten, es sei denn, dies ist gesetzlich vorgeschrieben.

In diesem Artikel:

• Was sind Flows und wie funktionieren sie?
• Foundational Flows von GitLab
• Custom Flows erstellen
• Flow-Ausführung und Orchestrierung
• Real-World-Beispiele und Use Cases

🎯 Probiere GitLab Duo Agent Platform noch heute aus!

Einführung in Flows

Flows sind Kombinationen aus einem oder mehreren Agenten, die zusammenarbeiten. Sie orchestrieren mehrstufige Workflows, um komplexe Probleme zu lösen, und werden auf der GitLab-Plattform-Compute ausgeführt.

Hauptmerkmale von Flows:

• Multi-Agent-Orchestrierung: Kombiniere mehrere spezialisierte Agenten
• Built-in: Laufen auf Plattform-Compute, keine zusätzliche Umgebung erforderlich
• Event-gesteuert: Ausgelöst durch Mention, Assignment oder Assign as Reviewer
• Asynchron: Laufen im Hintergrund, während du weiterarbeitest
• Vollständige Workflows: Erledigen End-to-End-Aufgaben von Analyse bis Implementierung

Denke an Flows als autonome Workflows, die Kontext sammeln, Entscheidungen treffen, Änderungen ausführen und Ergebnisse liefern können, während du dich auf andere Arbeit konzentrierst.

Flows vs. Agents: Den Unterschied verstehen

Agenten arbeiten interaktiv mit dir. Flows arbeiten autonom für dich.

Flow-Typen im Überblick

Foundational Flows

Foundational Flows sind produktionsreife Workflows, die von GitLab erstellt und gewartet werden. Sie sind über dedizierte UI-Controls oder IDE-Interfaces zugänglich.

Aktuell verfügbare Foundational Flows

Custom Flows

Custom Flows sind YAML-definierte Workflows, die du für die spezifischen Anforderungen deines Teams erstellst. Sie laufen in GitLab Runner und können durch GitLab-Events ausgelöst werden.

🎯 Jetzt ausprobieren: Interaktive Demo von Custom Flows – Erkunde, wie du Custom Flows erstellen und konfigurieren kannst.

Warum Custom Flows erstellen?

Custom Flows automatisieren sich wiederholende mehrstufige Aufgaben, die spezifisch für den Workflow deines Teams sind. Anders als Foundational Flows, die allgemeinen Zwecken dienen, sind Custom Flows auf die Prozesse, Tools und Anforderungen deiner Organisation zugeschnitten.

Häufige Use Cases:

• Automatisierter Code Review: Mehrstufiger Review-Prozess (Security Scan → Quality Check → Style Validation)
• Compliance Checking: Überprüfe regulatorische Anforderungen, Lizenz-Compliance oder Sicherheitsrichtlinien bei jedem MR
• Dokumentationsgenerierung: Automatisches Update von API-Docs, README-Dateien oder Changelogs basierend auf Code-Änderungen
• Dependency Management: Wöchentliche Security-Scans, automatisierte Updates und Schwachstellenberichte
• Custom Testing: Spezialisierte Test-Suites für deinen Tech-Stack oder Integrationstests

Real-World-Beispiel

Ein Fintech-Unternehmen erstellt einen Compliance-Flow, der bei jedem Merge Request läuft. Wenn er durch @compliance-flow ausgelöst wird, führt der Flow folgende Schritte aus:

1. Security Agent scannt Code auf PCI-DSS-Verstöße und prüft auf exponierte sensible Daten.
2. Code Review Agent verifiziert, dass Änderungen sicheren Coding-Standards und Best Practices folgen.
3. Documentation Agent prüft, dass API-Änderungen aktualisierte Dokumentation enthalten.
4. Summary Agent aggregiert Findings und postet einen Compliance-Report mit Pass/Fail-Status.

Die gesamte Compliance-Überprüfung erfolgt automatisch in 5-10 Minuten und bietet konsistente Checks über alle Merge Requests hinweg.

Wie du Custom Flows auslöst

Custom Flows können auf mehrere Arten ausgelöst werden:

1. Via Mentions in Issues/MRs: Erwähne den Flow in einem Kommentar, um ihn auszulösen. Beispiel für einen Dokumentationsgenerierungs-Flow: text @doc-generator Generate API documentation for this feature

2. Durch Zuweisen des Flows zu einem Issue oder MR: Weise den Flow über eine der folgenden Methoden zu:

• GitLab UI: Klicke den „Assign"-Button auf dem Issue/MR und wähle den Flow
• Command: Verwende den /assign-Befehl in einem Kommentar. Beispiel: shell /assign @doc-generator

3. Durch Zuweisen des Flows als Reviewer: Weise den Flow als Reviewer auf einem Merge Request über eine der folgenden Methoden zu:

• GitLab UI: Klicke den „Assign reviewer"-Button auf dem Merge Request und wähle den Flow
• Command: Verwende den /assign_reviewer-Befehl in einem Kommentar. Beispiel: shell /assign_reviewer @doc-reviewer Jede dieser Methoden löst den Flow automatisch aus, um seine Aufgaben auszuführen.

Wie du Custom Flows erstellst

Custom Flows werden über die GitLab UI unter Automate → Flows → New flow in deinem Projekt oder über Explore → AI Catalog → Flows → New flow erstellt. Du definierst deinen Flow mithilfe einer YAML-Konfiguration, die Komponenten, Prompts, Routing und Ausführungsablauf spezifiziert. Das YAML-Schema ermöglicht es dir, ausgeklügelte Multi-Agent-Workflows mit präziser Kontrolle über Agentenverhalten und Orchestrierung zu erstellen.

Schlüsselelemente eines Custom Flows:

• Components: Definiere die Agenten und Schritte in deinem Workflow
• Prompts: Konfiguriere KI-Modellverhalten und Anweisungen
• Routers: Steuere den Flow zwischen Komponenten
• Toolsets: Spezifiziere, welche GitLab-API-Tools Agenten verwenden können

Beispiel Custom Flow YAML

Hintergrund: Dieses Beispiel zeigt einen Feature-Implementierungs-Flow für eine Reisebuchungsplattform. Wenn ein(e) Entwickler(in) ein Issue mit Feature-Anforderungen erstellt, kann dieser Flow ausgelöst werden, um automatisch die Anforderungen zu analysieren, die Codebasis zu überprüfen, die Lösung zu implementieren und einen Merge Request zu erstellen, alles ohne manuelle Intervention. Hier ist die YAML-Konfiguration:

version: "v1"
environment: ambient
components:
  - name: "implement_feature"
    type: AgentComponent
    prompt_id: "implementation_prompt"
    inputs:
      - from: "context:goal"
        as: "user_goal"
      - from: "context:project_id"
        as: "project_id"
    toolset:
      - "get_issue"
      - "get_repository_file"
      - "list_repository_tree"
      - "find_files"
      - "blob_search"
      - "create_file"
      - "create_commit"
      - "create_merge_request"
      - "create_issue_note"
    ui_log_events:
      - "on_agent_final_answer"
      - "on_tool_execution_success"
      - "on_tool_execution_failed"

prompts:
  - name: "Cheapflights Feature Implementation"
    prompt_id: "implementation_prompt"
    unit_primitives: []
    prompt_template:
      system: |
        You are an expert full-stack developer specializing in travel booking platforms, specifically Cheapflights.

        Your task is to:
        1. Extract the issue IID from the goal (look for "Issue IID: XX")
        2. Use get_issue with project_id={{project_id}} and issue_iid to retrieve issue details
        3. Analyze the requirements for the flight search feature
        4. Review the existing codebase using list_repository_tree, find_files, and get_repository_file
        5. Design and implement the solution following Cheapflights best practices
        6. Create all necessary code files using create_file (call multiple times for multiple files)
        7. Commit the changes using create_commit
        8. Create a merge request using create_merge_request
        9. Post a summary comment to the issue using create_issue_note with the MR link

        Cheapflights Domain Expertise:
        - Flight search and booking systems (Amadeus, Sabre, Skyscanner APIs)
        - Fare comparison and pricing strategies
        - Real-time availability and inventory management
        - Travel industry UX patterns
        - Performance optimization for high-traffic flight searches

        Code Standards:
        - Clean, maintainable code (TypeScript/JavaScript/Python/React)
        - Proper state management for React components
        - RESTful API endpoints with comprehensive error handling
        - Mobile-first responsive design
        - Proper timezone handling (use moment-timezone or date-fns-tz)
        - WCAG 2.1 accessibility compliance

        Flight-Specific Best Practices:
        - Accurate fare calculations (base fare + taxes + fees + surcharges)
        - Flight duration calculations across timezones
        - Search filter logic (price range, number of stops, airlines, departure/arrival times)
        - Sort algorithms (best value, fastest, cheapest)
        - Handle edge cases: date line crossing, daylight saving time, red-eye flights
        - Currency amounts use proper decimal handling (avoid floating point errors)
        - Dates use ISO 8601 format
        - Flight codes follow IATA standards (3-letter airport codes)

        Implementation Requirements:
        - No TODOs or placeholder comments
        - All functions must be fully implemented
        - Include proper TypeScript types or Python type hints
        - Add JSDoc/docstring comments for all functions
        - Comprehensive error handling and input validation
        - Basic unit tests for critical functions
        - Performance considerations for handling large result sets

        CRITICAL - Your final comment on the issue MUST include:
        - **Implementation Summary**: Brief description of what was implemented
        - **Files Created/Modified**: List of all files with descriptions
        - **Key Features**: Bullet points of main functionality
        - **Technical Approach**: Brief explanation of architecture/patterns used
        - **Testing Notes**: How to test the implementation
        - **Merge Request Link**: Direct link to the created MR (format: [View Merge Request](MR_URL))

        IMPORTANT TOOL USAGE:
        - Extract the issue IID from the goal first (e.g., "Issue IID: 12" means issue_iid=12)
        - Use get_issue with project_id={{project_id}} and issue_iid=<extracted_iid>
        - Create multiple files by calling create_file multiple times (once per file)
        - Use create_commit to commit all files together with a descriptive commit message
        - Use create_merge_request to create the MR and capture the MR URL from the response
        - Use create_issue_note with project_id={{project_id}}, noteable_id=<issue_iid>, and body=<your complete summary with MR link>
        - Make sure to include the MR link in the comment body so users can easily access it

      user: |
        Goal: {{user_goal}}
        Project ID: {{project_id}}

        Please complete the following steps:
        1. Extract the issue IID and retrieve full issue details
        2. Analyze the requirements thoroughly
        3. Review the existing codebase structure and patterns
        4. Implement the feature with production-ready code
        5. Create all necessary files (components, APIs, tests, documentation)
        6. Commit all changes with a clear commit message
        7. Create a merge request
        8. Post a detailed summary comment to the issue including the MR link

      placeholder: history
    params:
      timeout: 300

routers:
  - from: "implement_feature"
    to: "end"

flow:
  entry_point: "implement_feature"

Was dieser Flow macht: Dieser Flow orchestriert einen KI-Agenten, um automatisch ein Feature zu implementieren, indem er Issue-Anforderungen analysiert, die Codebasis überprüft, produktionsreifen Code mit Domain-Expertise schreibt und einen Merge Request mit einem detaillierten Summary-Kommentar erstellt.

Für vollständige Dokumentation und Beispiele siehe:

• Custom Flows Dokumentation
• Flow Registry Framework (YAML Schema)

Flow-Ausführung

Flows laufen auf GitLab-Plattform-Compute. Wenn sie durch ein Event (Mention, Assignment oder Button-Click) ausgelöst werden, wird eine Session erstellt und der Flow beginnt mit der Ausführung.

Verfügbare Umgebungsvariablen

Flows haben Zugriff auf Umgebungsvariablen, die Kontext über den Trigger und das GitLab-Objekt bereitstellen:

• AI_FLOW_CONTEXT – JSON-serialisierter Kontext inklusive MR-Diffs, Issue-Beschreibungen, Kommentaren und Discussion-Threads
• AI_FLOW_INPUT – Der Prompt- oder Kommentartext des Nutzers, der den Flow ausgelöst hat
• AI_FLOW_EVENT – Der Event-Typ, der den Flow ausgelöst hat (mention, assign, assign_reviewer)

Diese Variablen ermöglichen es deinem Flow zu verstehen, was ihn ausgelöst hat, und auf relevante GitLab-Daten zuzugreifen, um seine Aufgabe zu erfüllen.

Multi-Agent-Flows

Custom Flows können mehrere Agent-Komponenten enthalten, die sequenziell zusammenarbeiten. Die YAML-Konfiguration des Flows definiert:

• Components: Ein oder mehrere Agenten (AgentComponent) oder deterministische Schritte
• Routers: Definieren den Flow zwischen Komponenten (z.B. von Komponente A zu Komponente B zu Ende)
• Prompts: Konfigurieren das Verhalten und Modell jedes Agenten

Beispielsweise könnte ein Code-Review-Flow einen Security Agent, dann einen Quality Agent, dann einen Approval Agent haben, mit Routern, die sie sequenziell verbinden.

Flow-Ausführung überwachen

Um Flows anzuzeigen, die für dein Projekt laufen:

1. Navigiere zu Automate → Sessions.
2. Wähle eine beliebige Session aus, um mehr Details zu sehen.
3. Der Details-Tab zeigt einen Link zu den CI/CD-Job-Logs.

Sessions zeigen detaillierte Informationen inklusive Schritt-für-Schritt-Fortschritt, Tool-Aufrufe, Reasoning und Entscheidungsprozess.

Wann Flows verwenden

• Komplexe mehrstufige Aufgaben
• Hintergrund-Automatisierung
• Event-gesteuerte Workflows
• Multi-File-Änderungen
• Zeitaufwändige Aufgaben
• Automatisierte Reviews/Checks

Was kommt als Nächstes?

Du verstehst jetzt Flows, wie man sie erstellt und wann man sie im Vergleich zu Agenten verwendet. Als Nächstes lerne, wie du Agenten und Flows über deine Organisation hinweg entdecken, erstellen und teilen kannst in Teil 5: AI Catalog. Erkunde den AI Catalog, um verfügbare Flows und Agenten zu durchsuchen, sie zu deinen Projekten hinzuzufügen und deine eigenen Agenten und Flows zu veröffentlichen.

Ressourcen

• GitLab Duo Agent Platform Flows
• Foundational Flows Dokumentation
• Custom Flows Dokumentation
• Flow Execution Konfiguration
• GitLab CI/CD Variables Guide
• Service Accounts

Nächster: Teil 5: AI Catalog

Vorheriger: Teil 3: Agenten verstehen

In diesem Artikel:

• Was sind Agenten?
• Agententypen
• Häufige Use Cases
• Wie du einen Custom Agent erstellst
• Best Practices

🎯 Probiere GitLab Duo Agent Platform noch heute aus!

Was sind Agenten?

Agenten sind spezialisierte KI-Kollaborationspartner innerhalb der GitLab Duo Agent Platform. Jeder Agententyp dient verschiedenen Zwecken und läuft in unterschiedlichen Kontexten.

Agententypen

Foundational Agents

Von GitLab entwickelt und gewartet sind diese Agenten sofort verfügbar, ohne dass ein Setup erforderlich ist. Die Verfügbarkeit von Foundational Agents kann von Namespace-Eigentümer(innen) oder Instanz-Administratoren verwaltet werden. Starte die Interaktion mit Foundational Agents, indem du GitLab Duo Agentic Chat in der IDE oder Web-UI öffnest.

GitLab Duo

Dies ist der Standard-Agent, dein universeller Entwicklungs-Kollaborationspartner für das Erstellen und Ändern von Code, Öffnen von Merge Requests, Triaging und Aktualisieren von Issues/Epics sowie das Ausführen von Workflows mit vollständigem SDLC-Plattform-Kontext.

Beispiel-Prompts:

• "Erkläre, wie das Authentifizierungssystem funktioniert."
• "Wo befindet sich die Benutzerprofil-Logik?"
• "Wie sollte ich Feature X implementieren?"

Planner Agent

Hilft bei der Produktplanung, beim Aufteilen von Epics und beim Erstellen strukturierter Issues.

Beispiel-Prompts:

• "Erstelle ein Epic für das neue Payment-System mit Subtasks."
• "Teile Issue #789 in kleinere Tasks auf."
• "Generiere Akzeptanzkriterien für dieses Feature."

Mehr über Planner Agent erfahren.

Security Analyst Agent

Triaged Schwachstellen, identifiziert False Positives und priorisiert Sicherheitsrisiken.

Beispiel-Prompts:

• "Triage alle Schwachstellen aus dem letzten Scan."
• "Welche SAST-Findings sind False Positives?"
• "Priorisiere Security-Issues nach tatsächlichem Risiko."

Mehr über Security Analyst Agent erfahren.

Data Analyst Agent

Führt Abfragen durch, visualisiert Daten und macht Daten über die GitLab-Plattform zugänglich, indem er GitLab Query Language (GLQL) verwendet, um umsetzbare Einblicke in deine Projekte und Teams zu liefern.

Beispiel-Prompts:

• "Wie viele Merge Requests wurden im letzten Quartal erstellt?"
• "Zeig mir, woran jedes Teammitglied diesen Monat gearbeitet hat."
• "Was sind die Trends bei Issue-Lösungszeiten?"
• "Finde alle offenen Issues mit dem Label 'bug' in meinem Projekt."
• "Generiere eine GLQL-Query, um Merge Requests nach Autor zu zählen."

Mehr über Data Analyst Agent erfahren.

Custom Agents

Erstelle eigene Agenten, die auf die spezifischen Workflows und Standards deines Teams zugeschnitten sind.

Häufige Use Cases

• Troubleshooting and Debugging Agent: Debugge Software-Bugs und Regressionen, analysiere Deployment-Fehler.
• Documentation Agent: Pflege Docs gemäß deinen Konventionen.
• Onboarding Assistant: Hilf neuen Teammitgliedern mit unternehmensspezifischen Praktiken.
• Compliance Monitor: Stelle sicher, dass regulatorische Anforderungen erfüllt werden.
• Localized Support Agent: Triage Support-Issues in einer lokalisierten Sprache, zum Beispiel Deutsch.

Sieh dir die Aufzeichnung des GitLab DACH Roadshow Vienna 2025 Duo Agent Platform Use Cases Talks an:

🎯 Jetzt ausprobieren: Interaktive Demo von Custom Agents – Erkunde, wie du Custom Agents erstellen und konfigurieren kannst.

Wie du einen Custom Agent erstellst

Custom Agents werden über deine Projekt- oder Gruppeneinstellungen konfiguriert. Die Schlüsselkomponente ist der System Prompt, der das Verhalten und die Expertise deines Agenten definiert.

System Prompt Beispiel vom Custom Agent devops-debug-failures-agent: text You are an expert in Dev, Ops, DevOps, and SRE, and can debug code and runtime failures. Your speciality is that you can correlate static SDLC data with runtime data from CI/CD pipelines, logs, and other tool calls necessary. Expect that the user has advanced knowledge, but always provide commands and steps to reproduce your analysis so they can learn from you. Start with a short summary and suggested actions, and then go into detail with thoughts, analysis, suggestions. Think creative and consider unknown unknowns in your debug journey.

Sichtbarkeitsoptionen:

• Private: Nur für Mitglieder des verwaltenden Projekts sichtbar (Developer-Rolle+). Kann nicht in anderen Projekten aktiviert werden.
• Public: Kann von jedem eingesehen und in jedem Projekt aktiviert werden, das die Voraussetzungen erfüllt. Erscheint im AI Catalog zur Entdeckung.

Vollständige Setup-Anleitung in der Dokumentation verfügbar.

Best Practices

System Prompt Tipps:

• Sei spezifisch über die Rolle und Verantwortlichkeiten des Agenten.
• Definiere klare Qualitätsstandards und Einschränkungen.
• Füge Beispiele für erwartete Outputs hinzu.
• Halte Prompts auf eine Hauptaufgabe fokussiert.

Klein anfangen:

• Beginne mit Read-only-Berechtigungen.
• Teste gründlich, bevor du Schreibzugriff gewährst.
• Sammle Team-Feedback und iteriere.

External Agents

External Agents laufen im Hintergrund auf der GitLab-Plattform, wenn sie durch Mentions (z.B. @ai-codex) oder Zuweisungen in Issues und Merge Requests ausgelöst werden. Anders als Foundational und Custom Agents, die interaktiv im Chat arbeiten, werden External Agents asynchron ausgeführt, was leistungsstarke Automatisierung mit spezialisierten KI-Anbietern ermöglicht.

Credential-Management: Ab der General Availability der GitLab Duo Agent Platform werden GitLab-verwaltete Credentials verwendet, um External Agents zu unterstützen, sodass Kunden keine API-Keys selbst verwalten und rotieren müssen.

Wann du External Agents verwenden solltest

• Du benötigst spezifisches Agentic-AI-Verhalten oder LLMs für spezialisierte Aufgaben.
• Du möchtest Event-gesteuerte Automatisierung (nicht interaktiven Chat).
• Du musst spezifische Compliance- oder Daten-Residency-Anforderungen erfüllen.

Warum External Agents verwenden?

• Nutze spezialisierte KI-Modelle: Greife auf providerspezifische Fähigkeiten zu, wie Claude Codes Code-Analyse oder OpenAI Codex' Task-Delegation.
• Erfülle Compliance-Anforderungen: Halte Daten innerhalb genehmigter KI-Anbieter für regulatorische oder Sicherheitsrichtlinien.
• Experimentiere mit Providern: Teste verschiedenes Agentic-AI- und LLM-Verhalten, um die beste Lösung für deine Workflows zu finden.
• Greife auf einzigartige Features zu: Nutze providerspezifische Tools wie Claude Codes Code-Analyse oder OpenAI Codex' Task-Delegation.

Real-World-Beispiel

Ein Entwicklungsteam nutzt OpenAI Codex als External Agent für Code Review. Wenn Entwickler(innen) Merge Requests erstellen, weisen sie Codex als Reviewer zu. Der Agent:

1. Analysiert die Code-Änderungen im MR.
2. Überprüft auf Best Practices und Code-Quality-Issues.
3. Schlägt Verbesserungen und Optimierungen vor.
4. Postet detaillierte Review-Kommentare mit spezifischen Empfehlungen.
5. Verlinkt zu relevanter Dokumentation.

All dies geschieht automatisch im Hintergrund, während das Entwicklungsteam weiterarbeitet, und die Ergebnisse werden direkt im Merge Request gepostet.

Unterstützte External Agents

Die folgenden Integrationen wurden getestet und sind verfügbar:

• Anthropic Claude – Code-Generierung, Review und Analyse
• OpenAI Codex – GPT-gestützte Code-Unterstützung

Beispiel-Verwendung: text @ai-codex Please implement this issue

Dies löst einen Runner-Execution-Job aus, der das externe KI-Tool ausführt und Ergebnisse zurück zu GitLab postet.

External Agents einrichten

Vollständige Setup-Anweisungen inklusive Service Accounts, Triggers und Konfigurationsbeispiele findest du in der External Agents Dokumentation.

Agentenverhalten mit AGENTS.md anpassen

Passe an, wie Agenten sich verhalten, indem du AGENTS.md-Dateien gemäß dem agents.md-Standard verwendest. Mehr dazu erfährst du in Teil 8: GitLab Duo Agent Platform anpassen: Chat-Regeln, Prompts und Workflows.

Den besten Agententyp für deine Use Cases wählen

Zusammenfassung

GitLab Duo Agent Platform bietet diese Agententypen:

• Foundational: Sofort einsatzbereite Agenten für gängige Aufgaben (Chat, Planner, Security Analyst, Data Analyst)
• Custom: Erstelle teamspezifische Agenten mit Custom Prompts und Verhaltensweisen
• External: Integriere externe KI-Tools

Starte mit Foundational Agents, erstelle Custom Agents für teamspezifische Anforderungen und erkunde External Agents, wenn du spezialisierte KI-Anbieter benötigst.

Nächster: Teil 4: Flows verstehen

Vorheriger: Teil 2: GitLab Duo Agentic Chat