Es funktioniert. Aber es nervt schnell.

Wer sich schon einmal gewünscht hat, der Repository-Browser würde sich mehr wie eine IDE anfühlen und weniger wie eine Abfolge von Breadcrumb-Pfaden: Der Dateibaum-Browser in GitLab 18.9 schafft genau das.

Was der Dateibaum-Browser bietet

Der Dateibaum-Browser ergänzt Datei- und Verzeichnisansichten um ein ein- und ausklappbares Panel mit anpassbarer Breite. Die Projektstruktur bleibt damit sichtbar, während du Code liest und navigierst – kein Kontextverlust, kein Zurückklicken mehr.

Dateien und Verzeichnisse werden im Baum neben der Dateiliste und dem Dateiinhalt angezeigt, sodass Struktur und Code gleichzeitig sichtbar sind.

Wer bereits mit einem Dateibaum in einer IDE oder einer Git-Plattform gearbeitet hat, wird sich sofort zurechtfinden:

Strukturbasierte Navigation

Verzeichnisse lassen sich auf- und zuklappen, Dateien wechseln – der Überblick über die aktuelle Position in der Repository-Hierarchie bleibt dabei erhalten. Beim direkten Aufruf einer verschachtelten Datei expandiert der Baum die übergeordneten Verzeichnisse und hebt die aktuelle Datei hervor. Der Baum synchronisiert sich außerdem mit der aktuellen Position: Wird eine Datei im Hauptinhaltsbereich ausgewählt, aktualisiert sich der Baum entsprechend.

Filtern nach Dateiname

Nach dem Öffnen des Baums lässt sich mit F der globale Suchdialog öffnen. Ein Teil des Dateinamens genügt, um direkt zu springen – die Ergebnisse zeigen jeweils das übergeordnete Verzeichnis an, damit klar ist, wo man landet.

Tastaturnavigation

Der Baum implementiert das W3C-ARIA-Treeview-Pattern: Navigation durch Dateien und Verzeichnisse ist vollständig per Tastatur möglich – mit Pfeiltasten sowie Enter, Leertaste, Pos1, Ende und Zeichentasten. Das verbessert die Zugänglichkeit für Screenreader-Nutzende und alle, die lieber ohne Maus arbeiten.

Responsives Verhalten

Auf dem Desktop liegt der Baum nebeneinander mit Dateiliste und Code. Auf kleineren Viewports wird er zur linken Seitenleiste, die sich bei Bedarf einblenden lässt. Auf Mobilgeräten ist der Baum ausgeblendet, damit die Code-Ansicht den gesamten Bildschirm nutzen kann.

Geeignet für große Repositories

Bei Repositories mit vielen Einträgen verwendet der Baum Paginierung: Weitere Einträge lassen sich bei Bedarf nachladen, ohne die Seite zu überlasten. Das Verhalten bleibt auch bei wachsenden Projekten stabil.

Der Dateibaum-Browser in Aktion

GitLab Principal Developer Advocate Michael Friedrich zeigt in einer Demo den neuen Dateibaum-Browser und wie er die Navigation in großen Repositories vereinfacht. Die Demo verwendet das Projekt GitLab project: Tanuki IoT Platform, das sich zum Ausprobieren in einem echten Repository anbietet.

Jetzt mit dem Dateibaum-Browser starten

Der Dateibaum-Browser ist auf GitLab.com verfügbar und wurde mit 18.9 für GitLab Self-Managed und GitLab Dedicated veröffentlicht.

So geht's:

1. Eine beliebige Datei- oder Verzeichnisansicht im Projekt öffnen (/<project>/-/tree/<branch>).
2. Links oben das Dateibaum-Symbol auswählen oder Shift+F drücken, um den Dateibaum-Browser ein- oder auszublenden.
3. F drücken, um Dateien nach Name oder Erweiterung zu filtern, den Suchbegriff eingeben und mit den Pfeiltasten sowie Enter direkt zur gewünschten Datei springen.

Ausblick

Das Source Code Team bei GitLab hat den Dateibaum-Browser mit Barrierefreiheit, Performance bei großen Repositories und konsistentem Verhalten über verschiedene Viewports hinweg als Kernanforderungen entwickelt. Diese Prinzipien werden auch die weitere Entwicklung leiten – Feedback aus der Community fließt dabei aktiv ein.

Feedback zum Dateibaum-Browser

Gedanken zum Dateibaum-Browser gerne im Feedback-Issue teilen.

Mehr zum Dateibaum-Browser: Dokumentation zum Dateibaum-Browser.

Mit der MCP-Unterstützung des GitLab Duo Agent Platform lassen sich Jira und andere MCP-kompatible Tools direkt in die KI-gestützte Entwicklungsumgebung einbinden. Issues abfragen, Tickets aktualisieren, Workflows synchronisieren – per natürlicher Sprache, direkt aus der IDE.

Was in diesem Tutorial vermittelt wird

Dieses Tutorial zeigt:

• Einrichtung der Jira/Atlassian OAuth-Anwendung für sichere Authentifizierung
• Konfiguration des GitLab Duo Agent Platform als MCP-Client
• Drei praxisnahe Anwendungsfälle mit realen Workflows

Voraussetzungen

Vor dem Start sollten folgende Voraussetzungen erfüllt sein:

Architektur verstehen

Der GitLab Duo Agent Platform agiert als MCP-Client und stellt eine Verbindung zum Atlassian MCP-Server her, um auf Jira-Projektmanagement-Daten zuzugreifen. Der Atlassian MCP-Server übernimmt die Authentifizierung, übersetzt natürlichsprachliche Anfragen in API-Aufrufe und gibt strukturierte Daten zurück – bei gleichzeitiger Einhaltung von Sicherheits- und Audit-Anforderungen.

Teil 1: Jira OAuth-Anwendung konfigurieren

Um den GitLab Duo Agent Platform sicher mit der Jira-Instanz zu verbinden, muss eine OAuth 2.0-Anwendung in der Atlassian Developer Console erstellt werden. Diese erteilt dem GitLab MCP-Server autorisierten Zugriff auf die Jira-Daten.

Einrichtungsschritte

Für die manuelle Konfiguration sind folgende Schritte erforderlich:

1. Atlassian Developer Console aufrufen
   • developer.atlassian.com/console/myapps öffnen
   • Mit dem Atlassian-Konto anmelden
2. Neue OAuth 2.0-App erstellen
   • Create → OAuth 2.0 integration klicken
   • Namen eingeben (z. B. „gitlab-dap-mcp")
   • Nutzungsbedingungen akzeptieren und Create klicken
3. Berechtigungen konfigurieren
   • In der linken Seitenleiste zu Permissions navigieren
   • Jira API hinzufügen und folgende Scopes konfigurieren:
     • read:jira-work — Issues, Projekte und Boards lesen
     • write:jira-work — Issues erstellen und aktualisieren
     • read:jira-user — Benutzerinformationen lesen
4. Autorisierung einrichten
   • In der linken Seitenleiste zu Authorization navigieren
   • Callback-URL für die Umgebung hinzufügen (https://gitlab.com/oauth/callback)
   • Änderungen speichern
5. Zugangsdaten abrufen
   • Zu Settings navigieren
   • Client ID und Client Secret kopieren
   • Sicher aufbewahren – diese werden für die MCP-Konfiguration benötigt

Interaktive Anleitung: Jira OAuth-Einrichtung

Auf das Bild klicken, um zu beginnen.

Teil 2: GitLab Duo Agent Platform MCP-Client konfigurieren

Mit den bereitgestellten OAuth-Zugangsdaten kann der GitLab Duo Agent Platform nun für die Verbindung mit dem Atlassian MCP-Server konfiguriert werden.

MCP-Konfigurationsdatei erstellen

Die MCP-Konfigurationsdatei im GitLab-Projekt unter .gitlab/duo/mcp.json erstellen:

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp",
      "auth": {
        "type": "oauth2",
        "clientId": "YOUR_CLIENT_ID",
        "clientSecret": "YOUR_CLIENT_SECRET",
        "authorizationUrl": "https://auth.atlassian.com/oauth/authorize",
        "tokenUrl": "https://auth.atlassian.com/oauth/token"
      },
      "approvedTools": true
    }
  }
}

YOUR_CLIENT_ID und YOUR_CLIENT_SECRET durch die in Teil 1 generierten Zugangsdaten ersetzen.

MCP in GitLab aktivieren

1. Zu Gruppeneinstellungen → GitLab Duo → Konfiguration navigieren
2. „Externe MCP-Tools erlauben" aktivieren

Verbindung überprüfen

Das Projekt in VS Code öffnen und im GitLab Duo Agent Platform Chat eingeben:

What MCP tools do you have access to?

Dann

Test the MCP JIRA configuration in this project

Anschließend erfolgt eine Weiterleitung von der IDE zur MCP Atlassian-Website zur Zugriffsgenehmigung:

Überprüfung über das MCP-Dashboard

GitLab bietet zudem ein integriertes MCP-Dashboard direkt in der IDE.

In VS Code oder VSCodium die Befehlspalette öffnen (Cmd+Shift+P unter macOS, Ctrl+Shift+P unter Windows/Linux) und nach „GitLab: Show MCP Dashboard" suchen. Das Dashboard öffnet sich in einem neuen Editor-Tab und zeigt:

• Verbindungsstatus für jeden konfigurierten MCP-Server
• Verfügbare Tools des Servers (z. B. jira_get_issue, jira_create_issue)
• Server-Logs mit Echtzeit-Protokollierung der aufgerufenen Tools

Interaktive Anleitung: MCP testen

Teil 3: Anwendungsfälle in der Praxis

Mit der konfigurierten Integration lassen sich drei praxisnahe Workflows erkunden, die die Möglichkeiten der Jira-Anbindung an den GitLab Duo Agent Platform demonstrieren.

Planungsassistent

Szenario: Vorbereitung auf Sprint-Planung – schnelle Bewertung des Backlogs, Verstehen von Prioritäten, Identifizierung von Blockern.

Diese Demo zeigt:

• Backlog abfragen
• Nicht zugewiesene hochpriorisierte Issues identifizieren
• KI-gestützte Sprint-Empfehlungen erhalten

Beispiel-Prompts

Im GitLab Duo Agent Platform Chat ausprobieren:

List all the unassigned issues in JIRA for project GITLAB

Suggest the two top issues to prioritize and summarize them. Assign them to me.

Interaktive Anleitung: Projektplanung

Issue-Triage und Erstellung aus dem Code

Szenario: Beim Code-Review wird ein Bug entdeckt – ein Jira-Issue mit relevantem Kontext erstellen, ohne die IDE zu verlassen.

Diese Demo zeigt:

• Einen Bug beim Coding identifizieren
• Ein detailliertes Jira-Issue per natürlicher Sprache erstellen
• Issue-Felder automatisch mit Code-Kontext befüllen
• Das Issue mit dem aktuellen Branch verknüpfen

Beispiel-Prompts

Search in JIRA for a bug related to: Null pointer exception in PaymentService.processRefund().

If it does not exist create it with all the context needed from the code. Find possible blockers that this bug may cause.

Create a new branch called issue-gitlab-18, checkout, and link it to the issue we just created. Assign the JIRA issue to me and mark it as in-progress.

Interaktive Anleitung: Bug-Review und Aufgaben-Automatisierung

Systemübergreifende Incident-Untersuchung

Szenario: Ein Production-Incident tritt auf – Informationen aus Jira, GitLab Project Management, Codebase und Merge Requests werden korreliert, um die Ursache zu identifizieren.

Diese Demo zeigt:

• Incident-Details aus Jira abrufen
• Mit aktuellen Merge Requests in GitLab korrelieren
• Möglicherweise betroffene Code-Änderungen identifizieren
• Eine Incident-Timeline generieren
• Einen Behebungsplan entwerfen und als Work Item in GitLab erstellen

Beispiel-Prompts

"We have a production incident INC-1 about checkout failures. Can you help me investigate with all available context?"

Create a timeline of events for incident INC-1 including related Jira issues and recent deployments

Propose a remediation plan

Interaktive Anleitung: Systemübergreifende Fehleranalyse und Behebung

Fehlerbehebung

Häufige Einrichtungsprobleme und schnelle Lösungen:

Sicherheitshinweise

Bei der Integration von Jira mit dem GitLab Duo Agent Platform:

• OAuth-Token — Zugangsdaten sicher aufbewahren
• Prinzip der minimalen Rechtevergabe — Nur die minimal erforderlichen Jira-Scopes vergeben
• Token-Rotation — OAuth-Zugangsdaten regelmäßig rotieren

Zusammenfassung

Die Anbindung des GitLab Duo Agent Platform an verschiedene Tools über MCP verändert die Interaktion mit dem Entwicklungslebenszyklus. In diesem Artikel wurde gezeigt:

• Issues per natürlicher Sprache abfragen — Fragen zum Backlog, zu Sprints und Incidents in natürlicher Sprache stellen.
• Issues in der gesamten DevSecOps-Umgebung erstellen und aktualisieren — Bugs melden und Tickets aktualisieren, ohne die IDE zu verlassen.
• Systemübergreifend korrelieren — Jira-Daten mit GitLab Project Management, Merge Requests und Pipelines für vollständige Transparenz kombinieren.
• Kontextwechsel reduzieren — Fokus auf den Code behalten und gleichzeitig mit dem Projektmanagement verbunden bleiben.

Für deutsche Unternehmen könnte dies folgende Themen betreffen

Teams, die externe Tools über MCP einbinden, haben möglicherweise auch Governance- und Sicherheitsüberlegungen – beispielsweise in Bereichen wie Zugriffskontrolle, Token-Management und Audit-Nachvollziehbarkeit.

Regulatorische Frameworks wie NIS2, ISO 27001 und DSGVO adressieren ähnliche Themen rund um Zugriffssteuerung und Protokollierung. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.

Weiterführende Informationen

• GitLab Duo Agent Platform unterstützt jetzt das Model Context Protocol
• Was ist das Model Context Protocol?
• Leitfäden und Ressourcen für Agentic AI
• Dokumentation zu GitLab-MCP-Clients
• Erste Schritte mit der GitLab Duo Agent Platform: Der vollständige Leitfaden

Wie wird Code Review vom Engpass zum Beschleuniger?

Teams erstellen Merge Requests schneller, wenn KI beim Coding unterstützt – doch menschliche Reviewer können kaum mithalten, wenn Review-Zyklen von Stunden auf Tage anwachsen. KI übernimmt Routineprüfungen wie logische Fehler und API-Vertragsverletzungen, damit Reviewer sich auf Architektur und Geschäftslogik konzentrieren können.

MR auf logische Fehler prüfen

Komplexität: Einstieg Kategorie: Code Review Prompt aus der Bibliothek:

Review this MR for logical errors, edge cases, and potential bugs: [MR URL or paste code]

Warum das hilft: Automatische Linter erkennen Syntaxfehler – logische Fehler erfordern das Verständnis der Absicht hinter dem Code. Dieser Prompt findet Bugs, bevor Reviewer überhaupt einen Blick darauf werfen, und reduziert Review-Zyklen häufig auf eine einzige Freigaberunde.

Breaking Changes im MR identifizieren

Komplexität: Einstieg Kategorie: Code Review Prompt aus der Bibliothek:

Does this MR introduce any breaking changes?

Changes:

[PASTE CODE DIFF]

Check for:

1. API signature changes

2. Removed or renamed public methods

3. Changed return types

4. Modified database schemas

5. Breaking configuration changes

Warum das hilft: Breaking Changes, die erst beim Deployment auffallen, erzwingen Rollbacks und verursachen Incidents. Dieser Prompt verlagert die Erkennung in die MR-Phase – wo Korrekturen deutlich weniger aufwändig sind.

Wie lässt sich Security nach links verschieben, ohne den Prozess zu verlangsamen?

Security-Scans erzeugen Hunderte von Befunden. Security-Teams triagieren manuell, während Entwicklerinnen und Entwickler auf Deployment-Freigaben warten. Der Großteil der Befunde sind False Positives oder Niedrigrisiko-Probleme – die tatsächlichen Bedrohungen herauszufiltern kostet Zeit und Expertise. KI priorisiert Befunde nach tatsächlicher Ausnutzbarkeit und unterstützt bei der Behebung häufiger Schwachstellen, sodass Security-Teams sich auf die relevanten Bedrohungen konzentrieren können.

Security-Scan-Ergebnisse analysieren

Komplexität: Fortgeschritten Kategorie: Security Agent: Duo Security Analyst Prompt aus der Bibliothek:

@security_analyst Analyze these security scan results:

[PASTE SCAN OUTPUT]

For each finding:

1. Assess real risk vs false positive

2. Explain the vulnerability

3. Suggest remediation

4. Prioritize by severity

Warum das hilft: Dieser Prompt hilft Security-Teams, sich auf die Befunde zu konzentrieren, die tatsächlich relevant sind – und reduziert die Zeit bis zur Behebung von Wochen auf Tage.

Code auf Sicherheitsprobleme prüfen

Komplexität: Fortgeschritten Kategorie: Security Agent: Duo Security Analyst Prompt aus der Bibliothek:

@security_analyst Review this code for security issues:

[PASTE CODE]

Check for:

1. Injection vulnerabilities

2. Authentication/authorization flaws

3. Data exposure risks

4. Insecure dependencies

5. Cryptographic issues

Warum das hilft: Herkömmliche Security-Reviews finden statt, nachdem Code geschrieben wurde. Dieser Prompt ermöglicht es, Sicherheitsprobleme vor dem Erstellen eines MR zu erkennen und zu beheben – und eliminiert die Abstimmungsschleifen, die Deployments verzögern.

Wie bleibt Dokumentation mit dem Code auf dem neuesten Stand?

Code ändert sich schneller als Dokumentation. Neue Teammitglieder benötigen Wochen für das Onboarding, weil Docs veraltet oder unvollständig sind. Dokumentation wird stets als wichtig erkannt, aber bei Deadlines zuerst verschoben. Automatisierte Generierung und Aktualisierung als Teil des Standard-Workflows hält Docs aktuell – ohne zusätzlichen Aufwand.

Release Notes aus MRs generieren

Komplexität: Einstieg Kategorie: Dokumentation Prompt aus der Bibliothek:

Generate release notes for these merged MRs:

[LIST MR URLs or paste titles]

Group by:

1. New features

2. Bug fixes

3. Performance improvements

4. Breaking changes

5. Deprecations

Warum das hilft: Die manuelle Zusammenstellung von Release Notes dauert Stunden und enthält häufig Lücken oder Fehler. Automatisierte Generierung stellt sicher, dass jedes Release vollständige Notes erhält – ohne zusätzlichen Aufwand im Release-Prozess.

Dokumentation nach Code-Änderungen aktualisieren

Komplexität: Einstieg Kategorie: Dokumentation Prompt aus der Bibliothek:

I changed this code:

[PASTE CODE CHANGES]

What documentation needs updating? Check:

1. README files

2. API documentation

3. Architecture diagrams

4. Onboarding guides

Warum das hilft: Dokumentation driftet, weil Teams nach Code-Änderungen nicht immer im Blick haben, welche Docs betroffen sind. Dieser Prompt macht Dokumentationspflege zum Teil des Entwicklungsworkflows – statt einer Aufgabe, die aufgeschoben wird.

Wie lässt sich Planungskomplexität systematisch aufbrechen?

Große Features bleiben in der Planungsphase stecken. KI kann komplexe Arbeit strukturiert in konkrete, umsetzbare Aufgaben mit klaren Abhängigkeiten und Akzeptanzkriterien zerlegen – und so wochenlange Abstimmung in fokussierte Implementierung verwandeln.

Epic in Issues aufteilen

Komplexität: Fortgeschritten Kategorie: Dokumentation Agent: Duo Planner Prompt aus der Bibliothek:

Break down this epic into implementable issues:

[EPIC DESCRIPTION]

Consider:

1. Technical dependencies

2. Reasonable issue sizes

3. Clear acceptance criteria

4. Logical implementation order

Warum das hilft: Dieser Prompt verwandelt eine Woche Planungsmeetings in 30 Minuten KI-gestützte Zerlegung – gefolgt von einer Teamabstimmung. Teams starten früher mit der Implementierung und mit klarerer Ausrichtung.

Wie lässt sich Testabdeckung ausbauen, ohne den Aufwand zu erhöhen?

Entwicklerinnen und Entwickler schreiben Code schneller, aber wenn Tests nicht mithalten, sinkt die Testabdeckung und Fehler gelangen in die Produktion. Tests manuell zu schreiben ist aufwändig – und unter Zeitdruck werden Randfälle übersehen. Automatisch generierte Tests bedeuten: prüfen und anpassen statt von Grund auf neu schreiben.

Unit-Tests generieren

Komplexität: Einstieg Kategorie: Testing Prompt aus der Bibliothek:

Generate unit tests for this function:

[PASTE FUNCTION]

Include tests for:

1. Happy path

2. Edge cases

3. Error conditions

4. Boundary values

5. Invalid inputs

Warum das hilft: Manuelle Tests sind aufwändig, und Randfälle werden unter Zeitdruck oft übersehen. Dieser Prompt generiert umfassende Test-Suites, die Entwicklerinnen und Entwickler prüfen und anpassen – statt von Grund auf zu schreiben.

Lücken in der Testabdeckung erkennen

Komplexität: Einstieg Kategorie: Testing Prompt aus der Bibliothek:

Analyze test coverage for [MODULE/COMPONENT]:

Current coverage: [PERCENTAGE]

Identify:

1. Untested functions/methods

2. Uncovered edge cases

3. Missing error scenario tests

4. Integration points without tests

5. Priority areas to test next

Warum das hilft: Dieser Prompt zeigt blinde Flecken in der Test-Suite auf, bevor sie zu Production-Incidents werden. Teams können die Abdeckung dort systematisch verbessern, wo es am meisten zählt.

Wie lässt sich die Zeit bis zur Fehlerbehebung verkürzen?

Production-Incidents dauern Stunden in der Diagnose. Entwicklerinnen und Entwickler durchsuchen Logs und Stack Traces, während Nutzerinnen und Nutzer Ausfälle erleben. KI beschleunigt die Ursachenanalyse durch Auswertung komplexer Fehlermeldungen und konkrete Lösungsvorschläge – und verkürzt die Diagnosezeit von Stunden auf Minuten.

Fehlerhafte Pipeline debuggen

Komplexität: Einstieg Kategorie: Debugging Prompt aus der Bibliothek:

This pipeline is failing:

Job: [JOB NAME]

Stage: [STAGE]

Error: [PASTE ERROR MESSAGE/LOG]

Help me:

1. Identify the root cause

2. Suggest a fix

3. Explain why it started failing

4. Prevent similar issues

Warum das hilft: CI/CD-Ausfälle blockieren das gesamte Team. Dieser Prompt analysiert Fehler in Sekunden statt in den 15 bis 30 Minuten, die Entwicklerinnen und Entwickler typischerweise für die Fehlersuche benötigen.

Von individuellen Gewinnen zu echter Team-Beschleunigung

Diese Prompts stehen für einen Ansatz, der KI nicht nur beim individuellen Coding einsetzt, sondern an den Stellen, die Team-Velocity tatsächlich begrenzen: Koordination, Qualitätssicherung und Wissenstransfer. Die vollständige Prompt-Bibliothek enthält mehr als 100 Prompts für alle Phasen des Softwarelebenszyklus – von Planung und Entwicklung über Security und Testing bis hin zu Deployment und Betrieb. Jeder Prompt ist nach Komplexitätsstufe (Einstieg, Fortgeschritten, Experte) und Anwendungsfall kategorisiert. Mit Prompts der Stufe „Einstieg" lässt sich am dringendsten Engpass beginnen. Ziel ist nicht schnelleres Coding allein – sondern zuverlässigere, qualitativ hochwertigere Software-Lieferung von der Planung bis zur Produktion.

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.