Der Planungsaufwand reduziert die Zeit für strategische Entscheidungen, die Produkte tatsächlich voranbringen.

Für diese Herausforderung haben wir GitLab Duo Planner entwickelt – einen KI-Agent auf Basis der GitLab Duo Agent Platform, der Produktmanager direkt in GitLab unterstützt.

GitLab Duo Planner ist kein generischer KI-Assistent. Die Produkt- und Engineering-Teams bei GitLab haben den Agent gezielt für Planungs-Workflows entwickelt, um Overhead zu reduzieren und gleichzeitig Alignment und Planbarkeit zu verbessern.

Unterstützung für deine Planung

Drei Herausforderungen in der Planungspraxis:

1. Ungeplante Arbeit – Unkoordinierte Tasks und verwaiste Work Items reduzieren das Vertrauen in die Planung.
2. Unterbrechungen – Ständige Status-Anfragen unterbrechen den Entwicklungsfluss.
3. Intransparenz – Risiken werden zu spät sichtbar, um gegenzusteuern.

GitLab Duo Planner unterstützt Teams bei diesen Aufgaben: Der Agent strukturiert vage Ideen in konkrete Anforderungen, identifiziert Backlog-Probleme frühzeitig und wendet Priorisierungs-Frameworks wie RICE und MoSCoW an. Durch die Integration in GitLab hat der Agent Zugriff auf den vollständigen Kontext der Plattform. Die foundational agent architecture ermöglicht GitLab-spezifisches Wissen und Kontext-Awareness.

Für Teams entwickelt

GitLab Duo Planner arbeitet mit Work Items (Epics, Issues, Tasks) und versteht Work Breakdown Structures, Dependency-Analysen und Aufwandsschätzungen. Dies verbessert Transparenz, Alignment und Planungssicherheit.

Plattform-Ansatz: Im Unterschied zu Einzellösungen orchestriert Duo Planner über die gesamte GitLab-Plattform – von der Planung über Development bis Testing. Dies schafft Transparenz über Teams und Workflows hinweg.

Im Workflow integriert: Kein Wechsel zwischen Tools oder tiefes Navigieren in GitLab erforderlich. Duo Planner ermöglicht Beiträge, Kollaboration und Transparenz für alle Beteiligten im Software Development Lifecycle.

Zeitersparnis: Duo Planner befreit Teams von repetitiver Koordinationsarbeit, verbessert die Planbarkeit von Deliveries und reduziert verpasste Commitments. Der Fokus liegt auf der Arbeit, die tatsächlich Wirkung zeigt.

Sechs Workflows für Software-Planung

GitLab Duo Planner unterstützt verschiedene Phasen der Software-Planung und arbeitet innerhalb des Planungsbereichs – einer definierten Umgebung mit Projekt-Visibility.

Der Agent deckt sechs Workflows ab:

Priorisierung: Frameworks wie RICE, MoSCoW oder WSJF werden angewendet, um Work Items systematisch zu ranken. RICE bewertet nach Reach, Impact, Confidence und Effort. MoSCoW kategorisiert nach Must have, Should have, Could have, Won't have. WSJF (Weighted Shortest Job First) gewichtet nach Business Value, Time Criticality und Risk Reduction.

Work Breakdown: Initiativen werden in Epics, Features und User Stories zerlegt, um Anforderungen zu strukturieren. Dies folgt der hierarchischen Work Item-Struktur in GitLab.

Dependency-Analyse: Der Agent identifiziert blockierte Arbeit und versteht Beziehungen zwischen Items, um die Velocity aufrechtzuerhalten. Abhängigkeiten werden als Blocker oder "blocked by"-Relationen erfasst.

Planung: Organisation von Sprints, Milestones oder Quartalsplanungen. Der Agent berücksichtigt dabei die verfügbare Kapazität und bestehende Commitments.

Status-Reporting: Generierung von Zusammenfassungen über Projekt-Fortschritt, Risiken und Blocker zum Tracking von Deliveries. Die Reports strukturieren sich nach Overview, Milestone-Status, In-Progress Items, Dependencies und Blockers.

Backlog Management: Identifikation veralteter Issues, Duplikate oder Items, die Verfeinerung benötigen. Dies verbessert die Datenhygiene im Backlog.

Demonstration: Status-Check einer Initiative

Hier siehst du, wie GitLab Duo Planner den Status einer Initiative prüft:

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1131065078?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Duo Planner Agent"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

Duo Planner ist als Custom Agent im Duo Chat Side Panel verfügbar und nutzt den aktuellen Seiten-Kontext.

<p></p>

<p></p>

Wir fragen Duo Planner nach dem Status einer Initiative, indem wir den Epic-Link angeben:

<p></p>

Der Agent liefert eine strukturierte Zusammenfassung mit Overview, aktuellem Status der Milestones, in Bearbeitung befindlichen Items, Dependencies und Blockern sowie umsetzbaren Empfehlungen.

<p></p>

Als Nächstes fordern wir eine Executive Summary an, um Stakeholder zu informieren. GitLab Duo Planner reduziert den manuellen Analyseaufwand für Reports und unterstützt schnellere Entscheidungen.

<p></p>

<p></p>

Weitere Beispiel-Prompts für GitLab Duo Planner:

• "Welche Bugs mit dem Label 'boards' sollten wir priorisieren, unter Berücksichtigung der User Impact?"
• "Ranke diese Epics nach strategischem Wert für Q1."
• "Hilf mir, Technical Debt gegen neue Features zu priorisieren."
• "Welche Tasks sind erforderlich, um diese User Story zu implementieren?"
• "Schlage einen phasenweisen Ansatz für dieses Projekt vor: (URL einfügen)."

Agile-Planung mit GitLab

GitLab Duo Planner konzentriert sich gezielt auf Produktmanager und Engineering Manager in Agile-Umgebungen. Diese Spezialisierung ermöglicht verlässliche, umsetzbare Erkenntnisse statt generischer Vorschläge. Der Agent wurde auf GitLabs Planungs-Workflows und Agile Frameworks trainiert.

Die Agent Platform entwickelt sich weiter: Wir arbeiten an einer Familie spezialisierter Agents, die jeweils für spezifische Workflows optimiert sind und zu einer unified intelligence layer beitragen. Der heutige Planner für Software-Teams ist der erste Schritt für KI-gestützte Priorisierung in verschiedenen Team-Kontexten.

Integration in deutsche Agile-Prozesse: GitLab Duo Planner lässt sich in bestehende Scrum- und Kanban-Workflows integrieren. Der Agent arbeitet mit der Standard-Work-Item-Hierarchie in GitLab und respektiert definierte Projekt-Boundaries. Beispielsweise können Teams den Agent für Sprint Planning einsetzen, indem sie Backlog-Items nach RICE bewerten lassen und anschließend die Ergebnisse im Sprint Planning Meeting verwenden.

Technische Voraussetzungen: Die Nutzung erfordert GitLab mit aktivierter Duo Chat Funktion. Der Agent operiert innerhalb der konfigurierten Projekt-Visibility und hat Zugriff auf Work Items, für die du Leserechte besitzt. Die Dokumentation erklärt Prerequisites, Anwendungsfälle und Konfiguration im Detail.

Wenn du GitLab-Kunde bist und GitLab Duo Planner mit eigenen Prompts testen möchtest, findest du in unserer Dokumentation Prerequisites, Anwendungsfälle und weitere Details.

Java 8 hat im Januar 2019 das Ende der öffentlichen Updates für kommerzielle Nutzung erreicht. Laut aktuellen Telemetrie-Daten laufen jedoch fast 50 Prozent aller produktiven Workloads weiterhin auf Java 8 oder 11. Enterprise-Umgebungen verzögern Upgrades häufig aufgrund der Komplexität: Code-Refactoring, Dependency-Updates und umfangreiche Tests sind erforderlich. Ohne aktuelle Sicherheits-Patches steigen jedoch Compliance-Risiken, insbesondere in regulierten Branchen wie Finanzdienstleistungen oder Gesundheitswesen.

Automatisierte Java-Modernisierung

Java-Upgrades auf neuere, unterstützte Versionen erfordern typischerweise umfangreiche Anpassungen. Entwicklungsteams müssen deprecated APIs identifizieren, Bibliotheks-Abhängigkeiten aktualisieren und neue Sprachfeatures verstehen. In vielen Fällen sind größere Code-Überarbeitungen notwendig, wodurch Java-Upgrades zu mehrwöchigen Projekten werden, die Ressourcen von der Feature-Entwicklung abziehen.

GitLab Duo mit Amazon Q automatisiert den Java-Upgrade-Prozess durch KI-gestützte Code-Analyse. Die Integration analysiert den bestehenden Java-8-Code, erstellt einen Upgrade-Plan und generiert automatisch einen Merge Request mit allen notwendigen Anpassungen. Dabei bleiben die Funktionalität der Anwendung und die vollständige Nachvollziehbarkeit durch GitLabs Merge-Request-Workflow erhalten.

Voraussetzungen

Die Integration setzt GitLab Self-Managed ab Version 17.11 mit Ultimate-Lizenz und dem GitLab-Duo-mit-Amazon-Q-Add-on voraus. Zusätzlich sind ein Amazon Q Developer Profile, eine IAM-Rolle mit OIDC-Identity-Provider und eine HTTPS-URL für die GitLab-Instanz erforderlich. Die vollständige Setup-Dokumentation für Self-Managed-Installationen finden Sie unter docs.gitlab.com/user/duo_amazon_q/setup.

Der Java-Upgrade-Prozess

Der Java-Upgrade-Prozess mit GitLab Duo und Amazon Q umfasst folgende Schritte:

1. Issue erstellen

Erstellen Sie ein Issue im GitLab-Projekt und beschreiben Sie das Upgrade-Ziel im Titel und in der Beschreibung. GitLab Duo mit Amazon Q analysiert automatisch die verwendete Java-Version und erkennt, dass ein Upgrade von Java 8 auf Java 17 erforderlich ist. Eine explizite Versionsspezifikation ist optional.

2. Transformation starten

Nachdem das Issue erstellt wurde, geben Sie den Befehl /q transform als Kommentar im Issue ein. Dieser Befehl startet den automatisierten Prozess, der den gesamten Code analysiert, einen Upgrade-Plan erstellt und die notwendigen Code-Änderungen generiert.

3. Automatisierte Analyse und Code-Anpassung

Amazon Q analysiert die Java-8-Codebasis und identifiziert die Anwendungsstruktur, Abhängigkeiten und Implementierungsmuster. Der Analyseprozess erkennt deprecated Features, bestimmt die entsprechenden Java-17-Konstrukte und erstellt einen Merge Request mit allen erforderlichen Anpassungen. Im Demonstration-Projekt wurden beispielsweise String.format()-Aufrufe durch die moderne .formatted()-Methode ersetzt, die ab Java 17 verfügbar ist. Die Transformation umfasst sowohl die Source-Code-Dateien (CLI-, GUI- und Model-Klassen) als auch die Build-Konfiguration in Dateien wie pom.xml mit aktualisierten Java-17-Einstellungen und Abhängigkeiten.

4. Review und Verifikation

Der generierte Merge Request zeigt alle Code-Änderungen übersichtlich an. Entwickler können die Java-17-Sprachfeatures im angepassten Code überprüfen und verifizieren, dass alle Tests weiterhin erfolgreich durchlaufen. Die Funktionalität der Anwendung bleibt dabei unverändert erhalten.

Vorteile für Entwicklungsteams

Die Java-Modernisierung mit GitLab Duo und Amazon Q bietet folgende Vorteile für Entwicklungsteams:

Zeitersparnis: Der automatisierte Prozess reduziert den manuellen Aufwand für Java-Upgrades erheblich. Im Walkthrough-Video wird ein Mortgage-Calculator-Projekt (480 Zeilen Code, CLI-, GUI- und Model-Komponenten) innerhalb von 3 Minuten von Java 8 auf Java 17 aktualisiert – von der Befehlseingabe bis zum fertigen Merge Request. Entwicklungsteams können sich dadurch stärker auf die Feature-Entwicklung konzentrieren, anstatt Ressourcen für die Wartung technischer Schulden einzusetzen.

Risikominimierung: Der automatisierte Analyse- und Transformationsprozess reduziert das Risiko manueller Fehler bei Code-Migrationen. Alle Änderungen sind durch GitLabs Merge-Request-Workflow nachvollziehbar und überprüfbar.

Vollständiger Audit-Trail: Jede Transformation wird durch GitLabs Versionsverwaltung dokumentiert. Dies ermöglicht eine lückenlose Nachvollziehbarkeit aller Änderungen und unterstützt Compliance-Anforderungen sowie das Troubleshooting.

Sicherheit: Die Integration nutzt GitLabs End-to-End-Sicherheitsfunktionen und AWS-Cloud-Infrastruktur. Code und Daten bleiben während des gesamten Upgrade-Prozesses innerhalb der bestehenden Sicherheitsarchitektur geschützt.

Demonstration und weitere Informationen

Das vollständige Walkthrough-Video demonstriert den Java-Upgrade-Prozess Schritt für Schritt:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/qGyzG9wTsEo?si=47JnSb6flOgZAJcR" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Weitere Informationen zu GitLab Duo mit Amazon Q finden Sie auf der Produktseite oder kontaktieren Sie Ihren GitLab-Ansprechpartner.

Weiterführende Ressourcen

• Agentic AI guides and resources
• GitLab Duo with Amazon Q: DevSecOps meets agentic AI
• More GitLab Duo with Amazon Q tutorials

Mit GitLab 18.5 bauen wir auf dieser Grundlage auf. Neue Funktionen verbessern Genauigkeit und Geschwindigkeit. Entwicklungsteams erhalten Ergebnisse, denen sie vertrauen können, ohne dass der Arbeitsfluss unterbrochen wird. Die Verbesserungen umfassen höhere Standardpräzision und Custom Detection Rules. Drei Optimierungen beschleunigen die Scans: Multi-Core-Scanning, algorithmische Optimierungen und Diff-basiertes Scannen. Zusammen machen diese Verbesserungen Advanced SAST präziser und schneller.

Diese Verbesserungen sind besonders relevant für Entwicklungsteams in regulierten Branchen. Systematische Security-Scans sind dort oft Compliance-Anforderung – beispielsweise für Unternehmen mit TISAX-Zertifizierung in der Automobilindustrie oder BaFin-Vorgaben im Finanzsektor. Gleichzeitig müssen diese Scans schnell genug ablaufen, damit Entwicklungsteams produktiv bleiben. Die Kombination aus Genauigkeit und Performance ist entscheidend für erfolgreiche SAST-Programme.

Das Problem: Adoption scheitert an falschen Trade-offs

SAST-Programme scheitern selten an ungenauen Schwachstellenerkennung. Sie scheitern daran, dass Entwicklungsteams die Security-Tools nicht nutzen. Viele AppSec-Lösungen liefern Genauigkeit auf Kosten der Entwicklererfahrung. Andere priorisieren Usability, verlieren aber an Präzision. In der Realität sind beide Dimensionen notwendig. Ohne Genauigkeit vertrauen Entwickler den Ergebnissen nicht. Ohne Geschwindigkeit und Benutzerfreundlichkeit sinkt die Adoption.

Wenn beide Faktoren zusammenkommen, fügt sich Security natürlich in den Entwicklungsprozess ein. Nur so können Security-Teams SAST-Adoption in großem Umfang erreichen. Diese Philosophie prägt die GitLab-Roadmap für Advanced SAST.

Höhere Präzision durch bessere Regeln und Custom Detection

Die integrierten Advanced SAST Rules basieren auf Erkenntnissen des hauseigenen Security-Research-Teams von GitLab. Sie maximieren die Genauigkeit standardmäßig. Bisher konnten Regeln deaktiviert oder in Name, Beschreibung und Severity angepasst werden. Eigene Detection-Logik war jedoch nicht möglich. Mit GitLab 18.5 können Teams nun eigene musterbasierte Custom Rules definieren. Damit lassen sich organisationsspezifische Probleme erkennen – beispielsweise verbotene Funktionsaufrufe. Verstöße gegen Custom Rules werden am selben Ort wie die integrierten GitLab-Regeln gemeldet. Entwicklungsteams erhalten Informationen aus einem zentralen Dashboard.

Custom Rules eignen sich für klar definierte Probleme, die für die Organisation relevant sind. Sie beeinflussen jedoch nicht die Taint-Analyse, die Advanced SAST zur Erkennung von Injections und ähnlichen Schwachstellen nutzt. Custom Rules werden über TOML-Dateien verwaltet, wie andere SAST-Ruleset-Konfigurationen auch. Das Ergebnis: Scan-Ergebnisse mit höherer Qualität, angepasst an den spezifischen Kontext. Security-Teams erhalten mehr Kontrolle. Entwickler erhalten klarere und umsetzbare Findings.

Kürzere Scan-Zeiten für höhere Adoption

Geschwindigkeit ist ein entscheidender Faktor. Wenn ein SAST-Scan zu lange dauert, wechseln Entwickler oft zu anderen Aufgaben. Die Adoption sinkt.

Deshalb haben wir mehrere Performance-Verbesserungen implementiert, um Scan-Zeiten erheblich zu reduzieren – ohne Kompromisse bei der Genauigkeit:

• Multi-Core-Scanning: Nutzt mehrere CPU-Kerne auf GitLab Runners
• Diff-basiertes Scannen: Scannt nur den geänderten Code in einem Merge Request
• Laufende Optimierungen: Intelligentere Algorithmen und Engine-Verbesserungen

Diese Verbesserungen bauen aufeinander auf und liefern schnellere Scans mit erheblichem Impact:

• Multi-Core-Scanning reduziert die Scan-Laufzeit typischerweise um bis zu 50 Prozent.
• Diff-basiertes Scannen hilft besonders bei großen Repositories, in denen bei jeder Änderung weniger Code modifiziert wird. Es ist speziell darauf ausgelegt, schnelleres Feedback im Code-Review-Prozess zu liefern, indem es schnellere Scans in Merge Requests ermöglicht. In unseren Tests benötigen viele große Repositories jetzt weniger als 10 Minuten für Ergebnisse in MRs, während Scans zuvor mehr als 20 Minuten dauerten.
• In aktuellen internen Tests haben algorithmische Optimierungen die Scan-Zeiten bei großen Open-Source-Codebasen um bis zu 71 Prozent reduziert. Apache Lucene (Java) zeigte die größte Verbesserung. Auch andere Projekte wie Django (Python), Kafka und Zulip verzeichneten Performance-Steigerungen von über 50 Prozent im Single-Core-Modus. Die Ergebnisse sind in den Charts unten dargestellt.

Für Entwicklungsteams bedeutet das: schnelleres Feedback in Merge Requests, weniger Wartezeit auf Security-Ergebnisse und eine reibungslosere Adoption. Mit Multi-Core-Scanning und Diff-basierter Analyse werden die Verbesserungen noch größer.

<p></p>

<p></p>

Diese Performance-Verbesserungen spiegeln GitLabs Fokus auf bessere Workflows für Entwicklungsteams wider. Ein Kunde ist kürzlich auf GitLabs Pipeline Execution Policies umgestiegen. Das Ziel: mehr Kontrolle und Flexibilität bei Security-Scans innerhalb der Pipelines. Durch Standardisierung von Templates, Caching und Optimierung der Pipeline-Logik konnte das Team die Laufzeiten für Dependency-Scans von 15–60 Minuten auf nur 1–2 Minuten pro Job reduzieren. Das spart täglich etwa 100 000 Compute Minutes über 15 000 Scans hinweg. Ein klares Beispiel dafür, wie anpassbare und effiziente Pipeline Execution Policies zu schnelleren Feedback-Zyklen, höherer Produktivität und breiterer Adoption führen.

Mit diesen Verbesserungen bietet Advanced SAST Security- und Entwicklungsteams die Genauigkeit, Geschwindigkeit und Flexibilität, die sie für moderne Softwareentwicklung benötigen. Durch Reduzierung von False Positives, Custom Detection und beschleunigte Scan-Zeiten wird Security zu einem Enabler für Entwicklungsteams.

Wie alle Application-Security-Funktionen von GitLab ist Advanced SAST direkt in die DevSecOps-Plattform integriert. Security wird so zu einem natürlichen Bestandteil davon, wie Entwicklungsteams Software erstellen, testen, deployen und absichern.

Das Ergebnis: schnellere Adoption, weniger Bottlenecks und sicherere Anwendungen von Beginn an.

Advanced SAST jetzt testen: Kostenlose Testversion von GitLab Ultimate starten.

Mehr erfahren

• GitLab Advanced SAST is now generally available
• A comprehensive guide to GitLab DAST
• GitLab Security Testing solutions

Im Mittelpunkt dieses Release steht eine wesentliche Verbesserung der allgemeinen Usability von GitLab und der Integration von KI in die User Experience. Ein neues Panel-basiertes UI erleichtert die kontextbezogene Darstellung von Daten und ermöglicht es, GitLab Duo Chat plattformübergreifend dauerhaft sichtbar zu halten, wo immer es benötigt wird. Spezialisierte Agenten übernehmen die Triage von Schwachstellen und das Backlog-Management, während sich beliebte KI-Tools noch nahtloser in agentenbasierte Workflows integrieren lassen. Zusätzlich wurden die marktführenden Sicherheitsfunktionen erweitert, um ausnutzbare Schwachstellen besser von theoretischen zu unterscheiden, aktive von abgelaufenen Credentials zu trennen und nur geänderten Code zu scannen, damit Entwickler im Flow bleiben können.

Was ist neu in 18.5

18.5 ist das bisher größte Release dieses Jahres – die Einführung in das Release im Video ansehen und weitere Details unten lesen. <div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1128975773?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab_18.5 Release_101925_MP_v2"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

Moderne User Experience mit schnellem Zugriff auf GitLab Duo überall

GitLab 18.5 verbessert die GitLab User Experience mit einem intuitiveren Interface, das auf einem neuen Panel-basierten Layout basiert.

Panels präsentieren Informationen nebeneinander und ermöglichen kontextbezogenes Arbeiten. Ein Klick auf ein Issue in der Issue-Liste zeigt die Details im zugehörigen Side Panel an. Das GitLab Duo Chat Panel lässt sich dann auf der rechten Seite des Interface als On-Demand-Assistent öffnen. Von überall in der GitLab-Umgebung aus können kontextbezogene Fragen an Agenten gestellt und Anweisungen gegeben werden. Weitere subtile Verbesserungen der Benutzerfreundlichkeit umfassen die Verschiebung der globalen Suchleiste in die obere Mitte für bessere Zugänglichkeit, während globale Navigationselemente – darunter My Issues, Merge Requests, To-Dos und das User-Icon – in die obere rechte Ecke wandern. Das linke Navigationsmenü lässt sich nun ein- und ausklappen, um eine flexible Sidebar-Verwaltung zu ermöglichen.

Das Panel-UI ist in GitLab 18.5 standardmäßig deaktiviert. Ein Opt-in-Toggle findet sich unter dem User-Icon. Mehr Informationen zum Aktivieren oder Deaktivieren dieser Funktion in der Dokumentation hier. Feedback und Bug-Reports sind willkommen – die Engineers hören zu. Sofern die Experience genauso überzeugt wie beim eigenen Team, wird dieser Toggle voraussichtlich in 18.6 entfernt, sodass das Panel-UI zum Standard wird.

Neuerungen zur GitLab Duo Agent Platform

Security Analyst Agent: Von manueller Vulnerability-Triage zu intelligenter Automatisierung

Der GitLab Duo Security Analyst Agent automatisiert Vulnerability-Management-Workflows durch KI-gestützte Analyse und verwandelt stundenlanges manuelles Triaging in intelligente Automatisierung. Aufbauend auf den Vulnerability Management Tools, die über GitLab Duo Agentic Chat verfügbar sind, orchestriert der Security Analyst Agent mehrere Tools, wendet Sicherheitsrichtlinien an und erstellt automatisch benutzerdefinierte Flows für wiederkehrende Workflows.

Sicherheitsteams erhalten Zugriff auf angereicherte Vulnerability-Daten, einschließlich CVE-Details, statischer Erreichbarkeitsanalyse und Informationen zum Code-Fluss. Sie können Operationen wie das Verwerfen von Fehlalarmen, das Bestätigen von Bedrohungen, das Anpassen von Schweregraden und das Erstellen verknüpfter Issues zur Behebung ausführen: alles über Conversational AI. Der Agent reduziert repetitives Klicken durch Vulnerability-Dashboards und ersetzt Custom Scripts durch einfache Befehle in natürlicher Sprache.

Beispiel: Wenn ein Security-Scan Dutzende Schwachstellen aufdeckt, genügt der Prompt: „Dismiss vulnerabilities with reachable=FALSE and create issues for critical findings." Der Security Analyst Agent analysiert Erreichbarkeitsdaten, wendet Sicherheitsrichtlinien an und erledigt Massenoperationen in Momenten – Arbeit, die sonst Stunden dauern würde.

Während einzelne Vulnerability Management Tools direkt über Agentic Chat für spezifische Aufgaben zugänglich sind, orchestriert der Security Analyst Agent diese Tools intelligent und automatisiert komplexe mehrstufige Workflows. Die Vulnerability Management Tools sind über Agentic Chat auf GitLab Self-managed und GitLab.com verfügbar, der Security Analyst Agent ist in 18.5 nur auf GitLab.com verfügbar. Die Verfügbarkeit in Self-managed- und Dedicated-Umgebungen folgt mit dem nächsten Release. Demo ansehen:

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1128975984?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.5 Security Demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

GitLab Duo Planner: Von Backlog-Chaos zu strategischer Klarheit

Die Verwaltung komplexer Software-Delivery erfordert ständige Kontextwechsel zwischen Planungsaufgaben. GitLab Duo Planner adressiert die realen Planungsherausforderungen, mit denen Teams täglich konfrontiert sind. Duo Planner agiert als Teammitglied mit Bewusstsein für den Projektkontext. Er versteht, wie Issues, Epics und Merge Requests verwaltet werden. Anders als generische KI-Assistenten ist er speziell konzipiert mit tiefem Wissen über GitLabs Planungs-Workflows, kombiniert mit Agile- und Priorisierungs-Frameworks, um Aufwand, Risiko und strategische Ausrichtung auszubalancieren.

GitLab Duo Planner kann vage Ideen in strukturierte Planungshierarchien verwandeln, veraltete Backlog-Items identifizieren und Executive Updates entwerfen. Beispiel: Beim Verfeinern eines Backlogs mit Hunderten über Monate angesammelten Issues genügt der Prompt: „Identify stale backlog items and suggest priorities." Innerhalb von Sekunden erhält man eine strukturierte Zusammenfassung mit Issues ohne aktuelle Aktivität, Items mit fehlenden Details, doppelter Arbeit und empfohlenen Prioritäten basierend auf Labels und Milestones – komplett mit umsetzbaren Empfehlungen.

Für Teams, die komplexe Roadmaps verwalten, zielt der Planner darauf ab, Stunden manueller Analyse und Kontextwechsel zu eliminieren und Product Managern sowie Engineering Leads zu helfen, schnellere und besser informierte Entscheidungen zu treffen. Ab 18.5 ist GitLab Duo Planner aktuell schreibgeschützt, das heißt, er kann analysieren, planen und vorschlagen, aber noch keine direkten Aktionen zur Änderung ausführen. Weitere Informationen in der Dokumentation.

Extensible Agent Catalog: Beliebte KI-Tools als native GitLab-Agenten

GitLab 18.5 führt beliebte KI-Agenten direkt in den AI Catalog ein und macht externe Tools wie Claude, OpenAI Codex, Google Gemini CLI, Amazon Q Developer und OpenCode als native GitLab-Agenten verfügbar. Nutzer können diese Agenten nun über dieselbe einheitliche Catalog-Oberfläche entdecken, konfigurieren und deployen, die auch für GitLabs integrierte Agenten verwendet wird. Foundational Agents werden automatisch über Organisations-Catalogs hinweg synchronisiert.

Dies eliminiert die Komplexität des manuellen Agent-Setups durch eine grafische Katalog-Oberfläche und behält dabei Sicherheit auf Enterprise-Niveau durch GitLabs Authentifizierungs- und Audit-Systeme bei. GitLab Duo Enterprise Subscriptions enthalten nun die integrierte Nutzung von Claude und Codex innerhalb von GitLab, sodass die bestehende GitLab-Subscription für diese Tools verwendet werden kann, ohne separate API-Keys oder zusätzliches Billing-Setup zu benötigen. Andere Agenten können weiterhin separate Subscriptions und Konfiguration erfordern, während die Integrationspläne finalisiert werden.

Self-hosted GitLab Duo Agent Platform (Beta): Anforderungen an Datensouveränität erfüllen, ohne auf KI-Power zu verzichten

GitLab 18.5 hebt die Self-hosted-Funktionen der GitLab Duo Agent Platform von experimental auf beta und ermöglicht es Organisationen, KI-Agenten und Flows vollständig innerhalb ihrer eigenen Infrastruktur auszuführen – entscheidend für regulierte Branchen und Datensouveränitätsanforderungen. Das Beta-Release umfasst verbesserte Timeout-Konfigurationen und AI-Gateway-Einstellungen und erlaubt Teams, KI-Agenten für Code-Reviews, Bug-Fixes und Feature-Implementierungen zu nutzen, während Sicherheit auf Enterprise-Niveau für sensiblen Code gewährleistet wird.

Intelligentere, schnellere Sicherheit: Echte Risiken priorisieren und Entwickler im Flow halten

GitLab 18.5 führt neue Application-Security-Funktionen ein, die Teams helfen, ausnutzbare Risiken zu fokussieren, Rauschen zu reduzieren und die Software-Supply-Chain-Sicherheit zu stärken. Diese Updates setzen das Commitment fort, Sicherheit direkt in den Entwicklungsprozess zu integrieren – mit Präzision, Geschwindigkeit und Einblicken, ohne den Arbeitsfluss der Entwickler zu unterbrechen.

Statische Erreichbarkeitsanalyse

Mit über 37 000 neuen CVEs allein in diesem Jahr stehen Sicherheitsteams vor einem überwältigenden Volumen an Schwachstellen und haben Schwierigkeiten zu verstehen, welche davon tatsächlich ausnutzbar sind. Die statische Erreichbarkeitsanalyse, jetzt in Limited Availability, bringt Präzision auf Bibliotheksebene, indem sie hilft zu identifizieren, ob verwundbarer Code tatsächlich in der Anwendung aufgerufen wird und nicht nur in Abhängigkeiten vorhanden ist.

In Kombination mit dem kürzlich veröffentlichten Exploit Prediction Scoring System (EPSS) und Known Exploited Vulnerability (KEV) Daten können Sicherheitsteams die Vulnerability-Triage effektiver beschleunigen. So lassen sich echte Risiken priorisieren und die gesamte Sicherheit der Lieferkette stärken. In 18.5 kommt Unterstützung für Java hinzu, neben der bestehenden Unterstützung für Python, JavaScript und TypeScript.

Validierung exponierter Secrets

Genau wie die statische Erreichbarkeitsanalyse Teams hilft, ausnutzbare Schwachstellen aus Open-Source-Abhängigkeiten zu priorisieren, bringen Secret Validity Checks denselben Einblick für exponierte Secrets – aktuell in Beta auf GitLab.com und GitLab Self-Managed verfügbar. Für von GitLab ausgestellte Security-Tokens unterscheidet GitLab automatisch aktive von abgelaufenen Secrets direkt im Vulnerability Report, anstatt manuell zu prüfen, ob ein geleakter Credential oder API-Key aktiv ist. Dies ermöglicht es Sicherheits- und Entwicklungsteams, Remediation-Maßnahmen auf echte Risiken zu fokussieren. Unterstützung für von AWS und GCP ausgestellte Secrets ist für zukünftige Releases geplant.

Benutzerdefinierte Regeln für Advanced SAST

Advanced SAST läuft auf Regeln, die vom hauseigenen Security-Research-Team entwickelt wurden, um maximale Genauigkeit out of the box zu bieten. Einige Teams benötigten jedoch zusätzliche Flexibilität, um die SAST-Engine für ihre spezifische Organisation anzupassen. Mit benutzerdefinierten Regeln für Advanced SAST können AppSec-Teams atomare, musterbasierte Erkennungslogik definieren, um organisationsspezifische Sicherheitsprobleme zu erfassen – etwa das Flaggen verbotener Funktionsaufrufe – während GitLabs kuratiertes Ruleset weiterhin als Baseline dient. Anpassungen werden über einfache TOML-Dateien verwaltet, genau wie andere SAST-Ruleset-Konfigurationen. Diese Regeln unterstützen zwar keine Taint Analysis, bieten Organisationen aber größere Flexibilität für präzise SAST-Ergebnisse.

Advanced SAST: Unterstützung für C und C++

Die Sprachabdeckung für Advanced SAST wird um C und C++ erweitert, die in der Embedded-Systems-Softwareentwicklung weit verbreitet sind. Um das Scannen zu aktivieren, müssen Projekte eine Compilation Database generieren, die Compiler-Befehle und Include-Pfade erfasst, die während Builds verwendet werden. Dies stellt sicher, dass der Scanner Quelldateien präzise parsen und analysieren kann und kontextbewusste Ergebnisse liefert, die Sicherheitsteams helfen, echte Schwachstellen im Entwicklungsprozess zu identifizieren. Die Implementierungsanforderungen für C und C++ erfordern spezifische Konfigurationen, die in der Dokumentation zu finden sind. Advanced SAST C- und C++-Unterstützung sind aktuell in Beta verfügbar.

Diff-basiertes SAST-Scanning

Traditionelle SAST-Scans analysieren mit jedem Commit die gesamte Codebase neu, verlangsamen Pipelines und unterbrechen den Arbeitsfluss der Entwickler. Die Developer Experience ist eine entscheidende Überlegung, die über die Adoption von Application Security Testing entscheiden kann. Diff-basiertes SAST-Scanning zielt darauf ab, Scan-Zeiten zu beschleunigen, indem nur der in einem Merge Request geänderte Code fokussiert wird, redundante Analysen reduziert werden und relevante Ergebnisse angezeigt werden, die mit der Arbeit des Entwicklers verknüpft sind. Durch die Ausrichtung der Scans auf tatsächliche Code-Änderungen liefert GitLab schnelleres, fokussierteres Feedback. So bleiben Entwickler im Flow, während gleichzeitig starke Security-Coverage beibehalten wird.

API-Konfigurationen vereinfachen

API-gesteuerte Workflows bieten Power und Flexibilität, können aber auch unnötige Komplexität für Aufgaben schaffen, die Teams regelmäßig durchführen müssen. Das neue Maven Virtual Registry Interface bringt eine UI-Ebene für diese Operationen.

Maven Virtual Registry Interface

Das neue webbasierte Interface für die Verwaltung von Maven Virtual Registries verwandelt komplexe API-Konfigurationen in visuelle Einfachheit und bietet eine intuitivere Experience für Paket-Administratoren und Plattform-Engineers.

Zuvor konfigurierten und warteten Teams Virtual Registries ausschließlich über API-Aufrufe. Dies machte routinemäßige Wartung zeitaufwändig und erforderte spezialisiertes Plattform-Wissen. Das neue Interface beseitigt diese Barriere und macht alltägliche Aufgaben schneller und einfacher.

Mit diesem Update lassen sich nun:

• Virtual Registries erstellen, um die Konfiguration von Abhängigkeiten zu vereinfachen
• Upstreams erstellen und ordnen, um Performance und Compliance zu verbessern
• Veraltete Cache-Einträge direkt im UI durchsuchen und löschen

Diese visuelle Experience hilft, operativen Overhead zu reduzieren, und bietet Entwicklungsteams klareren Einblick, wie Abhängigkeiten aufgelöst werden, sodass bessere Entscheidungen über Build-Performance und Sicherheitsrichtlinien getroffen werden können.

Demo ansehen:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/CiOZJPhAvaI?si=cYaoR_OIgqFKbyM2" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

<p></p>

Enterprise-Kunden sind eingeladen, am Maven Virtual Registry Beta-Programm teilzunehmen und Feedback zu teilen, um das finale Release mitzugestalten.

KI, die sich an den Workflow anpasst

Dieses Release steht für mehr als neue Funktionen – es geht um Wahlmöglichkeiten und Kontrolle. Walkthrough-Video hier ansehen:

<p></p>

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1128992281?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.5-tech-demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

GitLab Premium- und Ultimate-Nutzer können diese Funktionen ab sofort auf GitLab.com und in Self-managed-Umgebungen verwenden. Die Verfügbarkeit für GitLab Dedicated ist für nächsten Monat geplant.

Die GitLab Duo Agent Platform befindet sich aktuell in der Beta – Beta- und experimentelle Features aktivieren, um zu erleben, wie KI mit vollem Kontext die Art und Weise transformieren kann, wie Teams Software entwickeln. Neu bei GitLab? Kostenlose Testversion starten und entdecken, warum die Zukunft der Entwicklung KI-gestützt, sicher und über die umfassendste DevSecOps-Plattform der Welt orchestriert ist.

Hinweis: Platform-Funktionen in der Beta sind im Rahmen des GitLab-Beta-Programms verfügbar. Sie sind während der Beta-Phase kostenlos nutzbar. Bei allgemeiner Verfügbarkeit werden sie als kostenpflichtige Add-on-Option für die GitLab Duo Agent Platform angeboten.

Mit GitLab auf dem aktuellen Stand bleiben

Um sicherzustellen, dass die neuesten Features, Sicherheitsupdates und Performance-Verbesserungen genutzt werden können, empfiehlt sich, die GitLab-Instanz aktuell zu halten. Die folgenden Ressourcen helfen bei der Planung und Durchführung des Upgrades:

• Upgrade Path Tool – aktuelle Version eingeben und die exakten Upgrade-Schritte für die Instanz anzeigen lassen
• Upgrade-Dokumentation – detaillierte Anleitungen für jede unterstützte Version, einschließlich Anforderungen, Schritt-für-Schritt-Anweisungen und Best Practices

Durch regelmäßige Upgrades profitiert das Team von den neuesten GitLab-Funktionen und bleibt sicher und supportet.

Für Organisationen, die einen Hands-off-Ansatz bevorzugen, bietet sich GitLabs Managed-Maintenance-Service an. Mit Managed Maintenance kann sich das Team auf Innovation konzentrieren, während GitLab-Experten die selbstverwaltete Instanz zuverlässig upgraden, sichern und für DevSecOps bereit halten. Für weitere Informationen den Account Manager kontaktieren.

Dieser Blog-Post enthält „forward‑looking statements" im Sinne von Section 27A des Securities Act von 1933 in der jeweils geltenden Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in diesen Aussagen zum Ausdruck gebrachten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass tatsächliche Ergebnisse oder Entwicklungen wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren finden sich unter der Überschrift „Risk Factors" in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blog-Posts zu aktualisieren oder zu überarbeiten, es sei denn, dies ist gesetzlich vorgeschrieben.

Die Ausgangssituation

Dutzende Streamlit-Anwendungen in verschiedenen Umgebungen, unterschiedliche Python-Versionen, inkonsistente Sicherheitspraktiken beim Zugriff auf sensible Daten. Manche Anwendungen funktionieren, andere versagen ohne nachvollziehbaren Grund. Niemand weiß, wer welche Anwendung erstellt hat oder wie sie zu warten ist.

Genau vor dieser Situation stand unser Data Team. Anwendungen entstanden isoliert, ohne Standardisierung, ohne Security-Oversight, ohne klaren Deployment-Prozess. Das Ergebnis: ein Compliance-Risiko und eine Wartungslast, die exponentiell wuchs.

Für Unternehmen mit regulatorischen Anforderungen (DSGVO, Branchenstandards) stellt diese dezentrale Infrastruktur ein systematisches Governance-Problem dar. Audit-Trails fehlen, Zugriffskontrollen sind inkonsistent, und nachträgliche Compliance-Implementierung verursacht erhebliche Kosten. Der hier beschriebene Ansatz zeigt, wie frühe Governance-Implementierung diese Risiken vermeidet.

<p></p>

<center><i>Funktionale Architektur (High-Level-Übersicht)</i></center>

Der methodische Ansatz

Als "Customer Zero" haben wir das gesamte Framework auf GitLabs eigener CI/CD-Infrastruktur und den Projekt-Management-Tools aufgebaut. Die Grundkomponenten:

1. GitLab (Produkt)

2. Snowflake – Single Source of Truth (SSOT) für Data-Warehouse-Aktivitäten

3. Streamlit – Open-Source-Tool für visuelle Anwendungen mit Python-Code

Dies ermöglichte direkten Zugriff auf Enterprise-DevSecOps-Funktionen: automatisierte Tests, Code-Review-Prozesse und Deployment-Pipelines von Beginn an. Durch GitLabs integrierte Features für Issue-Tracking, Merge-Requests und automatisierte Deployments (CI/CD-Pipelines) konnten wir schnell iterieren und das Framework gegen reale Enterprise-Anforderungen validieren. Dieser Internal-First-Ansatz stellte sicher, dass die Lösung im Produktiveinsatz bei GitLab selbst validiert wurde.

Erkenntnisse aus der Implementierung

Die wichtigste Erkenntnis beim Aufbau des Streamlit Application Framework in Snowflake: Struktur schlägt Chaos systematisch – Governance früh implementieren, nicht nachträglich, wenn die Wartungskosten exponentiell steigen.

Rollen und Verantwortlichkeiten müssen klar definiert sein. Infrastruktur-Concerns werden von Application Development getrennt, sodass jedes Team sich auf seine Stärken konzentrieren kann.

Security und Compliance können keine Nachgedanken sein. Sie müssen von Tag eins in Templates und automatisierte Prozesse integriert werden. Konsistente Standards vorab durchzusetzen ist wesentlich effizienter als nachträgliche Implementierung. Investitionen in Automatisierung und CI/CD-Pipelines zahlen sich aus, da manuelle Prozesse nicht skalieren und menschliche Fehler einführen.

<p></p>

<center><i>Framework-Architektur (Gesamtübersicht)</i></center>

Das Streamlit Application Framework

Das Framework verwandelt dezentrale Ansätze in eine strukturierte Lösung. Entwicklungsteams erhalten Freiheit innerhalb sicherer Leitplanken, während Deployment automatisiert und Wartungskomplexität eliminiert wird.

Drei Rollen, ein einheitlicher Prozess

Das Framework führt einen strukturierten Ansatz mit drei klar getrennten Rollen ein:

1. Maintainers (Data-Team-Mitglieder und Contributors) verwalten die Infrastruktur: CI/CD-Pipelines, Security-Templates und Compliance-Regeln. Sie stellen sicher, dass das Framework funktioniert und sicher bleibt.

2. Creators (Anwendungsentwicklungsteams) konzentrieren sich auf ihre Kernkompetenzen: Visualisierungen erstellen, Snowflake-Daten einbinden, User Experiences gestalten. Volle Flexibilität beim Erstellen neuer Anwendungen von Grund auf, beim Hinzufügen neuer Pages zu bestehenden Apps, beim Integrieren zusätzlicher Python-Libraries und beim Bauen komplexer Datenvisualisierungen, ohne Beschäftigung mit Deployment-Pipelines oder Security-Konfigurationen.

3. Viewers (Endnutzer) greifen auf fertige, sichere Anwendungen zu, ohne technischen Overhead. Benötigt wird lediglich Snowflake-Zugriff.

<p></p>

<center><i>Rollen-Übersicht und ihre Funktionen</i></center>

Vollständige Automatisierung

Durch CI/CD-Implementierung gehören tagelange manuelle Deployments und Konfigurationsaufwand der Vergangenheit an. Das Framework bietet:

• Umgebungsvorbereitung per Kommando: Mit make-Befehlen ist die Umgebung in wenigen Sekunden installiert und einsatzbereit.

================================================================================
✅ Snowflake CLI successfully installed and configured!
Connection: gitlab_streamlit
User: YOU@GITLAB.COM
Account: gitlab
================================================================================
Using virtualenv: /Users/YOU/repos/streamlit/.venv
📚 Installing project dependencies...
Installing dependencies from lock file
No dependencies to install or update
✅ Streamlit environment prepared!

• Automatisierte CI/CD-Pipelines: Übernehmen Testing, Code-Review und Deployment von Development bis Production.

• Sichere Sandbox-Umgebungen: Ermöglichen sichere Entwicklung und Tests vor Production-Deployment.

╰─$ make streamlit-rules
🔍 Running Streamlit compliance check...
================================================================================
CODE COMPLIANCE REPORT
================================================================================
Generated: 2025-07-09 14:01:16
Files checked: 1

SUMMARY:
✅ Passed: 1
❌ Failed: 0
Success Rate: 100.0%

APPLICATION COMPLIANCE SUMMARY:
📱 Total Applications Checked: 1
⚠️ Applications with Issues: 0
📊 File Compliance Rate: 100.0%

DETAILED RESULTS BY APPLICATION:
...

• Template-basierte Anwendungserstellung: Gewährleistet Konsistenz über alle Anwendungen und Pages hinweg.

╰─$ make streamlit-new-page STREAMLIT_APP=sales_dashboard STREAMLIT_PAGE_NAME=analytics
📝 Generating new Streamlit page: analytics for app: sales_dashboard
📃 Create new page from template:
Page name: analytics
App directory: sales_dashboard
Template path: page_template.py
✅ Successfully created 'analytics.py' in 'sales_dashboard' directory from template

• Poetry-basiertes Dependency-Management: Verhindert Versionskonflikte und erhält saubere Umgebungen.

• Organisierte Projektstruktur: Dedizierte Ordner für Anwendungen, Templates, Compliance-Regeln und Configuration-Management.

├── src/
│   ├── applications/     # Ordner für Streamlit-Anwendungen
│   │   ├── main_app/     # Main-Dashboard-Anwendung
│   │   ├── components/   # Gemeinsam genutzte Komponenten
│   │   └── <your_apps>/  # Eigene Anwendungen
│   │   └── <your_apps2>/ # Weitere Anwendungen
│   ├── templates/        # Anwendungs- und Page-Templates
│   ├── compliance/       # Compliance-Regeln und -Checks
│   └── setup/            # Setup- und Konfigurations-Utilities
├── tests/                # Test-Dateien
├── config.yml            # Umgebungskonfiguration
├── Makefile              # Build- und Deployment-Automatisierung
└── README.md             # Haupt-README-Datei

• Optimierter Workflow: Von lokaler Entwicklung über Test-Schema bis Production, vollständig automatisiert durch GitLab CI/CD-Pipelines.

<p></p> <center><i>GitLab CI/CD-Pipelines für vollständige Prozessautomatisierung</i></center>

Security und Compliance by Design

Statt Security nachträglich hinzuzufügen, baut das Streamlit Application Framework sie von Grund auf ein. Jede Anwendung folgt denselben Security-Standards, Compliance-Anforderungen werden automatisch durchgesetzt. Audit-Trails werden über den gesamten Development-Lifecycle gepflegt.

Compliance-Regeln werden mit einem einzigen Kommando eingeführt und verifiziert. Beispielsweise lassen sich definieren, welche Klassen und Methoden verpflichtend sind, welche Dateien vorhanden sein müssen und welche Rollen für das Teilen der Anwendung erlaubt oder verboten sind. Die Regeln sind flexibel und beschreibend – Definition erfolgt in einer YAML-Datei:

class_rules:
  - name: "Inherit code for the page from GitLabDataStreamlitInit"
    description: "All Streamlit apps must inherit from GitLabDataStreamlitInit"
    severity: "error"
    required: true
    class_name: "*"
    required_base_classes:
      - "GitLabDataStreamlitInit"
    required_methods:
      - "__init__"
      - "set_page_layout"
      - "setup_ui"
      - "run"

function_rules:
  - name: "Main function required"
    description: "Must have a main() function"
    severity: "error"
    required: true
    function_name: "main"

import_rules:
  - name: "Import GitLabDataStreamlitInit"
    description: "Must import the mandatory base class"
    severity: "error"
    required: true
    module_name: "gitlab_data_streamlit_init"
    required_items:
      - "GitLabDataStreamlitInit"
  - name: "Import streamlit"
    description: "Must import streamlit library"
    severity: "error"
    required: true
    module_name: "streamlit"

file_rules:
  - name: "Snowflake configuration required (snowflake.yml)"
    description: "Each application must have a snowflake.yml configuration file"
    severity: "error"
    required: true
    file_pattern: "**/applications/**/snowflake.yml"
    base_path: ""
  - name: "Snowflake environment required (environment.yml)"
    description: "Each application must have a environment.yml configuration file"
    severity: "error"
    required: true
    file_pattern: "**/applications/**/environment.yml"
    base_path: ""
  - name: "Share specification required (share.yml)"
    description: "Each application must have a share.yml file"
    severity: "warning"
    required: true
    file_pattern: "**/applications/**/share.yml"
    base_path: ""
  - name: "README.md required (README.md)"
    description: "Each application should have a README.md file with a proper documentation"
    severity: "error"
    required: true
    file_pattern: "**/applications/**/README.md"
    base_path: ""
  - name: "Starting point recommended (dashboard.py)"
    description: "Each application must have a dashboard.py as a starting point"
    severity: "warning"
    required: true
    file_pattern: "**/applications/**/dashboard.py"
    base_path: ""

sql_rules:
  - name: "SQL files must contain only SELECT statements"
    description: "SQL files and SQL code in other files should only contain SELECT statements for data safety"
    severity: "error"
    required: true
    file_extensions: [".sql", ".py"]
    select_only: true
    forbidden_statements:
      - ....
    case_sensitive: false
  - name: "SQL queries should include proper SELECT statements"
    description: "When SQL is present, it should contain proper SELECT statements"
    severity: "warning"
    required: false
    file_extensions: [".sql", ".py"]
    required_statements:
      - "SELECT"
    case_sensitive: false

share_rules:
  - name: "Valid functional roles in share.yml"
    description: "Share.yml files must contain only valid functional roles from the approved list"
    severity: "error"
    required: true
    file_pattern: "**/applications/**/share.yml"
    valid_roles:
      - ...
    safe_data_roles:
      - ...
  - name: "Share.yml file format validation"
    description: "Share.yml files must follow the correct YAML format structure"
    severity: "error"
    required: true
    file_pattern: "**/applications/**/share.yml"
    required_keys:
      - "share"
    min_roles: 1
    max_roles: 10

Mit einem einzigen Kommando:

╰─$ make streamlit-rules

lassen sich alle erstellten Regeln verifizieren und validieren, dass Entwicklungsteams (die eine Streamlit-Anwendung erstellen) die von den Creators (die Policies und Building Blocks des Frameworks festlegen) spezifizierten Richtlinien befolgen und alle Building Blocks an der richtigen Stelle sind. Dies gewährleistet konsistentes Verhalten über alle Streamlit-Anwendungen hinweg.

🔍 Running Streamlit compliance check...
================================================================================
CODE COMPLIANCE REPORT
================================================================================
Generated: 2025-08-18 17:05:12
Files checked: 4

SUMMARY:
✅ Passed: 4
❌ Failed: 0
Success Rate: 100.0%

APPLICATION COMPLIANCE SUMMARY:
📱 Total Applications Checked: 1
⚠️ Applications with Issues: 0
📊 File Compliance Rate: 100.0%

DETAILED RESULTS BY APPLICATION:
================================================================================
✅ PASS APPLICATION: main_app
------------------------------------------------------------
📁 FILES ANALYZED (4):
✅ dashboard.py
📦 Classes: SnowflakeConnectionTester
🔧 Functions: main
📥 Imports: os, pwd, gitlab_data_streamlit_init, snowflake.snowpark.exceptions, streamlit

✅ show_streamlit_apps.py
📦 Classes: ShowStreamlitApps
🔧 Functions: main
📥 Imports: pandas, gitlab_data_streamlit_init, snowflake_session, streamlit

✅ available_packages.py
📦 Classes: AvailablePackages
🔧 Functions: main
📥 Imports: pandas, gitlab_data_streamlit_init, streamlit

✅ share.yml
👥 Share Roles: snowflake_analyst_safe

📄 FILE COMPLIANCE FOR MAIN_APP:
✅ Required files found:
✓ snowflake.yml
✓ environment.yml
✓ share.yml
✓ README.md
✓ dashboard.py

RULES CHECKED:
----------------------------------------
Class Rules (1):
- Inherit code for the page from GitLabDataStreamlitInit (error)

Function Rules (1):
- Main function required (error)

Import Rules (2):
- Import GitLabDataStreamlitInit (error)
- Import streamlit (error)

File Rules (5):
- Snowflake configuration required (snowflake.yml) (error)
- Snowflake environment required (environment.yml) (error)
- Share specification required (share.yml) (warning)
- README.md required (README.md) (error)
- Starting point recommended (dashboard.py) (warning)

SQL Rules (2):
- SQL files must contain only SELECT statements (error)
🗄 SELECT-only mode enabled
🚨 Forbidden: INSERT, UPDATE, DELETE, DROP, ALTER...
- SQL queries should include proper SELECT statements (warning)

Share Rules (2):
- Valid functional roles in share.yml (error)
👥 Valid roles: 15 roles defined
🔒 Safe data roles: 11 roles
- Share.yml file format validation (error)
------------------------------------------------------------
✅ Compliance check passed
-----------------------------------------------------------

Developer Experience

Ob bevorzugte IDE, webbasierte Entwicklungsumgebung oder Snowflake Snowsight – die Experience bleibt konsistent. Das Framework bietet:

• Template-basierte Entwicklung: Neue Anwendungen und Pages werden über standardisierte Templates erstellt, was Konsistenz und Best Practices von Tag eins sicherstellt. Keine verstreuten Designs und Elemente mehr.

╰─$ make streamlit-new-app NAME=sales_dashboard
🔧 Configuration Environment: TEST
📝 Configuration File: config.yml
📜 Config Loader Script: ./setup/get_config.sh
🐍 Python Version: 3.12
📁 Applications Directory: ./src/applications
🗄 Database: ...
📊 Schema: ...
🏗 Stage: ...
🏭 Warehouse: ...
🆕 Creating new Streamlit app: sales_dashboard
Initialized the new project in ./src/applications/sales_dashboard

• Poetry Package Management: Alle Dependencies werden über Poetry verwaltet, was isolierte Umgebungen schafft, die bestehende Python-Setups nicht stören.

[tool.poetry]
name = "GitLab Data Streamlit"
version = "0.1.1"
description = "GitLab Data Team Streamlit project"
authors = ["GitLab Data Team <*****@gitlab.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = "<3.13,>=3.12"
snowflake-snowpark-python = "==1.32.0"
snowflake-connector-python = {extras = ["development", "pandas", "secure-local-storage"], version = "^3.15.0"}
streamlit = "==1.22.0"
watchdog = "^6.0.0"
types-toml = "^0.10.8.20240310"
pytest = "==7.0.0"
black = "==25.1.0"
importlib-metadata = "==4.13.0"
pyyaml = "==6.0.2"
python-qualiter = "*"
ruff = "^0.1.0"
types-pyyaml = "^6.0.12.20250516"
jinja2 = "==3.1.6"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

• Multi-Page-Application-Support: Teams können problemlos komplexe Anwendungen mit mehreren Pages erstellen und neue Libraries nach Bedarf hinzufügen. Multi-Page-Anwendungen sind Teil des Frameworks – Fokus liegt auf der Logik, nicht auf Design und Strukturierung.

<p></p>

<center><i>Multi-Page-Anwendungsbeispiel (in Snowflake)</i></center>

<p></p>

• Nahtlose Snowflake-Integration: Integrierte Konnektoren und Authentication-Handling für sicheren Datenzugriff bieten dieselbe Experience in lokaler Entwicklung und direkt in Snowflake.

make streamlit-push-test APPLICATION_NAME=sales_dashboard
📤 Deploying Streamlit app to test environment: sales_dashboard
...
------------------------------------------------------------------------------------------------------------
🔗 Running share command for application: sales_dashboard
Running commands to grant shares
🚀 Executing: snow streamlit share sales_dashboard with SOME_NICE_ROLE
✅ Command executed successfully
📊 Execution Summary: 1/1 commands succeeded

• Umfassendes Makefile: Alle gängigen Kommandos sind in einfache Makefile-Befehle verpackt, von lokaler Entwicklung über Testing bis Deployment, inklusive CI/CD-Pipelines.

• Sichere lokale Entwicklung: Alles läuft in isolierten Poetry-Umgebungen, schützt das System und bietet Production-ähnliche Experiences.

<p></p>

<center><i>Konsistente Experience unabhängig von der Umgebung (Beispiel lokale Entwicklung)</i></center>

<p></p>

• Collaboration via Code: Alle Anwendungen und Komponenten sind in einem Repository zusammengefasst, was der gesamten Organisation ermöglicht, an denselben Ressourcen zu kollaborieren und doppelte Arbeit sowie redundante Setups zu vermeiden.

Implementierungsschritte

Bei ähnlichen Herausforderungen mit verstreuten Streamlit-Anwendungen:

1. Bestandsaufnahme: Bestehende Anwendungen inventarisieren und Problembereiche identifizieren.

2. Rollen definieren: Maintainer-Verantwortlichkeiten von Creator- und Endnutzer-Anforderungen trennen.

3. Mit Templates beginnen: Standardisierte Anwendungs-Templates erstellen, die Security- und Compliance-Anforderungen durchsetzen.

4. CI/CD implementieren: Deployment-Pipeline automatisieren, um manuelle Fehler zu reduzieren und Konsistenz sicherzustellen.

<p></p>

<center><i>Die in Snowflake deployte Anwendung</i></center>

Einordnung

Dieses Framework behandelt Daten-Anwendungen als vollwertige Komponenten der Enterprise-Architektur.

Durch die Bereitstellung von Struktur ohne Flexibilitätsverlust hat das GitLab Data Team eine Umgebung geschaffen, in der Teams mit minimalen technischen Vorkenntnissen schnell innovieren können, während höchste Security- und Compliance-Standards gewahrt bleiben.

Ausblick

Wir entwickeln das Framework basierend auf User-Feedback und entstehenden Anforderungen kontinuierlich weiter. Zukünftige Verbesserungen umfassen erweiterte Template-Libraries, verbesserte Monitoring-Funktionen, mehr Flexibilität und eine optimierte User Experience.

Das Ziel: ein Foundation schaffen, das mit den wachsenden Data-Application-Anforderungen der Organisation skaliert.

Weitere technische Details zur Implementierung im englischen Original.

Zusammenfassung

Das GitLab Data Team hat dutzende verstreute, unsichere Streamlit-Anwendungen ohne Standardisierung in ein einheitliches, Enterprise-taugliches Framework mit klarer Rollentrennung überführt:

1. Maintainers verwalten Infrastruktur und Security.

2. Creators konzentrieren sich auf Anwendungsentwicklung ohne Deployment-Overhead.

3. Viewers greifen auf fertige, compliance-konforme Apps zu.

Die verwendeten Building Blocks:

1. Automatisierte CI/CD-Pipelines

2. Vollständig kollaborativer und versionierter Code in git

3. Template-basierte Entwicklung

4. Integrierte Security-Compliance und Testing

5. Poetry-verwaltete Umgebungen

Wir haben den Wartungs-Overhead eliminiert und gleichzeitig schnelle Innovation ermöglicht – der Beweis, dass Struktur und Flexibilität vereinbar sind, wenn Data Applications als vollwertige Enterprise-Assets behandelt werden, nicht als Wegwerf-Prototypen.

Um ein realistisches Bild dieser Entwicklung gewinnen zu können, hat GitLab zusammen mit The Harris Poll in einer aktuellen Studie 252 deutsche C-Level-Führungskräfte aus verschiedenen Branchen zur Rolle von Software-Innovationen für den Geschäftserfolg befragt. „Software-Innovation“ wird dabei als „die Entwicklung neuer Software oder die deutliche Verbesserung bestehender Software, um neue Funktionen einzuführen, die Effizienz zu steigern oder Probleme auf neue Weise zu lösen“ definiert.

Den vollständigen Report für C-Level-Führungskräfte in Deutschland findest du hier.

Kennzahlen unserer Studie

KI-gestützte Softwareinnovationen werden zum Wachstumsmotor der deutschen Wirtschaft

• Führungskräfte in Deutschland sehen Software-Innovation als entscheidenden Faktor für Wettbewerbsfähigkeit und wirtschaftliches Wachstum: 90 % geben an, dass Software-Innovation heute eine zentrale Geschäftspriorität ist, 85 % haben ihre Investitionen in Softwareentwicklung im vergangenen Jahr erhöht.
• Unternehmen berichten, dass der Einsatz von KI in der Softwareentwicklung bereits zu einem Umsatzwachstum von durchschnittlich 43 % und zu einer Produktivitätssteigerung von 46 % geführt hat.
• Software-Innovationen werden zunehmend als strategische Investition betrachtet, nicht als Kostenfaktor: 83 % der befragten Führungskräfte wären bereit, mehr als die Hälfte ihres jährlichen IT-Budgets in Software-Innovationen zu investieren.

Agentic AI gewinnt an Dynamik – Vertrauen und Governance bleiben zentrale Themen

• 89 % der deutschen Führungskräfte erwarten, dass Agentic AI (agentische KI) innerhalb von drei Jahren zum Standard in der Softwareentwicklung wird.
• Gleichzeitig sehen 80 % neue Sicherheitsherausforderungen und fordern, dass Governance und Vertrauen hier Schritt halten.
• Zu den größten Bedenken zählen regulatorische Fragen (48 %), Fehler durch KI-Tools (46 %), Cybersicherheitsrisiken (46 %), Ethik und Transparenz (44 %) sowie Datenschutz und Sicherheit (42 %).
• Um diesen Herausforderungen zu begegnen, implementieren Unternehmen neue Strukturen: 52 % haben interne Richtlinien eingeführt, 50 % setzen Ethikkommissionen ein, 48 % passen ihre Prozesse an gesetzliche Vorgaben an und 46 % führen Pilotprogramme oder Schulungen durch.

Weiterbildung wird zum Schlüssel im Zeitalter der KI

• Neben dem Fachkräftemangel sind Qualifikationslücken mittlerweile das größte Investitionshindernis: 99 % der Führungskräfte betonen den Wert des menschlichen Beitrags in der Softwareentwicklung – 88 % sagen, dass Unternehmen gezielt in die Schulung von Mitarbeitenden investieren müssen, um Qualifikationslücken zu schließen.
• Im Durchschnitt liegt die aktuelle Aufteilung zwischen menschlichem Input und KI bei 75 zu 25. Ideal wäre für die Mehrheit ein ausgewogenes Verhältnis von 50 zu 50.
• Besonders geschätzt werden Fähigkeiten wie Zusammenarbeit (42 %), strategische Weitsicht (36 %) und Kommunikation (34 %), die für kreative und verantwortungsvolle Softwareentwicklung unverzichtbar bleiben.

Software-Innovation im Vorstand angekommen – messbare Ergebnisse als Maßstab

• 9 von 10 Führungskräften bestätigen, dass ihr Vorstand von den Vorteilen der Software-Innovation überzeugt ist.
• 88 % geben an, dass ihr Unternehmen bereits über ein Framework verfügt, das Softwareaktivitäten mit konkreten Geschäftsergebnissen verknüpft.
• 98 % messen den ROI ihrer Software-Investitionen bereits heute, wobei geschäftsorientierte Metriken wie Umsatzwachstum, Produktivität und Wettbewerbsvorteil im Vordergrund stehen.
• Darüber hinaus berichten 92 % der Befragten, dass sich Investitionen in KI innerhalb von weniger als zwei Jahren amortisieren.

Software-Innovation entscheidet über die Wettbewerbsfähigkeit der Zukunft

Der Report zeigt, dass Führungskräfte erkennen, wie KI-gestützte Softwareentwicklung nicht nur die Effizienz steigert, sondern zunehmend auch den Unternehmenserfolg bestimmt. Gleichzeitig wird deutlich, wie anspruchsvoll dieser Wandel ist. KI bringt nachweislich messbare Ergebnisse – mehr Umsatz, höhere Produktivität, schnellere Markteinführungen –, doch sie verändert auch Rollen, Kompetenzen und Verantwortlichkeiten. Deutsche Führungskräfte sehen in der Zusammenarbeit zwischen Mensch und KI die größte Chance. Doch obwohl man ein ausgewogenes Verhältnis anstrebt, dominiert aktuell noch menschliche Arbeit. Langfristiger Erfolg erfordert dabei mehr als technologische Investitionen: Weiterbildung, Governance und Vertrauen in KI werden zur Voraussetzung, um das wirtschaftliche Potenzial von Software-Innovationen voll auszuschöpfen.

Wenn man es also schafft, im Feld der Software-Innovation strategisch vorzugehen und Entwicklungen nutzt, lässt sich für den Wirtschaftsstandort Deutschland ein Milliardenpotenzial heben.

Lade den vollständigen Report für C-Level-Führungskräfte in Deutschland jetzt herunter.

Für deutsche Unternehmen besonders relevant: Diese Konfigurationsoptimierungen reduzieren Infrastructure-Kosten durch geringere Egress-Gebühren und Serverlast. Die systematische Trennung von Komponenten ermöglicht zudem granulare Zugriffskontrolle und vereinfachtes Cost Tracking – beispielsweise für Enterprise-Umgebungen mit Compliance-Anforderungen.

Consolidated Form für GitLab-Komponenten verwenden

Für Artifacts, LFS, Uploads, Packages und weitere GitLab-Daten eliminiert die Consolidated Form die Credential-Duplizierung:

gitlab_rails['object_store']['enabled'] = true

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'use_iam_profile' => true
}

gitlab_rails['object_store']['objects']['artifacts']['bucket'] = 'gitlab-artifacts'

gitlab_rails['object_store']['objects']['lfs']['bucket'] = 'gitlab-lfs'

# ... additional buckets for each object type

Diese Konfiguration reduziert die Komplexität und ermöglicht gleichzeitig verschlüsselte S3-Buckets sowie korrekte Content-MD5-Header.

Container Registry separat konfigurieren

Die Container Registry benötigt eine eigene Konfiguration, da sie die Consolidated Form nicht unterstützt:

registry['storage'] = {
  's3_v2' => {  # Den neuen v2-Treiber verwenden
    'bucket' => 'gitlab-registry',
    'region' => 'us-east-1',
    # Access Keys weglassen für IAM-Rolle
  }
}

Hinweis: Der s3_v1-Treiber ist deprecated und wird in GitLab 19.0 entfernt. Eine Migration zu s3_v2 verbessert Performance und Zuverlässigkeit.

Proxy Download für Performance deaktivieren

proxy_download auf false (Standard) setzen für direkte Downloads:

# Für GitLab-Objekte - global konfigurierbar

gitlab_rails['object_store']['proxy_download'] = false

# Oder granular pro Bucket

gitlab_rails['object_store']['objects']['artifacts']['proxy_download'] = false

gitlab_rails['object_store']['objects']['lfs']['proxy_download'] = false

gitlab_rails['object_store']['objects']['uploads']['proxy_download'] = true  # Beispiel: Proxy für Uploads beibehalten

# Container Registry nutzt standardmäßig Redirect Mode (direkte Downloads)

# Nur bei Bedarf deaktivieren:

registry['storage']['redirect']['disable'] = false  # Auf false belassen

Wichtig: Die proxy_download-Option kann global auf Object-Store-Ebene oder individuell pro Bucket konfiguriert werden. Das ermöglicht Optimierung nach spezifischem Use Case – beispielsweise direkte Downloads für große Artifacts und LFS-Files, aber Proxy für kleinere Uploads mit zusätzlichen Security-Kontrollen.

Diese Konfiguration reduziert die Serverlast und Egress-Kosten erheblich, indem Clients direkt vom Object Storage herunterladen.

Identity-basierte Authentifizierung nutzen

AWS: IAM-Rollen statt Access Keys verwenden:

# GitLab-Objekte

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'use_iam_profile' => true
}

# Container Registry

registry['storage'] = {
  's3_v2' => {
    'bucket' => 'gitlab-registry',
    'region' => 'us-east-1'
    # Keine Access Keys = IAM-Role-Authentifizierung
  }
}

Google Cloud Platform: Application Default Credentials aktivieren:

gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_application_default' => true
}

Azure: Workload Identities durch Weglassen der Storage Access Keys nutzen.

Verschlüsselungsebenen hinzufügen

Server-side Encryption für zusätzliche Sicherheit aktivieren:

# GitLab-Objekte

gitlab_rails['object_store']['storage_options'] = {
  'server_side_encryption' => 'AES256'
}

# Container Registry

registry['storage'] = {
  's3_v2' => {
    'bucket' => 'gitlab-registry',
    'encrypt' => true
  }
}

Für AWS KMS Encryption den Key-ARN in server_side_encryption_kms_key_id angeben.

Separate Buckets für Organisation verwenden

Dedizierte Buckets für jede Komponente erstellen:

• gitlab-artifacts - CI/CD Job Artifacts

• gitlab-lfs - Git LFS Objects

• gitlab-uploads - User Uploads

• gitlab-packages - Package Registry

• gitlab-registry - Container Images

Diese Isolation verbessert die Sicherheit, ermöglicht granulare Zugriffskontrolle und vereinfacht Cost Tracking.

Zentrale Konfigurations-Unterschiede

Migrationspfad

1. Mit GitLab-Objekten beginnen: Consolidated Form für sofortige Komplexitätsreduktion nutzen.

2. Registry separat konfigurieren: s3_v2-Treiber mit IAM-Authentifizierung verwenden.

3. Verschlüsselung aktivieren: Server-side Encryption für beide Komponenten hinzufügen.

4. Performance optimieren: Direkte Downloads mit entsprechenden proxy_download-Einstellungen sicherstellen.

5. Lifecycle Policies einrichten: S3 Lifecycle Rules für unvollständige Multipart-Uploads konfigurieren.

Weitere Ressourcen

Ein vollständiges AWS S3 Konfigurationsbeispiel finden Sie in der GitLab-Dokumentation zum AWS S3 Object Storage Setup.

Details zur Konfiguration von proxy_download-Parametern pro Bucket enthält die GitLab Object Storage Configuration Documentation.

Diese Konfigurationen skalieren mit Ihrem Wachstum und wahren gleichzeitig Sicherheit und Performance. Die Trennung zwischen GitLab Object Storage und Container Registry Configuration spiegelt unterschiedliche zugrunde liegende Architekturen wider – beide profitieren jedoch von denselben Optimierungsprinzipien.

Für deutsche Entwicklungsteams sind LLMs besonders relevant, da sie repetitive Aufgaben automatisieren und die Einhaltung von Compliance-Anforderungen unterstützen können – beispielsweise in regulierten Branchen wie Finanzdienstleistungen oder der Automobilindustrie.

Was ist ein LLM?

LLMs sind KI-Systeme (Künstliche Intelligenz), die autonom Text verarbeiten und generieren können. Sie werden trainiert, indem sie große Datenmengen aus verschiedenen Quellen analysieren, wodurch sie linguistische Strukturen, kontextuelle Beziehungen und sprachliche Nuancen beherrschen.

LLMs stellen einen bedeutenden Fortschritt im KI-Bereich dar. Ihre Fähigkeit, Text zu verarbeiten, zu generieren und zu interpretieren, basiert auf ausgereiften Machine-Learning- und Natural-Language-Processing-Techniken (NLP). Diese Systeme verarbeiten nicht nur einzelne Wörter, sondern analysieren komplexe Sequenzen, um die Gesamtbedeutung, subtile Kontexte und linguistische Nuancen zu erfassen.

Wie funktionieren LLMs?

Um besser zu verstehen, wie sie funktionieren, betrachten wir einige Schlüsseleigenschaften von Large Language Models.

Supervised und Unsupervised Learning

LLMs werden mit zwei komplementären Ansätzen trainiert: Supervised Learning und Unsupervised Learning. Diese beiden Machine-Learning-Ansätze maximieren ihre Fähigkeit, Text zu analysieren und zu generieren.

• Supervised Learning basiert auf gelabelten Daten, bei denen jeder Input mit einem erwarteten Output verknüpft ist. Das Modell lernt, diese Inputs mit den korrekten Outputs zu assoziieren, indem es seine internen Parameter anpasst, um Vorhersagefehler zu reduzieren. Durch diesen Ansatz erwirbt das Modell präzises Wissen über spezifische Aufgaben wie Textklassifikation oder Named Entity Recognition.

• Unsupervised Learning (oder maschinelles Lernen) benötigt hingegen keine gelabelten Daten. Das Modell erkundet große Textmengen, um versteckte Strukturen zu entdecken und semantische Beziehungen zu identifizieren. Das Modell kann daher wiederkehrende Muster, implizite grammatikalische Regeln im Text und die Kontextualisierung von Sätzen und Konzepten lernen. Diese Methode ermöglicht es, LLMs auf großen Datenkorpora zu trainieren, was ihren Fortschritt ohne direkte menschliche Intervention erheblich beschleunigt.

  Durch die Kombination dieser beiden Ansätze gewinnen Large Language Models die Vorteile sowohl präzisen, menschlich geführten Lernens als auch unbegrenzter autonomer Exploration. Diese Komplementarität ermöglicht es ihnen, sich schnell zu entwickeln und gleichzeitig ihre Fähigkeit zu verbessern, Text kohärent und kontextuell zu verstehen und zu generieren.

Training auf großen Datenmengen

LLMs werden auf Milliarden von Sätzen aus verschiedenen Quellen trainiert, wie Nachrichtenartikeln, Online-Foren, technischer Dokumentation, wissenschaftlichen Studien und mehr. Diese Quellenvielfalt ermöglicht es ihnen, ein breites und nuanciertes Verständnis natürlicher Sprache zu erwerben, das von alltäglichen Ausdrücken bis zu Fachterminologie reicht.

Der Reichtum der verwendeten Daten ist ein Schlüsselfaktor für die Leistung von LLMs. Jede Quelle bringt unterschiedliche Schreibstile, kulturelle Kontexte und technische Niveaus mit sich. Zum Beispiel:

• Nachrichtenartikel, um informative und faktische Sprache zu beherrschen
• Online-Foren, um informelle Unterhaltungen und Fachsprache spezialisierter Communities zu verstehen
• Technische Dokumentation und wissenschaftliche Studien, um komplexe Konzepte und spezifische Terminologie zu assimilieren, besonders in Bereichen wie DevOps und DevSecOps Diese Inhaltsvielfalt ermöglicht es LLMs, komplexe linguistische Strukturen zu erkennen, Sätze in verschiedenen Kontexten zu interpretieren und sich an hochgradig technische Domänen anzupassen. In DevSecOps bedeutet dies, Commands, Konfigurationen, Sicherheitsprotokolle und sogar Konzepte im Zusammenhang mit der Entwicklung und Wartung von Computersystemen zu verstehen. Mit diesem groß angelegten Training können LLMs komplexe Fragen präzise beantworten, technische Dokumentation schreiben oder Schwachstellen in Computersystemen identifizieren.

Neuronale Netzwerkarchitektur und Deep Learning

LLMs basieren auf fortgeschrittenen neuronalen Netzwerkarchitekturen. Diese Netzwerke sind speziell darauf ausgelegt, große Textsequenzen zu verarbeiten und dabei ein genaues Verständnis des Kontexts beizubehalten. Dieses auf Deep Learning basierende Training ist ein wichtiger Vorteil im NLP-Bereich. Die bekannteste dieser Strukturen ist die Architektur von Sequence-to-Sequence-Modellen (Transformers). Diese Architektur hat NLP mit ihrer Fähigkeit, alle Teile eines Textes gleichzeitig zu analysieren, grundlegend verändert – im Gegensatz zu sequenziellen Ansätzen, die Wörter einzeln verarbeiten.

Sequence-to-Sequence-Modelle eignen sich hervorragend für die Verarbeitung langer Texte. Beispielsweise können sie in einer Konversation oder einem detaillierten technischen Dokument entfernte Informationen im Text verknüpfen, um präzise und gut begründete Antworten zu produzieren. Dieses Kontextmanagement ist in einem DevSecOps-Ansatz essenziell, wo Anweisungen komplex sein und sich über mehrere Codezeilen oder Konfigurationsschritte erstrecken können.

Prädiktive Textgenerierung

Wenn der Benutzer einen Text, eine Abfrage oder eine Frage einreicht, nutzt ein LLM seine prädiktive Fähigkeit, um die wahrscheinlichste Sequenz basierend auf dem gegebenen Kontext zu generieren. Das Modell analysiert jedes Wort, untersucht grammatikalische und semantische Beziehungen und wählt dann die passendsten Begriffe aus, um einen kohärenten und informativen Text zu produzieren. Dieser Ansatz ermöglicht es, präzise, detaillierte und an den erwarteten Ton angepasste Antworten zu generieren.

In DevSecOps-Umgebungen wird diese Fähigkeit besonders nützlich für:

• Coding-Unterstützung: Generierung von Code-Blöcken oder Scripts, die an spezifische Konfigurationen angepasst sind
• Technische Problemlösung: Lösungsvorschläge basierend auf Beschreibungen von Bugs oder Fehlern
• Erstellung technischer Dokumentation: Automatische Erstellung von Anleitungen, Handbüchern oder Anweisungen Die prädiktive Textgenerierung ermöglicht es somit, viele repetitive Aufgaben zu automatisieren und die Arbeit technischer Teams zu beschleunigen.

Anwendungen von Large Language Models im DevSecOps-Ansatz

Mit dem Aufstieg der Automatisierung sind LLMs zu unverzichtbaren Unterstützern für technische Teams geworden. Ihre Fähigkeit, Text kontextuell zu verstehen und zu generieren, ermöglicht es ihnen, effektiv in komplexen Umgebungen wie DevSecOps zu arbeiten.

Mit ihrer Analysekraft und Anpassungsfähigkeit an spezifische Bedürfnisse bieten diese Modelle maßgeschneiderte Lösungen, um Prozesse zu straffen und die Arbeitslast technischer Teams zu reduzieren.

Entwicklungsteams können LLMs nutzen, um funktionale Spezifikationen automatisch in Quellcode umzuwandeln.

Mit dieser Fähigkeit können sie folgende Aktionen durchführen:

• Komplexe Automatisierungsskripte generieren
• CI/CD-Pipelines erstellen, die auf spezifische Geschäftsprozesse zugeschnitten sind
• Individuelle Sicherheitspatches produzieren
• Code-Erklärungen generieren und Dokumentation erstellen
• Code refaktorisieren, indem Struktur und Lesbarkeit verbessert werden, ohne die Funktionalität zu ändern
• Tests generieren Durch den Einsatz von LLMs können Teams die Entwicklung ihrer Software beschleunigen und gleichzeitig das Risiko menschlicher Fehler reduzieren.

Verbesserte Dokumentation und Wissensaustausch

Diese leistungsstarken Tools ermöglichen es, maßgeschneiderte Benutzerhandbücher, API-Beschreibungen und Tutorials zu erstellen, die perfekt auf das Expertise-Level jedes Benutzers abgestimmt sind. Durch die Nutzung vorhandener Wissensbasen erstellen LLMs kontextuelle Antworten auf häufig gestellte Fragen. Dies verbessert den Wissensaustausch innerhalb von Teams, beschleunigt das Onboarding neuer Mitglieder und hilft, Best Practices zu zentralisieren.

Incident Management und Troubleshooting

Während eines Incidents spielen LLMs eine entscheidende Rolle bei der Echtzeit-Analyse von Logs und Trace-Dateien. Dank ihrer Fähigkeit, Informationen aus mehreren Quellen zu verknüpfen, identifizieren sie Anomalien und schlagen Lösungen basierend auf ähnlichen vergangenen Incidents vor. Dieser Ansatz reduziert die Diagnosezeit erheblich. Zusätzlich können LLMs die Erstellung detaillierter Incident-Reports automatisieren und spezifische Korrekturmaßnahmen empfehlen.

Erstellung und Verbesserung von CI/CD-Pipelines

LLMs verändern die Konfiguration von CI/CD-Pipelines grundlegend. Sie können nicht nur bei der Erstellung von Pipelines helfen, sondern auch diesen Prozess automatisieren und optimale Konfigurationen basierend auf Industriestandards vorschlagen. Durch die Anpassung von Workflows an spezifische Bedürfnisse gewährleisten sie perfekte Konsistenz zwischen verschiedenen Entwicklungsumgebungen. Automatisierte Tests werden durch relevante Vorschläge verbessert, wodurch das Fehlerrisiko begrenzt wird. LLMs überwachen auch kontinuierlich die Effizienz von Pipelines und passen Prozesse an, um einen reibungslosen und unterbrechungsfreien Rollout sicherzustellen.

Sicherheit und Compliance

In einer DevSecOps-Umgebung werden Large Language Models zu wertvollen Unterstützern für Sicherheit und Compliance. Sie analysieren den Quellcode auf potenzielle Schwachstellen und generieren detaillierte Patch-Empfehlungen. LLMs können auch die Anwendung von Sicherheitsstandards in Echtzeit überwachen, umfassende Compliance-Reports produzieren und die Anwendung von Sicherheitspatches automatisieren, sobald eine Schwachstelle identifiziert wird. Diese Automatisierung erhöht die Gesamtsicherheit und gewährleistet konsistente Compliance mit rechtlichen und branchenspezifischen Anforderungen.

Was sind die Vorteile von Large Language Models?

LLMs gestalten DevOps- und DevSecOps-Ansätze neu und bringen substanzielle Verbesserungen in Produktivität, Sicherheit und Softwarequalität. Durch die Integration in bestehende Workflows verändern LLMs traditionelle Ansätze, indem sie komplexe Aufgaben automatisieren und innovative Lösungen bieten.

Verbesserte Produktivität und Effizienz

LLMs spielen eine zentrale Rolle bei der Verbesserung der Produktivität und Effizienz technischer Teams. Durch die Automatisierung einer breiten Palette repetitiver Aufgaben befreien sie Entwicklungsteams von Routineoperationen und ermöglichen es ihnen, sich auf strategische Aktivitäten mit höherem Mehrwert zu konzentrieren.

Darüber hinaus agieren LLMs als intelligente technische Assistenten, die sofort relevante Code-Snippets liefern können, die auf den spezifischen Kontext jedes Projekts zugeschnitten sind. Auf diese Weise reduzieren sie die Recherchezeit erheblich, indem sie gebrauchsfertige Lösungen zur Unterstützung von Teams bei ihrer Arbeit anbieten. Diese gezielte Unterstützung beschleunigt die Problemlösung und reduziert Unterbrechungen in Workflows.

Als Ergebnis steigt die Produktivität und Projekte kommen schneller voran. Technische Teams können mehr Aufgaben übernehmen, ohne die Qualität der Deliverables zu beeinträchtigen.

Verbesserte Code-Qualität und Sicherheit

Der Einsatz von Large Language Models in der Softwareentwicklung ist ein wichtiger Hebel zur Verbesserung sowohl der Code-Qualität als auch der Anwendungssicherheit. Mit ihren fortgeschrittenen Analysefähigkeiten können LLMs Quellcode Zeile für Zeile scannen und sofort Syntaxfehler, logische Inkonsistenzen und potenzielle Schwachstellen erkennen. Ihre Fähigkeit, fehlerhaften Code zu erkennen, ermöglicht es ihnen, angemessene Korrekturen zu empfehlen, die den Best Practices der Branche entsprechen.

LLMs spielen auch eine wichtige präventive Rolle. Sie sind hervorragend darin, komplexe Sicherheitslücken zu identifizieren, die für Menschen oft schwer zu erkennen sind. Durch die Analyse von Dependencies können sie veraltete oder anfällige Bibliotheken kennzeichnen und sicherere, aktualisierte Versionen empfehlen. Dieser Ansatz trägt dazu bei, eine sichere Umgebung aufrechtzuerhalten, die den aktuellen Sicherheitsstandards entspricht.

Über die Behebung bestehender Fehler hinaus bieten LLMs Verbesserungen, indem sie optimierte Coding-Praktiken und Projektstrukturen vorschlagen. Sie können Code generieren, der den fortschrittlichsten Sicherheitsstandards von den frühesten Entwicklungsstadien an entspricht.

Beschleunigung von Entwicklungszyklen

Large Language Models spielen eine Schlüsselrolle bei der Beschleunigung von Softwareentwicklungszyklen, indem sie zentrale Aufgaben automatisieren, die andernfalls wertvolle menschliche Ressourcen binden würden. Komplexe und repetitive Aufgaben wie das Schreiben von Funktionen, die Erstellung von Unit-Tests oder die Implementierung von Standardkomponenten werden in wenigen Momenten automatisiert.

LLMs beschleunigen auch die Validierungsphase mit ihrer Fähigkeit, vollständige und angemessene Testfälle vorzuschlagen. Sie gewährleisten eine breitere Testabdeckung in kürzerer Zeit, reduzieren das Fehlerrisiko und ermöglichen die frühzeitige Erkennung von Anomalien. Dieser präventive Ansatz verkürzt den Korrekturzyklus und begrenzt Verzögerungen im Zusammenhang mit Code-Qualitätsproblemen. Indem sie technische Aufgaben vereinfachen und schnelle, maßgeschneiderte Lösungen bieten, ermöglichen Large Language Models Unternehmen, agiler auf Marktanforderungen zu reagieren. Diese Beschleunigung des Entwicklungszyklus führt zu häufigeren Updates, schnelleren Iterationen und einer besseren Fähigkeit, Produkte an die sich ändernden Bedürfnisse der Benutzer anzupassen. Entwicklungszyklen werden kürzer und bieten einen kritischen strategischen Vorteil in einer zunehmend anspruchsvollen Technologielandschaft.

Was sind die Herausforderungen beim Einsatz von LLMs?

Trotz ihrer vielen Vorteile haben Large Language Models bestimmte Einschränkungen, die sorgfältig verwaltet werden müssen. Ihre Effektivität hängt stark von der Qualität der während des Trainings verwendeten Daten und regelmäßigen Updates ihrer Wissensbasen ab. Darüber hinaus können Probleme im Zusammenhang mit algorithmischen Verzerrungen, Datensicherheit und Datenschutz auftreten, die Unternehmen operativen und rechtlichen Risiken aussetzen. Eine sorgfältige menschliche Überwachung bleibt unerlässlich, um die Zuverlässigkeit der Ergebnisse sicherzustellen, die regulatorische Compliance aufrechtzuerhalten und kritische Fehler zu vermeiden.

Datenschutz und Sicherheit

Das Training von LLMs basiert auf großen Datenmengen, oft aus verschiedenen Quellen, was Fragen zum Schutz vertraulicher Informationen aufwirft. Sensible Daten, die mit Cloud-Plattformen geteilt werden, können daher potenziellen Sicherheitsverletzungen ausgesetzt sein. Dies ist besonders besorgniserregend für Unternehmen, die in regulierten Sektoren tätig sind.

In Europa, wo strenge Vorschriften wie die DSGVO das Datenmanagement regeln, zögern viele Unternehmen, ihre Informationen an externe Dienste zu übertragen. Die regulatorischen Anforderungen, verbunden mit der Angst vor unbefugter Nutzung sensibler Daten, haben einige Unternehmen dazu veranlasst, sich für selbst gehostete Lösungen zu entscheiden, um die vollständige Kontrolle über ihre Systeme zu behalten.

Anbieter wie GitLab haben robuste Sicherheitsgarantien implementiert, wie die absichtliche Nicht-Speicherung persönlicher Daten und End-to-End-Verschlüsselung. Dies reicht jedoch möglicherweise nicht für die anspruchsvollsten Kunden aus, die eine vollständige Kontrolle über ihre Umgebungen bevorzugen. Die Implementierung hybrider oder On-Premises-Lösungen wird dann zu einer strategischen Notwendigkeit, um die Sicherheitsanforderungen bestimmter Unternehmen zu erfüllen. Erfahre mehr über GitLab Duo Self-Hosted, indem du auf das Bild unten klickst, um auf unsere Produkttour zuzugreifen.

Genauigkeit und Zuverlässigkeit

Obwohl Large Language Models beeindruckende Ergebnisse produzieren können, ist ihre Leistung nicht unfehlbar. Sie können falsche, unvollständige oder inkonsistente Antworten produzieren. Diese Ungenauigkeit wird besonders problematisch im Kontext kritischer Aufgaben wie der Generierung von Sicherheitscode oder der Analyse sensibler Daten.

Darüber hinaus arbeiten LLMs auf der Grundlage probabilistischer Modelle, was bedeutet, dass sie den Inhalt, den sie verarbeiten, nicht wirklich "verstehen", sondern Vorhersagen basierend auf statistischen Wahrscheinlichkeiten produzieren. Dies kann zu technisch falschen oder sogar gefährlichen Empfehlungen führen, wenn sie ohne menschliche Validierung verwendet werden.

Um diese Fallstricke zu vermeiden, ist es unerlässlich, eine konstante Überwachung aufrechtzuerhalten und rigorose Validierungsprozesse zu etablieren. Die von LLMs bereitgestellten Ergebnisse müssen immer von Menschen überprüft werden, bevor sie in kritische Systeme integriert werden.

Eine Strategie regelmäßiger Modell-Updates, kombiniert mit proaktiver menschlicher Überwachung, kann Fehler reduzieren und die Zuverlässigkeit der Ergebnisse schrittweise verbessern.

Wie GitLab LLMs für GitLab Duo-Features nutzt

GitLab Duo nutzt die Kraft von Large Language Models, um DevSecOps-Prozesse zu transformieren, indem KI-gestützte Fähigkeiten über den gesamten Softwareentwicklungszyklus integriert werden. Dieser Ansatz zielt darauf ab, die Produktivität zu verbessern, die Sicherheit zu stärken und komplexe Aufgaben zu automatisieren, damit sich Entwicklungsteams auf Aufgaben mit hohem Mehrwert konzentrieren können.

KI-unterstützte Softwareentwicklung

GitLab Duo bietet kontinuierliche Unterstützung während des gesamten Softwareentwicklungszyklus mit Echtzeit-Empfehlungen. Entwicklungsteams können automatisch Unit-Tests generieren, detaillierte Erklärungen komplexer Code-Segmente erhalten und von Vorschlägen zur Verbesserung ihrer Code-Qualität profitieren.

Proaktive CI/CD-Fehleranalyse

Eine der Schlüsselfunktionen von GitLab Duo ist die Unterstützung bei der Analyse von CI/CD-Job-Fehlern. Mit LLM und KI können Teams schnell Fehlerquellen in ihren Continuous-Integration- und Deployment-Pipelines identifizieren.

Verbesserte Code-Sicherheit

GitLab Duo integriert KI-basierte Sicherheitsfunktionen. Das System erkennt Schwachstellen im Quellcode und schlägt detaillierte Patches vor, um die Risiken zu reduzieren. Teams erhalten klare Erklärungen zur Art der identifizierten Schwachstellen und können automatisierte Patches über Merge Requests anwenden, die direkt von GitLab Duo generiert werden. Diese Funktion hilft, die Entwicklung zu sichern, ohne die Entwicklungszyklen zu verlangsamen.

Erfahre mehr über GitLab Duo Vulnerability Explanation and Resolution, indem du auf das Bild unten klickst, um auf unsere Produkttour zuzugreifen.

Schlüsselfunktionen von GitLab Duo

• GitLab Duo Chat: Diese Konversationsfunktion verarbeitet und generiert Text und Code intuitiv. Sie ermöglicht es Benutzern, schnell relevante Informationen in großen Textmengen zu suchen, einschließlich in Tickets, Epics, Quellcode und der GitLab-Dokumentation.
• GitLab Duo Self-Hosted: GitLab Duo Self-Hosted ermöglicht es Unternehmen mit strengen Datenschutzanforderungen, von den KI-Fähigkeiten von GitLab Duo mit Flexibilität bei der Wahl der Bereitstellung und LLMs aus einer Liste unterstützter Optionen zu profitieren.
• GitLab Duo Code Suggestions: Entwicklungsteams profitieren von automatisierten Code-Vorschlägen, die es ihnen ermöglichen, schneller sicheren Code zu schreiben. Repetitive und routinemäßige Codierungsaufgaben werden automatisiert, wodurch Softwareentwicklungszyklen erheblich beschleunigt werden.
• GitLab Duo ist nicht auf diese Funktionen beschränkt. Es bietet eine breite Palette von Features, die darauf ausgelegt sind, die Softwareentwicklung zu vereinfachen und zu optimieren. Ob es um die Automatisierung von Tests, die Verbesserung der Zusammenarbeit zwischen Teams oder die Stärkung der Projektsicherheit geht, GitLab Duo ist eine vollständige Lösung für intelligente und effiziente DevSecOps-Prozesse.
• Erfahre mehr über GitLab Duo Enterprise, indem du auf das Bild unten klickst, um auf unsere Produkttour zuzugreifen.

Der Geschäftsfall: Was Git-Performance kostet

Stellen wir uns vor: Arbeit am Chromium-Projekt, das Repository muss geklont werden. git clone starten, einen Kaffee holen, E-Mails checken, vielleicht eine Mittagspause – und 95 Minuten später ist endlich das Arbeitsverzeichnis da. Das ist die Realität für Entwickler, die mit großen Repositories von 50 GB+ arbeiten.

Die Produktivitätsauswirkungen sind erheblich: CI/CD-Pipelines kommen zum Erliegen während sie auf Repository-Klone warten. Infrastrukturkosten steigen, da Compute-Ressourcen untätig bleiben. Entwickler-Frustration wächst, während Context-Switching zur Norm wird. Das Problem zeigt sich überall: Embedded-Teams erben Repositories mit Legacy-Firmware und Vendor-SDKs. Web-Anwendungen akkumulieren Marketing-Assets. Game-Development-Projekte enthalten 3D-Modelle und Audio-Dateien – Repository-Größen erreichen Dutzende von Gigabytes.

Enterprise-CI/CD-Pipelines leiden besonders: Jeder Job braucht frische Repository-Klone. Bei 20-90 Minuten Operationszeit erliegen ganze Entwicklungsworkflows. Infrastrukturkosten steigen durch untätige Compute-Ressourcen.

8-60x schneller – je nach Repository-Größe:

Git Much Faster demonstriert dramatische Verbesserungen durch rigoroses Benchmarking über reale Repositories mit konsistenter AWS-Infrastruktur:

Linux-Kernel-Repository (7,5 GB total): Standard clone dauerte 6 Minuten 29 Sekunden. Optimized clone erreichte 46,28 Sekunden – eine 88,1%ige Verbesserung, wodurch das .git-Verzeichnis von 5,9 GB auf 284 MB reduziert wurde.

Chromium-Repository (60,9 GB total): Standard clone benötigte 95 Minuten 12 Sekunden. Optimized clone erreichte 6 Minuten 41 Sekunden – eine beeindruckende 93%ige Verbesserung, wodurch das .git-Verzeichnis von 55,7 GB auf 850 MB komprimiert wurde.

GitLab-Website-Repository (8,9 GB total): Standard clone dauerte 6 Minuten 23 Sekunden. Optimized clone erreichte 6,49 Sekunden – eine bemerkenswerte 98,3%ige Verbesserung, wodurch das .git-Verzeichnis auf 37 MB reduziert wurde.

Die Benchmark-Daten zeigen klare Muster: Größere Repositories zeigen dramatischere Verbesserungen, binär-lastige Repositories profitieren am meisten von intelligenten Filtern, und optimierte Ansätze übertreffen konsistent sowohl standard Git als auch Gits eigenes Scalar-Tool.

Kosteneinsparungen für die gesamte Infrastruktur

Git clone-Optimierung reduziert auch die Systembelastung durch kleinere Anfragegrößen. GitLabs Gitaly Cluster profitiert direkt: Weniger server-seitige "pack file"-Erstellung bedeutet niedrigere Memory-, CPU- und I/O-Anforderungen. Der gesamte Stack wird schneller und günstiger.

Diese Infrastructure-Einsparungen multiplizieren sich in Enterprise-Umgebungen: Reduzierte Dimensionierung der Git-Server, weniger Netzwerk-Overhead, optimierte Storage-Nutzung. Alle Schichten profitieren gleichzeitig.

Typische Enterprise-Anwendungsfälle

Embedded Development: Legacy-Firmware, FPGA-Bitstreams, PCB-Layouts treiben Repository-Größen hoch. Build-Prozesse klonen oft Dutzende externe Repositories, multiplizieren die Performance-Auswirkungen.

Enterprise-Monorepos: Mehrere Projekte, akkumulierte Historie. Media-Assets verstärken das Problem – Web-Apps mit Marketing-Assets, Games mit 3D-Modellen über 100 GB.

CI/CD-Pipelines: Jeder Job braucht frische Klone. Bei 20-90 Minuten werden Workflows unbrauchbar. Hier zeigen sich die größten Produktivitätsgewinne.

Verteilte Teams: Limitierte Netzwerk-Performance zu Development-Workstations profitiert von reduzierten Over-the-Wire-Größen.

Die technische Umsetzung: Wie es funktioniert

Git Much Faster ist ein Script, das ich als Enablement-Tool entwickelt habe, um verschiedene Clone-Optimierungsansätze auf demselben Client zu benchmarken – ob Entwickler-Workstation, CI, Cloud-Umgebungen oder GitOps-Klone. Es enthält kuratierte Konfigurationen für schnellste Clone-Optimierung, die sich als Ausgangspunkt nutzen lassen.

Die Lösung adressiert die grundlegende Herausforderung: Gits Standard-Clone-Verhalten priorisiert Sicherheit über Geschwindigkeit. Bei großen Codebasen, Binär-Assets oder Monorepo-Strukturen wird das zum erheblichen Engpass.

Vier Benchmark-Strategien im Vergleich

Git Much Faster löst dies durch umfassendes Benchmarking, das vier verschiedene Strategien vergleicht: standard git clone (Baseline mit vollständiger Historie), optimized git clone (custom Konfigurationen mit deaktivierter Kompression und sparse checkout), Gits Scalar clone (integriertes partial cloning) und current directory assessment (Analyse bestehender Repositories ohne erneutes Klonen).

Das Tool bietet messbare, wiederholbare Benchmarks in kontrollierten AWS-Umgebungen. Die wahre Stärke: alle Benchmarks lassen sich in der spezifischen Umgebung ausführen – auch bei langsamen Netzwerkverbindungen findet sich die optimale Clone-Strategie.

Zwei Schlüssel-Konfigurationen für 93% Zeitersparnis

Die bedeutendsten Gewinne stammen aus zwei Optimierungen:

Erste Optimierung – core.compression=0: Eliminiert CPU-intensive Kompression während Netzwerkoperationen. Bei modernen Hochgeschwindigkeitsnetzwerken überschreiten CPU-Zyklen oft die Bandbreiteneinsparungen. Allein diese Optimierung reduziert Clone-Zeiten um 40%–60%.

Zweite Optimierung – http.postBuffer=1024M: Erhöht Gits konservative HTTP-Buffer-Größe. Große Repositories profitieren enorm – Git kann größere Operationen handhaben ohne Aufteilen in mehrere Requests.

Zusätzlich nutzt Git Much Faster shallow clones (--depth=1) und partial clones (--filter=blob:none). Shallow clones reduzieren Daten um 70%–90%, partial clones helfen bei Repositories mit großen Binär-Assets. Sparse checkout kontrolliert ausgecheckte Dateien chirurgisch präzise – 30+ Binärdateitypen werden ausgeschlossen, Working-Directory-Größe sinkt um 78%.

Gits Scalar-Tool kombiniert partial clone, sparse checkout und Background-Wartung. Tests zeigen jedoch: Der custom optimized approach übertrifft Scalar um 48%–67% bei ähnlichen Disk-Space-Einsparungen.

Sofortige Implementierung in drei Schritten

Die Implementierung erfordert das Verständnis, wann welche Technik basierend auf Use Case und Risikotoleranz anzuwenden ist. Für Development, das vollständigen Repository-Zugang erfordert: standard Git cloning nutzen. Für read-heavy Workflows, die schnellen Zugang zu aktuellem Code benötigen: optimized cloning einsetzen. Für CI/CD-Pipelines, wo Geschwindigkeit paramount ist: optimized cloning bietet maximalen Nutzen.

Der Einstieg erfordert nur einfachen Download und Ausführung:

curl -L https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster/-/raw/master/git-much-faster.sh -o ./git-much-faster.sh




# Für Benchmarking



bash ./git-much-faster.sh --methods=optimized,standard --repo=https://github.com/your-org/your-repo.git

Für production-grade Testing enthält das Git Much Faster-Projekt komplette Terraform-Infrastruktur für AWS-Deployment, wodurch sich Variablen eliminieren lassen, die lokale Testergebnisse verzerren.

Wichtige Einschränkungen beachten

Optimized clones haben Limitierungen: Shallow clones verhindern Zugang zu historischen Commits. Lösung: Entwickler starten optimized, konvertieren bei Bedarf via git fetch --unshallow zu full clones. CI-Jobs mit Commit-Historie-Zugriff brauchen möglicherweise vollständige Historie.

Transformative Ergebnisse für deutsche Teams

Git clone-Optimierung liefert messbare Verbesserungen – bis zu 93% weniger Clone-Zeit, 98% weniger Disk-Space-Usage. Gits konservativer Standard-Ansatz lässt erhebliche Performance-Gelegenheiten ungenutzt.

Für deutsche Entwicklungsteams: Reduzierte CI/CD-Wartezeiten steigern tägliche Produktivität, geringere Infrastrukturkosten ermöglichen relevante Kosteneinsparungen in Enterprise-Umgebungen.

Einfach starten mit dem Git Much Faster Repository – read-only Optimierung in CI/CD-Pipelines beginnen, schrittweise auf Development-Workflows erweitern basierend auf gemessenen Ergebnissen.

Als Teil des Engagements für verantwortungsvolles KI-Management hat GitLab die ISO/IEC 42001-Zertifizierung erhalten – den ersten international anerkannten Standard für Einrichtung, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung eines KI-Management-Systems (AIMS) in Organisationen.

Dieser Meilenstein ist beispielsweise für deutsche Unternehmen relevant, die mit den EU AI Act-Anforderungen navigieren müssen. Die schrittweise Implementierung des EU AI Act bringt ab August 2025 konkrete Governance-Verpflichtungen für KI-Systeme mit sich. ISO/IEC 42001 bietet einen systematischen Rahmen, der Organisationen bei der Erfüllung dieser regulatorischen Anforderungen unterstützt – besonders in Branchen wie Automotive, Financial Services oder Industrieautomation, wo KI-Governance und Nachvollziehbarkeit zunehmend geschäftskritisch werden.

Zertifizierungsumfang

Der Zertifizierungsumfang umfasst das umfassende KI-Angebot GitLab Duo sowie die GitLab Duo Agent Platform mit allen Komponenten. Als führende DevSecOps-Plattform bietet GitLab KI-gestützte Funktionen über den gesamten Entwicklungslebenszyklus:

• GitLab Duo Agent Platform (jetzt in Public Beta, allgemeine Verfügbarkeit geplant für später dieses Jahr): Ermöglicht asynchrone Zusammenarbeit zwischen Entwicklern und spezialisierten KI-Agenten während des Software-Entwicklungslebenszyklus. Die Plattform transformiert lineare Entwicklungsprozesse in dynamische, parallele Workflows und verschafft Agenten Zugriff auf den gesamten Software-Engineering-Kontext innerhalb von GitLabs einheitlicher Plattform.

• Code Suggestions (allgemein verfügbar): Ermöglicht Entwicklern, im Flow zu bleiben, indem Code-Blöcke prädiktiv vervollständigt, Funktionslogik definiert, Tests generiert und gängige Code-Patterns wie Regex vorgeschlagen werden – alles in der gewohnten Entwicklungsumgebung.

• Vulnerability Explanation (allgemein verfügbar): Hilft Entwicklern und Sicherheitsanalysten, Schwachstellen zu verstehen, wie sie ausgenutzt werden könnten und wie sie behoben werden können.

• Test Generation (allgemein verfügbar): Erstellt automatisch Tests für ausgewählten Code, verbessert die Testabdeckung und reduziert manuellen Aufwand.

Was diese Zertifizierung bedeutet

Vertrauen und Transparenz: Die KI-Features von GitLab werden nach global anerkannten Best Standards für KI-Governance entwickelt und verwaltet. Das unterstützt Zuverlässigkeit und ethische Implementierung.

Strategisches Risikomanagement: GitLab hat Risk-Assessment- und Risk-Treatment-Strategien für KI-Komponenten innerhalb der Plattform implementiert. Diese berücksichtigen Aspekte wie operative Business-Continuity-Risiken, technische Risiken, Security- und Privacy-Risiken sowie breitere gesellschaftliche Implikationen. Dieser proaktive Ansatz verbessert den Datenschutz und ermöglicht zuverlässigere KI-gestützte Features.

Kontinuierliche Verbesserung: Unter dem ISO/IEC 42001-Framework wird GitLab die KI-Capabilities kontinuierlich evaluieren und verbessern – durch jährliche externe Surveillance-Audits, regelmäßige interne Assessments und Leadership-AIMS-Reviews bei gleichzeitiger Wahrung von Qualitäts- und Verantwortungsstandards.

Regulatorische Ausrichtung: Da sich KI-Regulierungen global weiterentwickeln – wie der EU AI Act – unterstützt diese Zertifizierung GitLabs Ausrichtung an aufkommenden regulatorischen Anforderungen.

Diese Zertifizierung bestätigt GitLabs Position als vertrauenswürdige Plattform für KI-gestützte DevSecOps.

Mehr erfahren

• ISO/IEC 42001-Zertifikat im GitLab Trust Center einsehen
• Über unser AIMS im Handbook lesen
• Das GitLab AI Transparency Center besuchen
• Alle GitLab Duo Features und Capabilities in der Dokumentation entdecken

Was ist YAML?

YAML ist eine Programmiersprache, die entwickelt wurde, damit Menschen Daten prägnant und verständlich darstellen können. Sie wird häufig für Konfigurationsdateien und Datenübertragung verwendet. YAML eignet sich hervorragend zur Organisation hierarchischer Informationen und wird manchmal als Alternative zu JSON oder XML eingesetzt.

Wofür wird YAML verwendet?

Aufgrund seiner hohen Lesbarkeit wird YAML für Konfigurationsdateien und Playbooks verwendet. Hier sind einige Beispiele als Referenz:

• Erstellung von Konfigurationsdateien
• Log-Dateien
• Nachrichtenaustausch zwischen Prozessen
• Datenaustausch zwischen Anwendungen
• Beschreibung strukturierter Daten

Was ist der Unterschied zwischen YAML und YML?

Beide bezeichnen Dateien im gleichen Format – der einzige Unterschied ist die Dateierweiterung ".yml" oder ".yaml". Die offizielle Erweiterung für YAML-Dateien ist .yaml, aber da Dateierweiterungen (.txt, .zip, .exe, .png usw.) üblicherweise aus drei Buchstaben bestehen, wurde .yml an diese Drei-Buchstaben-Regel angepasst. Entwickler(innen), die es kurz und prägnant mögen, wählen oft ".yml".

Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. Erfolgsstory lesen

Der Unterschied zwischen YAML und JSON

Während JSON geschweifte Klammern zur Definition von Anforderungen verwendet, wird bei YAML die Struktur durch Einrückungen deutlich gemacht, was die Lesbarkeit erhöht. Vergleiche die folgenden Beispiele: Du wirst sehen, dass YAML auf Benutzerfreundlichkeit für Programmierer(innen) ausgelegt ist.

YAML:

JSON:

YAML vs. CUE im Vergleich

Während YAML eine hohe Lesbarkeit und einfache Struktur bietet, integriert CUE Schema und Daten, wodurch auch komplexe Konfigurationen in einer einzigen Datei verwaltet werden können. Außerdem verfügt CUE über Schema-Validierungsfunktionen, die mit YAML allein nicht möglich sind, was die Datenintegrität besser gewährleistet.

Flexibilität ist ebenfalls ein großes Merkmal. CUE ist eine Open-Source-Sprache (genauer gesagt ein Superset von JSON), die zur Definition, Generierung und Validierung aller Arten von Daten verwendet wird. Sie kann mit vielen anderen Sprachen wie Go, JSON, OpenAPI, Protocol Buffers und YAML zusammenarbeiten.

Mit Scripting-Funktionen über die Go-API gibt es Anwendungsfälle wie die Anzeige von CUE-Manifesten als finale Kubernetes-Ressourcen-YAML oder die Implementierung von Befehlen zur Auflistung von Ressourcen für die Bereitstellung in bestimmten Clustern.

YAML-Datenstruktur und Syntax (Grundlagen)

Wichtige Hinweise zum Schreiben von YAML-Dateien

Denk daran, dass Einrückungen und Tabs sehr wichtig sind. Zusätzliche Einrückungen oder verwendete Tabs können die Bedeutung von YAML-Objekten verändern, daher sind diese besonders wichtig.

YAML-Datenstruktur

YAML besteht hauptsächlich aus zwei Datentypen: Collections und Skalare. Collections bestehen aus Sequenzen und Mappings. Sequenzen sind Arrays, Mappings sind Name-Wert-Paare (Arrays, die als Key : Value ausgedrückt werden). Skalare dienen zur Typidentifizierung und repräsentieren Strings, Zahlen usw.

• Collections

  • Sequenzen
  • Mappings

• Skalare

YAML-Syntax

• Mehrzeilige Collections: Verwende das | (vertikaler Balken) Symbol, wenn du das Format mehrerer Zeilen beibehalten musst.
• Mehrzeiliges Format: Verwende >, wenn du lange String-Werte hast und diese über mehrere Zeilen mit beibehaltener Formatierung schreiben musst.
• Listen: Listen werden mit - (Bindestrich) dargestellt.
• Verschachtelung: Verschachtelte Datenstrukturen werden durch Einrückungen dargestellt.

Wie man Kubernetes (k8s) YAML-Dateien schreibt

In Kubernetes werden YAML-Dateien zur Definition von Ressourcen verwendet. Hier zeige ich dir, wie man YAML-Manifeste schreibt.

YAML-Manifest:

Wie man Ansible YAML-Dateien schreibt

In Ansible werden Playbooks, die Verarbeitungsabläufe beschreiben, in YAML geschrieben. Hier ist ein einfaches Beispiel eines Ansible-Playbooks:

YAML in GitLab verwenden

GitLab CI/CD-Pipelines verwenden für jedes Projekt eine YAML-Datei namens .gitlab-ci.yml, um die Pipeline-Struktur und Ausführungsreihenfolge zu definieren. Die in dieser Datei konfigurierten Inhalte werden im GitLab Runner verarbeitet. Weitere Informationen zur CI/CD YAML-Syntax findest du auf dieser Übersichtsseite.

Lass uns gemeinsam eine YAML-Datei bearbeiten

Dank seiner Einfachheit und hohen Lesbarkeit wird YAML vielseitig eingesetzt – für Konfigurationsdateien, CI/CD-Pipelines, Container-Orchestrierung mit Kubernetes, Dokumentation und Konfigurationsmanagement. Die hohe Lesbarkeit ermöglicht es Entwicklern und Betriebsingenieuren, Konfigurationen und Daten einfach zu verwalten und effizient zu arbeiten. Wenn du YAML verstehst, kannst du Einstellungen für verschiedene Systeme und Tools einfacher und intuitiver vornehmen.

Häufig gestellte Fragen zu YAML

Wofür wird YAML verwendet?

Dank seiner Einfachheit und hohen Lesbarkeit wird YAML vielseitig eingesetzt – für Konfigurationsdateien, CI/CD-Pipelines, Container-Orchestrierung mit Kubernetes, Dokumentation und Konfigurationsmanagement.

Was ist der Unterschied zwischen YAML und JSON?

JSON-Dateien verwenden geschweifte Klammern zur Definition von Anforderungen, während bei YAML die Struktur durch Einrückungen deutlich gemacht wird, was die Lesbarkeit erhöht. Beachte jedoch, dass bei YAML Einrückungen und Leerzeichen sehr wichtig sind.

Warum ist YAML so beliebt?

YAML ist eine beliebte Daten-Serialisierungssprache unter Entwicklern. Das liegt an seiner Lesbarkeit, Vielseitigkeit und dem Python-ähnlichen Einrückungssystem. YAML unterstützt mehrere Datentypen und bietet Parser-Bibliotheken für viele Programmiersprachen. Dadurch kann es verschiedene Daten-Serialisierungsaufgaben bewältigen und wird in vielen Bereichen eingesetzt.

Möchtest du GitLab Ultimate mit Duo Enterprise ausprobieren? Melde dich heute für eine kostenlose Testversion an.

Diese Situation erfordert eine ehrliche Betrachtung der tatsächlichen Kosten fragmentierten Artifact Managements – und realistische Lösungsansätze für Platform-Teams. Dieser Artikel analysiert die Problematik und zeigt, wie GitLab durch strategische Konsolidierung messbare Verbesserungen ermöglicht.

Die messbaren Auswirkungen

Basierend auf Kundendaten und Branchenanalysen verursacht fragmentiertes Artifact Management typischerweise folgende Kosten für mittelgroße Organisationen (500+ Entwickler(innen)):

• Lizenzierung: 50.000-200.000 US-Dollar jährlich über mehrere Tools verteilt
• Operativer Overhead: 2-3 FTE-Äquivalent für Artifact-Management-Aufgaben
• Storage-Ineffizienz: 20-30 % höhere Storage-Kosten durch Duplikation und mangelhaftes Lifecycle Management
• Produktivitätsverlust: 15-20 Minuten täglich pro Entwickler(in) durch Artifact-bezogene Reibungsverluste

Bei Großunternehmen multiplizieren sich diese Zahlen erheblich. Ein Kunde berechnete über 500.000 US-Dollar jährliche Kosten allein für den operativen Overhead der Verwaltung von sieben verschiedenen Artifact-Storage-Systemen.

Die versteckten Kosten summieren sich täglich:

Zeit-Multiplikation: Jede Lifecycle-Policy, Sicherheitsregel oder Zugriffskontrolle muss über mehrere Systeme implementiert werden. Eine 15-minütige Konfiguration wird zu stundenlanger Arbeit.

Sicherheitslücken-Risiken: Die Verwaltung von Sicherheitsrichtlinien über disparate Systeme schafft blinde Flecken. Vulnerability Scanning, Zugriffskontrollen und Audit Trails werden fragmentiert.

Kontextwechsel-Kosten: Entwickler(innen) verlieren Produktivität, wenn sie Artifacts nicht finden oder sich merken müssen, welches System was speichert.

Das Multiplikationsproblem

Die Artifact-Management-Landschaft ist explodiert. Wo Teams früher ein einzelnes Maven-Repository verwalteten, jonglieren Platform-Engineers heute mit:

• Container-Registries (Docker Hub, ECR, GCR, Azure ACR)
• Package-Repositories (JFrog Artifactory, Sonatype Nexus)
• Sprachspezifische Registries (npm, PyPI, NuGet, Conan)
• Infrastructure-Artifacts (Terraform-Module, Helm-Charts)
• ML-Model-Registries (MLflow, Weights & Biases)

Jedes Tool bringt eigene Authentifizierungssysteme, Lifecycle-Policies, Security Scanning und operative Anforderungen mit. Für Organisationen mit Hunderten oder Tausenden von Projekten entsteht eine exponentielle Management-Belastung.

GitLabs strategischer Ansatz: Tiefe statt Breite

Bei der Entwicklung von GitLabs Artifact-Management-Fähigkeiten stand eine klassische Produktentscheidung an: Unterstützung für jedes erdenkliche Artifact-Format oder tiefgehende Implementierung für die Formate, die für Enterprise-Teams wirklich zählen. Die Entscheidung für Tiefe prägt alles, was seitdem entwickelt wurde.

Die Kernfokusbereiche

Statt oberflächlicher Unterstützung für 20+ Formate wurde Enterprise-Grade-Funktionalität für ein strategisches Set entwickelt:

• Maven (Java-Ökosystem)
• npm (JavaScript/Node.js)
• Docker/OCI (Container-Images)
• PyPI (Python-Packages)
• NuGet (C#/.NET-Packages)
• Generic Packages (beliebige binäre Artifacts)
• Terraform-Module (Infrastructure as Code)

Diese sieben Formate decken basierend auf Kundendaten etwa 80 % der Artifact-Nutzung in Enterprise-Umgebungen ab.

Was "Enterprise-Grade" konkret bedeutet

Durch Fokussierung auf weniger Formate können Fähigkeiten geliefert werden, die in Produktionsumgebungen mit Hunderten von Entwickler(innen), Terabytes von Artifacts und strengen Compliance-Anforderungen funktionieren:

Virtual Registries: Proxy und Cache für Upstream-Dependencies für zuverlässige Builds und Supply-Chain-Kontrolle. Aktuell produktionsreif für Maven, npm und Docker folgen Anfang 2026.

Lifecycle Management: Automatisierte Cleanup-Policies, die Storage-Kosten kontrollieren und gleichzeitig Artifacts für Compliance bewahren. Heute auf Projektebene verfügbar, organisationsweite Policies für Mitte 2026 geplant.

Security-Integration: Integriertes Vulnerability Scanning, Dependency-Analyse und Policy-Enforcement. Die kommende Dependency Firewall (geplant für Ende 2026) wird Supply-Chain-Security-Kontrolle über alle Formate bieten.

Tiefe CI/CD-Integration: Vollständige Nachverfolgbarkeit vom Source-Commit zum deployed Artifact, mit Build-Provenance und Security-Scan-Ergebnissen in Artifact-Metadaten.

Aktuelle Fähigkeiten: Praxiserprobte Features

Maven Virtual Registries: Das Flaggschiff der Enterprise-Fähigkeiten, bewährt bei 15+ Enterprise-Kunden. Die meisten komplettieren das Maven Virtual Registry-Setup innerhalb von zwei Monaten mit minimaler GitLab-Unterstützung.

Lokal gehostete Repositories: Alle sieben unterstützten Formate bieten komplette Upload-, Download-, Versionierungs- und Zugriffskontroll-Fähigkeiten und unterstützen kritische Workloads bei Organisationen mit Tausenden von Entwickler(innen).

Protected Artifacts: Umfassender Schutz vor unautorisierten Änderungen mit feingranularen Zugriffskontrollen über alle Formate.

Projekt-Level Lifecycle Policies: Automatisierte Cleanup- und Retention-Policies für Storage-Kostenkontrolle und Compliance.

Performance- und Skalierungscharakteristika

Basierend auf aktuellen Produktions-Deployments:

• Durchsatz: 10.000+ Artifact-Downloads pro Minute/pro Instanz
• Storage: Kunden verwalten erfolgreich 50+ TB Artifacts
• Gleichzeitige Nutzer(innen): 1.000+ Entwickler(innen) greifen simultan auf Artifacts zu
• Verfügbarkeit: 99,99 % Uptime für GitLab.com seit über 2 Jahren

Strategische Roadmap: Die nächsten 18 Monate

Q1 2026

• npm Virtual Registries: Enterprise Proxy/Cache für JavaScript-Packages
• Docker Virtual Registries: Container-Registry-Proxy-Fähigkeiten

Q2 2026

• Organisations-Level Lifecycle Policies (Beta): Zentralisierte Cleanup-Policies mit Projekt-Overrides
• NuGet Virtual Registries (Beta): .NET-Package-Proxy-Unterstützung
• PyPI Virtual Registries (Beta): Vervollständigung der Virtual-Registry-Unterstützung für Python

Q3 2026

• Advanced Analytics Dashboard: Storage-Optimierung und Nutzungs-Insights

Q4 2026

• Dependency Firewall (Beta): Supply-Chain-Security-Kontrolle für alle Artifact-Typen

Entscheidungsframework: Wann GitLab die richtige Wahl ist

GitLab ist wahrscheinlich die richtige Wahl, wenn:

• 80 %+ deiner Artifacts in unseren sieben unterstützten Formaten sind
• Du bereits GitLab für Source Code oder CI/CD nutzt
• Du integrierte Workflows über Standalone-Feature-Reichtum stellst
• Du die operative Komplexität mehrerer Systeme reduzieren willst
• Du vollständige Nachverfolgbarkeit von Source bis Deployment benötigst

Migrationsüberlegungen

Typische Timeline: 2-4 Monate für komplette Migration von Artifactory/Nexus

Häufige Herausforderungen: Virtual-Registry-Konfiguration, Access-Control-Mapping und Entwickler(innen)-Workflow-Änderungen

Erfolgsfaktoren: Phasenansatz, umfassendes Testing und Entwickler(innen)-Training

Die erfolgreichsten Migrationen folgen diesem Muster:

1. Assessment (2-4 Wochen): Katalogisierung aktueller Artifacts und Nutzungsmuster
2. Pilot (4-6 Wochen): End-to-End-Migration eines Teams/Projekts
3. Rollout (6-12 Wochen): Graduelle Migration mit parallelen Systemen
4. Optimierung (fortlaufend): Implementierung fortgeschrittener Features und Policies

Besseres Artifact Management kann heute beginnen

GitLabs Artifact Management versucht nicht, alles für jeden zu sein. Strategische Trade-offs wurden getroffen: tiefe Fähigkeiten für Kern-Enterprise-Formate statt oberflächlicher Unterstützung für alles.

Wenn deine Artifact-Anforderungen mit unseren unterstützten Formaten übereinstimmen und du integrierte Workflows schätzt, können wir deinen operativen Overhead signifikant reduzieren und gleichzeitig die Developer Experience verbessern.

Unser Ziel ist es, dir bei informierten Entscheidungen über deine Artifact-Management-Strategie zu helfen – mit klarem Verständnis der Fähigkeiten und unserer Roadmap.

Kontaktiere mich gerne unter trizzi@gitlab.com(bitte auf Englisch anschreiben), um mehr über GitLab Artifact Management zu erfahren. Ich kann spezifische Anforderungen diskutieren und dich mit unserem technischen Team für eine tiefere Evaluierung verbinden.

Weitere technische Details und Implementierungsbeispiele findest du im englischen Original.

Dieser Blog enthält Informationen zu kommenden Produkten, Features und Funktionalitäten. Es ist wichtig zu beachten, dass die Informationen in diesem Blogpost nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen für Kauf- oder Planungszwecke. Wie bei allen Projekten können die in diesem Blog und verlinkten Seiten erwähnten Elemente Änderungen oder Verzögerungen unterliegen. Die Entwicklung, Veröffentlichung und das Timing von Produkten, Features oder Funktionalitäten liegen im alleinigen Ermessen von GitLab.

GitLab bewahrt die Wahlfreiheit – ob Self-Managed für Compliance, Cloud für Flexibilität oder Hybrid für spezifische Anforderungen – alles innerhalb einer einzigen KI-gestützten DevSecOps-Plattform, die alle Geschäftsanforderungen respektiert.

Während andere Anbieter Migrationen zu reinen Cloud-Architekturen erzwingen, unterstützt GitLab weiterhin alle Deployment-Optionen, die zu individuellen Geschäftsanforderungen passen. Ob du sensible Regierungsdaten verwaltest, in air-gapped Umgebungen arbeitest oder die Kontrolle selbstverwalteter Deployments bevorzugst – wir verstehen, dass es keine Einheitslösung gibt. Besonders für deutsche Unternehmen mit strengen Datenschutzanforderungen nach DSGVO und branchenspezifischen Regularien ist diese Flexibilität geschäftskritisch.

Cloud-Architekturen erfüllen nicht alle Compliance-Anforderungen

Für viele Unternehmen, die Millionen in Data Center-Deployments investiert haben – einschließlich derer, die nach der Einstellung der Server-Produkte zu Data Center migriert sind – stellt diese Ankündigung mehr als eine Produktabkündigung dar. Sie signalisiert eine grundlegende Abkehr von kundenorientierten Architekturentscheidungen und zwingt Unternehmen, zwischen nicht passenden Deployment-Modellen oder einem Anbieterwechsel zu wählen.

Viele Organisationen, die selbstverwaltete Deployments benötigen, gehören zu den wichtigsten Institutionen: Gesundheitssysteme mit Patientendatenschutz, Finanzinstitute mit BaFin-Auflagen, Regierungsbehörden mit nationalen Sicherheitsanforderungen und Verteidigungsunternehmen in air-gapped Umgebungen.

Diese Organisationen wählen selbstverwaltete Deployments nicht aus Bequemlichkeit, sondern aufgrund von Compliance-, Sicherheits- und Souveränitätsanforderungen, die reine Cloud-Architekturen nicht erfüllen können. Organisationen in geschlossenen Umgebungen ohne Internetzugang sind keine Ausnahmen – sie repräsentieren einen signifikanten Anteil von Unternehmenskunden verschiedener Branchen.

Die wahren Kosten erzwungener Cloud-Migration

Während Cloud-Anbieter Zwangsmigrationen als "Upgrades" darstellen, stehen Organisationen vor erheblichen Herausforderungen jenseits reiner Kostenbetrachtungen:

• Verlust von Integrationsfähigkeiten: Jahre sorgfältig entwickelter Integrationen mit Legacy-Systemen, maßgeschneiderte Workflows und unternehmensspezifische Automatisierungen werden obsolet. Für Organisationen mit tiefen Legacy-System-Integrationen ist Cloud-Migration oft technisch nicht durchführbar.

• Regulatorische Einschränkungen: Für Organisationen in regulierten Branchen ist Cloud-Migration nicht nur komplex – sie ist oft nicht zulässig. Datenresidenz-Anforderungen, air-gapped Umgebungen und strenge regulatorische Rahmenwerke richten sich nicht nach Anbieterpräferenzen. Das Fehlen von Single-Tenant-Lösungen in vielen Cloud-Only-Ansätzen schafft unüberwindbare Compliance-Hürden.

• Produktivitätseinbußen: Cloud-Only-Architekturen erfordern oft die Verwaltung mehrerer Produkte: separate Tools für Planung, Code-Management, CI/CD und Dokumentation. Jedes Tool bedeutet einen weiteren Kontextwechsel, eine weitere zu wartende Integration, einen weiteren potenziellen Fehlerpunkt. Eine GitLab-Studie zeigt, dass 30 % der Entwickler mindestens 50 % ihrer Arbeitszeit mit der Wartung und/oder Integration ihrer DevSecOps-Toolchain verbringen. Fragmentierte Architekturen verschärfen diese Herausforderung, anstatt sie zu lösen.

GitLab bietet Wahlfreiheit, Verlässlichkeit und Konsolidierung

Unternehmenskunden verdienen einen verlässlichen Technologiepartner. Deshalb haben wir uns zur Unterstützung verschiedener Deployment-Optionen verpflichtet – ob du On-Premises für Compliance, Hybrid für Flexibilität oder Cloud für Skalierbarkeit benötigst, du hast die freie Auswahl. Diese Verpflichtung setzt sich mit GitLab Duo fort, unserer KI-Lösung, die Entwickler in jeder Phase ihres Workflows unterstützt.

Wir bieten mehr als nur Deployment-Flexibilität. Während dich andere Anbieter zwingen, deine Produkte zu einer fragmentierten Toolchain zusammenzufügen, bietet GitLab alles in einer umfassenden KI-nativen DevSecOps-Plattform. Source Code Management, CI/CD, Security Scanning, Agile-Planung und Dokumentation werden innerhalb einer einzigen Anwendung und einer einzigen Anbieterbeziehung verwaltet.

Dies ist keine Theorie. Als Airbus und Iron Mountain ihre bestehenden fragmentierten Toolchains evaluierten, identifizierten sie konsistent dieselben Herausforderungen: schlechte Benutzererfahrung, fehlende Funktionalitäten wie integriertes Security Scanning und Review Apps sowie Verwaltungskomplexität durch Plugin-Troubleshooting. Das sind keine kleineren Herausforderungen, sondern ernsthafte Hindernisse für moderne Software-Delivery.

Dein Migrationspfad: Systematisch und planbar

Wir haben tausenden Organisationen bei der Migration von anderen Anbietern geholfen und die Tools sowie Expertise entwickelt, um deinen Übergang reibungslos zu gestalten:

• Automatisierte Migrationstools: Unser Bitbucket Server Importer überträgt Repositories, Pull Requests, Kommentare und sogar Large File Storage (LFS) Objekte. Für Jira übernimmt unser integrierter Importer Issues, Beschreibungen und Labels. Professional Services stehen für komplexe Migrationen zur Verfügung.

• Bewährt im großen Maßstab: Ein 500 GiB Repository mit 13.000 Pull Requests, 10.000 Branches und 7.000 Tags benötigt mit Parallelverarbeitung nur etwa 8 Stunden für die Migration von Bitbucket zu GitLab.

• Sofortiger ROI: Eine von GitLab beauftragte Forrester Consulting Total Economic Impact™ Studie bestätigt messbare Geschäftsvorteile: 483 % ROI über drei Jahre, 5-fache Zeitersparnis bei sicherheitsbezogenen Aktivitäten und 25% Einsparungen bei Software-Toolchain-Kosten.

Beginne die Transformation zu einer einheitlichen DevSecOps-Plattform

Vorausschauende Organisationen warten nicht auf anbieterdiktierte Fristen. Sie evaluieren jetzt Alternativen, während noch Zeit für eine durchdachte Migration zu Plattformen bleibt, die ihre Investitionen schützen und Versprechen einhalten.

Organisationen investieren in selbstverwaltete Deployments, weil sie Kontrolle, Compliance und Anpassungsfähigkeit benötigen. Wenn Anbieter diese Fähigkeiten abkündigen, entfernen sie nicht nur Features, sondern die grundlegende Fähigkeit, Umgebungen entsprechend der Geschäftsanforderungen zu wählen.

Moderne DevSecOps-Plattformen sollten vollständige Funktionalität bieten, die Deployment-Anforderungen respektiert, Toolchains konsolidiert und Software-Delivery beschleunigt – ohne Kompromisse bei Sicherheit oder Datensouveränität zu erzwingen.

Sprich noch heute mit unserem Vertrieb über alle Migrationsoptionen oder erkunde unsere umfassenden Migrationsressourcen, um zu sehen, wie tausende Organisationen bereits migriert sind.

Alternativ bieten wir einen kostenlosen 30-tägigen Test von GitLab Ultimate mit GitLab Duo Enterprise an, damit du live erleben kannst, was eine einheitliche DevSecOps-Plattform für deine Organisation leisten kann.

Weitere technische Details zur Migration und Deployment-Architektur finden sich im englischen original Blogpost.

Diese vier Ansätze zeigen, wie sich typische Herausforderungen der Embedded-Entwicklung mit GitLab adressieren lassen.

1. Dependency-Management für Embedded-Systeme

Embedded-Projekte nutzen häufig spezialisierte Bibliotheken und Hardware-spezifische Abhängigkeiten. Das manuelle Tracking dieser Dependencies ist fehleranfällig und erschwert die Nachvollziehbarkeit – ein kritischer Aspekt für Compliance-Audits.

GitLab bietet mehrere Ansätze für systematisches Dependency-Management:

Dependency Scanning: GitLab scannt automatisch die Abhängigkeiten im Projekt und identifiziert bekannte Sicherheitslücken. Die Ergebnisse erscheinen direkt in Merge Requests, sodass Probleme frühzeitig adressiert werden können.

Dependency-Proxy: Der GitLab Dependency-Proxy cached externe Abhängigkeiten lokal. Das reduziert die Abhängigkeit von externen Repositories und verbessert die Build-Performance – besonders relevant für große Embedded-Projekte mit vielen Dependencies.

Container Registry: Viele Embedded-Toolchains lassen sich in Container-Images paketieren. Die GitLab Container Registry ermöglicht versioniertes Management dieser Images, sodass alle Teammitglieder mit identischen Build-Umgebungen arbeiten.

Dieser systematische Ansatz ist beispielsweise relevant für deutsche Entwicklungsteams in regulierten Branchen, wo Nachvollziehbarkeit und Audit-Trails zu den Compliance-Anforderungen gehören.

2. Sicherheitsscans für Embedded-Code

Embedded-Systeme sind zunehmend vernetzt und damit potenzielle Angriffsziele. Sicherheitslücken in Embedded-Software können schwerwiegende Folgen haben – von Datenlecks bis hin zu Safety-Risiken in kritischen Systemen.

GitLab integriert mehrere Scan-Mechanismen in die CI/CD-Pipeline:

Static Application Security Testing (SAST): SAST analysiert den Source Code auf bekannte Sicherheitsmuster und Schwachstellen. Für C/C++ – die dominierenden Sprachen in der Embedded-Entwicklung – unterstützt GitLab mehrere SAST-Analyzer.

Secret Detection: Embedded-Projekte enthalten oft API-Keys für Cloud-Services oder Hardware-Zugangsdaten. GitLabs Secret Detection identifiziert versehentlich committete Credentials automatisch.

Dependency Scanning: Wie bereits erwähnt, scannt GitLab auch Dependencies auf bekannte CVEs – essentiell, da Embedded-Projekte oft Legacy-Bibliotheken nutzen.

Die Security-Findings erscheinen zentral im Security Dashboard und in Merge Requests. Teams können Vulnerabilities priorisieren, Verantwortlichkeiten zuweisen und den Remediation-Progress tracken.

3. Compliance-Automatisierung

Embedded-Entwicklung in regulierten Branchen erfordert strikte Compliance mit Standards wie ISO 26262 (Automotive), IEC 62304 (Medizintechnik) oder DO-178C (Luftfahrt). Die manuelle Dokumentation von Compliance-Prozessen ist zeitaufwändig und fehleranfällig.

GitLab ermöglicht Compliance-Automatisierung auf mehreren Ebenen:

Compliance Pipelines: Mit Compliance-Frameworks lassen sich Pipeline-Policies zentral definieren und durchsetzen. Beispielsweise kann eine Policy verlangen, dass alle Builds bestimmte Sicherheitsscans durchlaufen oder dass Code-Reviews von mindestens zwei Personen genehmigt werden.

Audit Events: GitLab loggt alle sicherheitsrelevanten Aktionen automatisch – von Code-Changes über Pipeline-Executions bis hin zu Access-Grants. Diese Audit-Trails sind für Compliance-Audits unverzichtbar.

Merge Request Approvals: Approval-Rules stellen sicher, dass kritischer Code vor dem Merge von autorisierten Personen reviewt wird. Das lässt sich beispielsweise nach Code-Ownership-Bereichen oder Compliance-Anforderungen konfigurieren.

Protected Branches: Produktions-Branches lassen sich gegen direkte Commits schützen. Änderungen müssen durch definierte Approval- und Testing-Prozesse gehen.

Diese Automatisierung reduziert den manuellen Aufwand für Compliance-Dokumentation erheblich und schafft gleichzeitig eine nachvollziehbare, audit-fähige Entwicklungshistorie.

4. Build-Optimierung für Embedded-Projekte

Embedded-Builds sind oft langwierig – Cross-Compilation, Hardware-spezifische Toolchains und umfangreiche Test-Suites summieren sich. Lange Build-Zeiten beeinträchtigen die Entwicklerproduktivität und verlangsamen Entwicklungszyklen.

GitLab bietet mehrere Ansätze zur Build-Optimierung:

Parallel Jobs: GitLab-Pipelines lassen sich parallelisieren. Statt sequenzieller Builds können unabhängige Jobs gleichzeitig laufen – beispielsweise Tests für verschiedene Hardware-Targets.

Caching: GitLab-Runner unterstützen Caching von Build-Artefakten und Dependencies. Das vermeidet redundante Downloads und Kompilierungen über mehrere Pipeline-Runs hinweg.

Distributed Runners: Für größere Teams lassen sich mehrere GitLab-Runner bereitstellen. Jobs werden automatisch auf verfügbare Runner verteilt, sodass mehrere Entwickler parallel arbeiten können ohne Wartezeiten.

Merge Request Pipelines: Pipelines lassen sich so konfigurieren, dass sie nur bei Merge Requests laufen – nicht bei jedem einzelnen Commit. Das spart Ressourcen für experimentelle Branches.

Die Kombination dieser Ansätze kann Build-Zeiten erheblich reduzieren und ermöglicht schnellere Entwicklungszyklen – selbst bei komplexen Embedded-Projekten mit mehreren Hardware-Targets.

Embedded-Entwicklung systematisch angehen

Die vier beschriebenen Ansätze adressieren zentrale Herausforderungen der Embedded-Entwicklung: Dependency-Management für Supply-Chain-Security, automatisierte Sicherheitsscans für vernetzte Systeme, Compliance-Automatisierung für regulierte Branchen und Build-Optimierung für effiziente Entwicklungszyklen.

GitLab integriert diese Capabilities in eine einheitliche Plattform. Teams müssen keine separaten Tools für Dependency-Scanning, Security-Testing, Compliance-Tracking und CI/CD orchestrieren – alles läuft in einem System mit einheitlicher Datenbasis.

Mehr Details zu GitLabs Embedded-Development-Capabilities gibt es in der englischen Originaldokumentation. Für spezifische Fragen zu Sicherheitsscans, Compliance-Features oder Pipeline-Optimierung stehen die GitLab-Docs zur Verfügung.

GitLabs Managed Lifecycle Environments lösen diese Herausforderungen systematisch. Durch automatisierte virtuelle Umgebungen beschleunigt GitLab Embedded-Entwicklungszyklen ohne die typische Konfigurationskomplexität und Kostenexplosion. Für Teams, die mit komplexen Test-Setups arbeiten – etwa MATLAB/Simulink MIL-Tests oder Testing auf spezialisierten Prozessoren wie Infineon AURIX – bietet dieser Ansatz messbare Vorteile.

Die Herausforderungen virtueller Testumgebungen

Virtuelle Testumgebungen – simulierte Hardware-Setups, die das Verhalten von Embedded-Systemen und reale Bedingungen nachbilden – können Hardware-Engpässe reduzieren. Teams testen Firmware auf simulierten Prozessoren, führen Model-in-the-Loop (MIL) Tests in MATLAB/Simulink durch oder verifizieren Software auf virtuellen Embedded-Systemen ohne physischen Hardware-Zugriff.

Die meisten Teams implementieren virtuelle Umgebungen jedoch mit einem von zwei gängigen Ansätzen, die beide zu nicht nachhaltigen Problemen führen.

Problematischer Ansatz 1: Pipeline Lifecycle Environments

Pipeline Lifecycle Environments erstellen die gesamte Testumgebung für jeden CI/CD-Durchlauf neu. Bei Code-Änderungen provisioniert das System Infrastruktur, installiert Software-Simulationen und konfiguriert alles von Grund auf, bevor Tests laufen.

Dieser Ansatz funktioniert für einfache Szenarien, wird aber mit steigender Komplexität ineffizient. Betrachte beispielsweise Software-in-the-Loop (SIL) Tests in einer komplexen virtuellen Umgebung. Jeder Pipeline-Durchlauf erfordert die vollständige Neuerstellung der Umgebung, einschließlich virtueller Prozessor-Provisionierung, Toolchain-Installationen und Zielkonfigurationen. Diese Prozesse verschlingen erhebliche Zeit.

Mit zunehmend anspruchsvolleren virtuellen Hardware-Konfigurationen für Embedded-Systeme summieren sich die Provisionierungskosten schnell.

Um diese Rebuild-Kosten und Verzögerungen zu vermeiden, setzen viele Teams auf langlebige Umgebungen, die zwischen Testläufen bestehen bleiben. Diese bringen jedoch eigene Nachteile mit sich.

Problematischer Ansatz 2: Long-lived Environments

Long-lived Environments bleiben dauerhaft bestehen, um ständige Neuaufbauten zu vermeiden. Entwickler(innen) fordern diese Umgebungen bei IT- oder DevOps-Teams an, warten auf Genehmigung und benötigen dann manuelle Provisionierung der Infrastruktur. Diese Umgebungen sind an einzelne Entwickler(innen)/Teams gebunden statt an spezifische Code-Änderungen und unterstützen laufende Entwicklungsarbeit über mehrere Projekte hinweg.

Dies eliminiert zwar den Rebuild-Overhead, erzeugt aber Umgebungs-Wildwuchs. Umgebungen akkumulieren ohne klares Enddatum. Infrastrukturkosten steigen, da Umgebungen unbegrenzt Ressourcen verbrauchen.

Long-lived Environments leiden zudem unter "Config Rot" – Umgebungen behalten Einstellungen, gecachte Daten oder Software-Versionen früherer Tests, die nachfolgende Ergebnisse beeinflussen können. Ein Test, der fehlschlagen sollte, wird durch Rückstände vorheriger Tests erfolgreich.

Letztlich ist die Verwaltung langlebiger Umgebungen ein manueller Prozess, der die Entwicklungsgeschwindigkeit bremst und den operativen Overhead erhöht.

GitLab bietet einen dritten Ansatz durch "Managed Lifecycle Environments". Dieser Ansatz vereint die Vorteile von langlebigen und Pipeline-Lifecycle-Umgebungen bei gleichzeitiger Vermeidung der Nachteile.

Die Lösung: Managed Lifecycle Environments

GitLabs Managed Lifecycle Environments binden virtuelle Test-Setups an Merge Requests (MRs) statt an Pipeline-Läufe oder einzelne Entwickler(innen). Man kann sie auch als "verwaltete MR-Testumgebungen" bezeichnen. Beim Erstellen eines MR für ein neues Feature orchestriert GitLab automatisch die Provisionierung notwendiger virtueller Testumgebungen. Diese Umgebungen bleiben während des gesamten Feature-Entwicklungsprozesses bestehen.

Die wichtigsten Vorteile

• Persistente Umgebungen ohne Neuaufbau: Die gleiche virtuelle Umgebung verarbeitet mehrere Pipeline-Läufe während der Feature-Iteration. Ob MIL-Tests in MATLAB/Simulink oder SIL-Tests auf spezialisierten Embedded-Prozessoren – die Umgebung bleibt konfiguriert und bereit.

• Automatische Bereinigung: Beim Merge des Features und Löschen des Branches löst GitLab automatisch die Umgebungsbereinigung aus und eliminiert Umgebungs-Wildwuchs.

• Single Source of Truth: Der MR dokumentiert alle Build-Ergebnisse, Testergebnisse und Umgebungs-Metadaten an einem Ort. Teammitglieder können Fortschritte verfolgen und zusammenarbeiten, ohne zwischen verschiedenen Tools oder Tabellen zu wechseln.

Dieses Übersichtsvideo zeigt, wie Managed Lifecycle Environments in der Praxis funktionieren:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/9tfyVPK5DuI?si=Kj_xXNo02bnFBDhy" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

GitLab automatisiert den gesamten Test-Workflow. Bei jedem Firmware-Test orchestriert GitLab Tests in der entsprechenden virtuellen Umgebung, dokumentiert Ergebnisse und bietet volle Transparenz über jeden Pipeline-Lauf. Dieser Ansatz verwandelt komplexes virtuelles Testen von einem manuellen, fehleranfälligen Prozess in automatisierte, zuverlässige Workflows.

Das Ergebnis: Teams erhalten wiederverwendbare Umgebungen ohne ausufernde Kosten. Sie steigern die Effizienz bei gleichzeitiger Aufrechterhaltung sauberer, isolierter Test-Setups für jedes Feature.

Hier ist eine Demo von Managed Lifecycle Environments für Firmware-Tests auf virtueller Hardware:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/iWdY-kTlpH4?si=D6rpoulr9sv6Sl6E" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Geschäftsnutzen

GitLabs Managed Lifecycle Environments liefern messbare Verbesserungen über Embedded-Entwicklungsworkflows hinweg. Teams, die MIL-Tests in MATLAB/Simulink und SIL-Tests auf spezialisierten Prozessoren wie Infineon AURIX oder BlackBerry QNX-Systemen durchführen, müssen nicht mehr zwischen ständigen Umgebungs-Neuaufbauten oder unkontrolliertem Umgebungs-Wildwuchs wählen. Stattdessen bleiben diese komplexen virtuellen Test-Setups während der Feature-Entwicklung bestehen und bereinigen sich automatisch bei Abschluss. Dies ermöglicht:

• Schnellere Produktentwicklungszyklen
• Kürzere Time-to-Market
• Niedrigere Infrastrukturkosten
• Höhere Qualitätssicherung

Virtuelle Testprozesse systematisch verbessern

Lade das Whitepaper "Unlocking agility and avoiding runaway costs in embedded development" herunter für eine tiefergehende Betrachtung von Managed Lifecycle Environments und erfahre, wie du Embedded-Entwicklungsworkflows nachhaltig beschleunigen kannst.

Weitere technische Details und Implementierungsbeispiele findest du im englischen original Blogpost.

Nutzer(innen) haben nun die Flexibilität, Claude Sonnet 4.5 neben anderen führenden Modellen auszuwählen und ihre GitLab Duo-Experience mit Verbesserungen in Tool-Orchestrierung, Kontext-Bearbeitung und domänenspezifischen Fähigkeiten zu erweitern. Mit Spitzenleistung auf SWE-bench Verified (77,2 %) und Stärken in Cybersecurity, Finanzen und forschungsintensiven Workflows können GitLab-Nutzer(innen) Claude Sonnet 4.5 einsetzen, um schärfere Einblicke und tieferen Kontext in ihre Entwicklungsarbeit zu bringen.

"Claude Sonnet 4.5 in GitLab zu haben, ist ein großer Gewinn für Entwickler(innen). Es ist ein wirklich leistungsfähiges Coding-Modell, und wenn du es mit der GitLab Duo Agent Platform verwendest, erhältst du smartere Hilfe direkt in deinen Workflows. Es ist die Art von Schritt, die Entwicklung einfacher macht", sagt Taylor McCaslin, Principal, Strategy and Operations for AI Partnerships bei GitLab.

GitLab Duo Agent Platform + Claude Sonnet 4.5

Die GitLab Duo Agent Platform erweitert die Leistungsfähigkeit von Claude Sonnet 4.5, indem sie Agenten orchestriert, sie mit internen Systemen verbindet und sie über den gesamten Software-Lebenszyklus integriert. Diese Kombination schafft eine einzigartig GitLab-Experience – in der fortschrittliches Reasoning und Problemlösung auf plattformweiten Kontext und Sicherheit treffen. Das Ergebnis ist schnellere Entwicklung, genauere Ergebnisse und stärkere organisatorische Abdeckung – alles direkt im GitLab-Workflow, den Entwickler(innen) täglich nutzen.

Wie du Claude Sonnet 4.5 nutzen kannst

Claude Sonnet 4.5 ist jetzt als Modelloption in GitLab Duo Agent Platform Agentic Chat auf GitLab.com verfügbar. Du kannst Claude Sonnet 4.5 aus dem Modellauswahl-Dropdown wählen, um seine Coding-Funktionen für deine Entwicklungsaufgaben zu nutzen.

{altText="Screenshot showing the model selection dropdown in GitLab Duo with Claude Sonnet 4.5 highlighted as an available option"}

Hinweis: Die Möglichkeit, Claude Sonnet 4.5 in unterstützten IDEs auszuwählen, wird bald verfügbar sein.

Leg los

GitLab Duo Pro- und Enterprise-Kund(inn)en können Claude Sonnet 4.5 ab sofort nutzen. Besuche unsere Dokumentation, um mehr über GitLab Duo-Funktionen und -Modelle zu erfahren.

Fragen oder Feedback? Teile deine Erfahrungen über die GitLab Community mit uns.

Willst du GitLab Ultimate mit Duo Enterprise ausprobieren? Melde dich noch heute für eine kostenlose Testversion an.

Was ist Shift Left Security?

Shift Left Security bezeichnet einen Ansatz in der Softwareentwicklung, bei dem Sicherheitsmaßnahmen möglichst früh im Entwicklungsprozess integriert werden.

Traditionell wurden Sicherheitstests erst am Ende des Softwareentwicklungszyklus (SDLC) durchgeführt, zum Beispiel in der Test- oder Produktionsphase. Dieses Vorgehen führt oft zu höheren Kosten und längeren Entwicklungszeiten, wenn kritische Sicherheitslücken spät entdeckt werden.

Mit dem Shift Left Ansatz wird das Thema Sicherheit nun auf der Zeitachse der Anwendungsentwicklung nach links verschoben, sodass anfälliger Code früh entdeckt werden kann. Ziel ist es, Schwachstellen schon in den frühen Phasen wie Planung, Design oder Codierung zu erkennen und zu beheben, statt sie erst im späteren Verlauf oder nach dem Deployment zu adressieren.

Der Shift Left Ansatz

Shift Left Security ist eine strategische Herangehensweise, bei der Sicherheit möglichst früh in den Entwicklungsprozess integriert wird – nicht durch ein einzelnes Tool, sondern durch eine Kombination verschiedener Maßnahmen.

Typischerweise werden dafür Sicherheitstools entlang des Entwicklungszyklus eingesetzt, darunter:

• SCA (Software Composition Analysis): SCA erkennt Schwachstellen und Lizenzrisiken in Open-Source-Komponenten, indem es Paketverwaltung, Manifestdateien, Binärdateien und Container-Images analysiert. Die Ergebnisse werden in einer Software-Stückliste (sog. Software Bill of Materials) zusammengeführt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen. So lassen sich Sicherheits- und Compliance-Probleme systematisch aufspüren und schnell adressieren.
• SAST (Static Application Security Testing): SAST ist ein White-Box-Verfahren, das den Quellcode analysiert, ohne die Anwendung auszuführen. Es spiegelt die Sichtweise von Entwickler(innen) wider und erkennt Schwachstellen früh im Softwareentwicklungszyklus, z. B. fehlende Eingabevalidierung oder unsichere Codemuster. Dadurch ist es besonders kosteneffizient. Laufzeit- oder umgebungsbezogene Probleme kann SAST allerdings nicht erfassen.
• DAST (Dynamic Application Security Testing): DAST ist ein Black-Box-Verfahren, das laufende Web-Anwendungen testet und sich an der Methodik potenzieller Angreifer(innen) orientiert. Es erkennt Schwachstellen wie XSS, fehlerhafte Authentifizierung oder Konfigurationsfehler zur Laufzeit – ohne Kenntnis des zugrundeliegenden Codes. DAST wird typischerweise in späten Phasen der Entwicklung oder in Testumgebungen eingesetzt und eignet sich ausschließlich für Web-Anwendungen und -Services.
• Secret Scanning: Shift Left Security umfasst auch das Scannen von Container-Images und serverlosen Funktionen, da moderne Anwendungen zunehmend in Containern ausgeführt oder über serverlose Architekturen bereitgestellt werden. Beim Scannen eines Container-Images wird der Inhalt auf Sicherheitslücken, Schwachstellen im Build-Prozess und fehlerhafte Konfigurationen geprüft. Ziel ist es, Probleme zu erkennen, bevor das Image in der Produktion verwendet wird. Das Scannen serverloser Funktionen erfordert spezielle Überwachungslösungen, die cloud-native Umgebungen abdecken und auch ohne klassische Serverinfrastruktur funktionieren.

Diese Tools können einzeln oder kombiniert verwendet werden. Effektiver ist jedoch eine automatisierte Sicherheitsplattform, die Risiken in allen Phasen des Entwicklungszyklus erkennt – von der Codierung bis zur Bereitstellung. So können DevOps-Teams Schwachstellen frühzeitig und systematisch beheben.

Lesetipp: SAST vs. DAST - Die Unterschiede erklärt

Vorteile der Shift Left Security

Die Linksverschiebung sicherheitsrelevanter Maßnahmen führt zu einer Reihe von Vorteilen für Unternehmen und Entwickler(innen).

• Frühzeitiges Erkennen von Sicherheitsrisiken: Durch Sicherheitsanalysen direkt im Code oder bei der Integration von Abhängigkeiten lassen sich Schwachstellen erkennen, bevor sie in produktive Systeme gelangen. Dies verschafft Entwickler(innen) mehr Zeit für die Reaktion und reduziert die potenzielle Bedrohung (beispielsweise durch Exploits oder Datenlecks) erheblich.
• Geringere Kosten für Fehlerbehebung: Je später ein Sicherheitsfehler entdeckt wird, desto teurer ist seine Behebung. Wird eine Schwachstelle bereits vor dem Build entdeckt, reicht oft eine einfache Codeänderung – ohne zusätzlichen Aufwand für Tests oder Deployments. Wird das Problem erst in der Produktion bemerkt, ist der Aufwand deutlich höher und der gesamte Prozess kann Wochen dauern. Frühes Eingreifen spart Zeit, senkt die Kosten und ermöglicht es Entwickler(innen), sich stärker auf neue Funktionen statt auf Notfallpatches zu konzentrieren.
• Schnellere Entwicklungszyklen: Sicherheitsprobleme lassen sich schneller beheben, solange sie nur im Quellcode bestehen. Wird ein Problem erst kurz vor dem Release oder in der Produktion entdeckt, verlängert sich der Behebungsprozess deutlich – mit der Gefahr, gesetzte Fristen zu verpassen und die Time-to-Market zu verlangsamen.
• Bessere Codequalität: Sicherheitsüberprüfungen fördern eine saubere Code-Architektur, konsistente Implementierung und verständlichen Code. So entstehen robuste und wartbare Anwendungen.
• Bessere Zusammenarbeit: Shift Left Security fördert die Zusammenarbeitzwischen Entwickler(innen) und Security-Teams. Wird ein Sicherheitsproblem früh im Quellcode erkannt, können beide Seiten gemeinsam daran arbeiten, ohne Schuldzuweisungen oder Zeitdruck. Das verbessert die Kommunikation und stärkt das gegenseitige Verständnis.
• Reduziertes Risiko im Live-Betrieb: Wird eine Schwachstelle erst im laufenden Betrieb entdeckt, sind schnelle und oft drastische Maßnahmen nötig – etwa das Abschalten der App. Wird die Schwachstelle hingegen bereits während der Entwicklung identifiziert, lässt sie sich mit geringem Aufwand und ohne größere Auswirkungen auf Nutzer(innen) beheben.

Wie Dunelm, der britische Marktführer für Haushaltswaren, die Sicherheit "nach links" geschoben hat, steht in dieser ausführlichen Case Study.

Best Practices für deinen Shift Left Security Ansatz

Shift Left Security erfordert die frühzeitige und umfassende Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess – idealerweise ab dem ersten Moment, in dem Entwickler(innen) mit dem Programmieren beginnen. Die Sicherheitsprüfung soll nicht nachgelagert, sondern integraler Bestandteil der täglichen Entwicklungsarbeit sein. Damit das gelingt, solltest du auf Best Practices zurückgreifen.

#1 Integration von Sicherheitsmaßnahmen in die CI/CD-Pipeline

Sicherheits-Scans sind ein zentrales Element des Shift-Left-Ansatzes. Ihre volle Wirkung entfalten sie aber nur, wenn die Ergebnisse unmittelbar in die DevOps-Toolkette eingebunden sind. Reports sollten direkt im CI/CD-Pipeline-Bericht angezeigt werden, sodass Entwickler(innen) sie ohne Umwege nutzen können. Zusätzlich sollte die Erstellung einer Software Bill of Materials (SBOM) automatisiert werden, um alle verwendeten Abhängigkeiten, Container-Images und serverlosen Funktionen transparent zu erfassen und systematisch auf bekannte Schwachstellen zu prüfen.

#2 Anwendung von Security-Tools in der Entwicklungsumgebung

Sicherheitsfunktionen sollten direkt in die Entwicklungsumgebung eingebunden werden, damit Schwachstellen bereits vor Übertragung in den Main Branch erkannt werden. Durch die Integration in die vertrauten Toolsets der Entwickler(innen) wird eine kontinuierliche Zusammenarbeit mit dem Security-Team ermöglicht und der Aufwand für nachträgliche Korrekturen deutlich reduziert.

#3 Schulung von Entwickler(innen)

Damit Entwickler(innen) die Anwendungssicherheit bereits frühzeitig im Prozess berücksichtigen, ist eine intensive Schulung notwendig. Entwicklerteams müssen verstehen, warum sie Sicherheitsprüfungen frühzeitig durchführen – und welchen Beitrag das zur Gesamtqualität und Stabilität der Anwendung leistet. Dazu eignen sich praxisnahe und rollenbezogene Schulungsformate wie z. B. Code Labs, Code Guidelines oder Hands-on-Training.

#4 Integration von Security Reviews in Code Reviews und Pull Requests

Sicherheit sollte auch Teil von Code Reviews sein. Teams können z. B. Checklisten mit sicherheitsrelevanten Aspekten verwenden. Pair Programming bietet zusätzlich die Möglichkeit, Sicherheit direkt beim Schreiben des Codes mitzudenken – vor allem in frühen Projektphasen.

HackerOne + GitLab: Setze Shift Left Security einfach und kostengünstig um

Eine der größten Herausforderungen für die Umsetzung der Shift Left Sicherheit für Entwicklerteams ist eine aufgeblähte Toolchain. Der Wechsel zwischen Tools und unklare Rollenverteilungen können die frühzeitige Integration von Sicherheitsüberprüfungen behindern.

GitLab bietet mit HackerOne eine integrierte Lösung, die Security-Teams und Entwickler(innen) effektiv verbindet. Sicherheitslücken, die über HackerOne gemeldet und validiert werden, werden automatisch in GitLab als Tickets angelegt. Diese enthalten unter anderem:

• Synchronisation von Kommentaren
• Statusänderungen
• Zuständigkeiten
• Belohnungen
• Fälligkeitsdaten

Die Kommunikation erfolgt dabei bidirektional zwischen beiden Plattformen. Die Integration ermöglicht es somit Entwickler(innen), im gewohnten Workflow zu bleiben und Sicherheitslücken direkt zu bearbeiten.

Auswirkungen der automatisierten Sicherheitsintegration

Die Integration von HackerOne und GitLab führt in der Praxis zu:

• Bis zu 70 Prozent Zeitersparnis von der Entdeckung bis zur Behebung von Schwachstellen
• Erhöhte Transparenz über den Sicherheitsstatus im gesamten Unternehmen
• Effektivere Nutzung der Ressourcen im Security-Team
• Gesteigerte Zufriedenheit der Entwickler(innen), da sie im bevorzugten Workflow bleiben können

Keine Kompromisse bei der Shift Left Security

Shift Left Security verschiebt das Thema Sicherheit weg von der Endkontrolle hin zur kontinuierlichen Begleitung des Entwicklungsprozesses. Durch Tools wie SAST, DAST, SCA und Container-Scanning lassen sich Schwachstellen frühzeitig identifizieren – noch bevor sie produktiv wirksam werden. Das senkt Kosten, reduziert Risiken und beschleunigt Entwicklungszyklen.

Erfolgreich ist dieser Ansatz jedoch nur, wenn Sicherheitsprüfungen eng in die CI/CD-Pipeline und Entwicklungsumgebungen integriert werden und Entwickler(innen) durch gezielte Schulungen und klare Prozesse unterstützt werden. Die Fallstudie zu GitLab und HackerOne zeigt zudem, dass integrierte Plattformen Kontextwechsel vermeiden und die Effizienz deutlich steigern können. Entscheidend für eine nachhaltige Umsetzung ist eine Sicherheitskultur, in der Entwicklung und Security partnerschaftlich und auf Augenhöhe zusammenarbeiten.

Wir glauben, dass diese Anerkennung unsere umfassende Plattformstrategie in einem kritischen Moment für die Softwareentwicklung bestätigt. Unternehmen wetteifern darum, KI-gestützte Funktionen zu übernehmen und gleichzeitig Sicherheit, Compliance und operative Exzellenz aufrechtzuerhalten. Erfolg erfordert einen einheitlichen Plattformansatz, der die Art und Weise transformiert, wie Teams zusammenarbeiten und Mehrwert liefern.

Ob unsere Kunden agile Software bereitstellen, Cloud-native Anwendungen entwickeln oder Plattformen konstruieren – GitLab ermöglicht es ihnen, im Einklang mit KI-Agenten zusammenzuarbeiten, um sichere und zuverlässige Software schneller zu liefern.

<p></p>

Lade den Report herunter, um mehr zu erfahren.

Schnellere Time-to-Value

Unsere Mission ist es, allen zu ermöglichen, zur Software beizutragen und sie mitzugestalten, die unsere Welt antreibt. Das rasante Tempo unserer Innovationsagenda zeigt, dass wir noch lange nicht fertig sind. Wir haben unseren Kunden über 150 Monate hinweg jeden Monat neue Lösungen geliefert, und diese Tradition wird fortgesetzt.

Während wir die Branche anführen, bleiben wir unserem Engagement treu, unseren Kunden dabei zu helfen, diese neuen Funktionen in Geschäftswert umzusetzen.

Wir sind fest davon überzeugt, dass in dieser Ära beschleunigter KI-gestützter Innovation im gesamten Technologie-Ökosystem ein einheitlicher Plattformansatz zur Bewältigung der schwierigsten Engineering-Herausforderungen unserer Kunden wichtiger denn je ist. Dieser Ansatz ermöglicht es Organisationen, Integrations-Overhead zu reduzieren, Sicherheitslücken zu schließen und Innovationen zu übernehmen, ohne bestehende Software-Delivery-Workflows zu stören.

Hier sind einige Beispiele:

• Beschleunige Releases mit agentischer KI: Fragmentierte Toolchains verlangsamen Code Reviews und Tests. GitLab Duo Agents und Flows automatisieren Aufgaben wie Code Reviews, Testgenerierung und Vulnerability Triage im Kontext der vollständigen Plattform und helfen Teams, Zykluszeiten zu verkürzen und die Qualität zu verbessern.
• Von Anfang an sicher entwickeln: Viele Organisationen behandeln Sicherheit als nachträglichen Gedanken, was zu kostspieliger Nacharbeit und Compliance-Lücken führt. GitLab bettet Scanning, Policy-Durchsetzung und Compliance-Checks in alltägliche Workflows ein und erkennt Risiken früher, ohne Entwickler auszubremsen.
• Mit Flexibilität deployen: Teams mit strengen regulatorischen oder operativen Einschränkungen benötigen Deployment-Optionen jenseits von Multi-Tenant-SaaS. GitLab unterstützt SaaS, Self-Managed, Air-Gapped und FedRAMP Moderate autorisierte Umgebungen und stellt sicher, dass Kunden die Kontrolle behalten, wo Wettbewerber das nicht können.
• Konsistente Innovation liefern: Tool-Fragmentierung macht die Übernahme neuer Features riskant und störend. GitLabs monatliche Releases liefern neue Funktionen wie GitLab Duo Agent Platform, erweiterte KI-Governance und Cloud-Integrationen, die Teams ohne Umrüstung übernehmen können.

Kundenanwendungsfälle, die wirklich zählen

GitLab unterstützt die folgenden Innovationsbereiche:

• Integriertes Toolset für Cloud-native Bereitstellung und Unternehmensskalierung
• Erweiterte Planungstools und umfangreiche Sicherheitsfunktionen
• Package Management und Feature Flags für progressive Bereitstellung
• Value Stream Metriken für Sichtbarkeit und Verbesserung über den gesamten Lebenszyklus
• KI-native Workflows, direkt in tägliche Aufgaben eingebettet

Diese Vielseitigkeit führt zu echtem Kundenwert, wie Bal Kang, Engineering Platform Lead bei NatWest, erklärt:

„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 verstehen Absichten, zerlegen Probleme und werden aktiv – sie werden zu echten Mitarbeitern unserer Teams."

Die Verlagerung hin zu einheitlichen Plattformen stellt eine grundlegende Veränderung dar, wie Organisationen an die Softwareentwicklung herangehen. Wir glauben, dass Gartner® uns deshalb kürzlich auch als Leader im 2025 Magic Quadrant™ für AI Code Assistants ausgezeichnet hat.

Da Unternehmen die Entwicklerproduktivität sicher maximieren und Innovation beschleunigen möchten, wird ein umfassender Plattformansatz dringender denn je.

Lade den Report herunter, um mehr zu erfahren.

GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen Tochtergesellschaften in den USA und international, und MAGIC QUADRANT ist eine eingetragene Marke von Gartner, Inc. und/oder seinen Tochtergesellschaften und wird hier mit Genehmigung verwendet. Alle Rechte vorbehalten.

Gartner befürwortet keinen Anbieter, kein Produkt oder keine Dienstleistung, die in seinen Forschungspublikationen dargestellt werden, und rät Technologiebenutzern nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Bezeichnungen auszuwählen. Gartner-Forschungspublikationen bestehen aus den Meinungen der Forschungsorganisation von Gartner und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Garantien in Bezug auf diese Forschung ab, einschließlich jeglicher Garantien der Marktgängigkeit oder Eignung für einen bestimmten Zweck.

Diese Grafik wurde von Gartner Inc. als Teil eines größeren Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage bei Gartner B.V. erhältlich.

Quelle: Gartner, Magic Quadrant for DevOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, 22. September 2025

Mit GitLab 18.3 haben wir das Fundament für echte Mensch-KI-Zusammenarbeit gelegt. Wir integrierten führende KI-Tools wie Claude Code, Codex CLI, Amazon Q CLI und Gemini CLI nativ in GitLab, lieferten unsere erste Vorschau des GitLab Model Context Protocol (MCP)-Servers in Partnerschaft mit Cursor und veröffentlichten zwei neue Flows – Issue to MR und Convert CI File for Jenkins Flows – um Teams bei alltäglichen Herausforderungen zu unterstützen.

Mit GitLab 18.4 erweitern wir deine Möglichkeiten, eigene Agents zu erstellen und zu teilen, effektiver durch Agentic Chat zusammenzuarbeiten, Codebasen mit dem Knowledge Graph zu navigieren und Pipelines mit dem Fix Failed Pipelines Flow grün zu halten – während wir gleichzeitig mehr Sicherheit und Governance für deine KI-Nutzung bieten.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1120293274?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.4 Release video placeholder"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Hast du Fragen zu den neuesten Features in GitLab 18.4? Sei bei The Developer Show dabei – live auf LinkedIn am 23. September um 10:00 Uhr PT (19:00 Uhr in Europa) oder kurz danach auf Abruf!

Gestalte deine Experience

Starte deinen Tag mit dem AI Catalog – einer Bibliothek spezialisierter Agents, die Prioritäten aufzeigen, Routinearbeit automatisieren und dich auf das Wesentliche fokussiert halten.

AI Catalog als deine Bibliothek spezialisierter Agents

Mit GitLab 18.4 führen wir den GitLab Duo AI Catalog ein – eine zentrale Bibliothek, in der Teams maßgeschneiderte Agents erstellen, teilen und unternehmensweit nutzen können. Jedes Team hat seine eigene Arbeitsweise. Ein Custom Agent zu erstellen ist daher wie das Einarbeiten eines neuen Kollegen in die „richtige" Arbeitsweise deiner Organisation.

Zum Beispiel kann ein Custom Product Planning Agent Bugs im spezifischen Format mit deinen Labeling-Standards erfassen, ein Technical Writer Agent kann prägnante Dokumentation nach deinen Konventionen verfassen, oder ein Security Agent stellt sicher, dass deine Sicherheits- und Compliance-Standards bei jedem MR eingehalten werden. Statt als isolierte Tools zu funktionieren, werden diese Agents Teil des natürlichen Arbeitsflusses in GitLab – sie beschleunigen Aufgaben ohne etablierte Prozesse zu stören.

Hinweis: Diese Funktion ist derzeit nur auf GitLab.com verfügbar. Für Self-Managed-Kunden planen wir die Bereitstellung nächsten Monat mit Release 18.5.

Bleib im Flow

GitLab Duo Agentic Chat macht die Zusammenarbeit mit Agents nahtlos.

Smarterer Agentic Chat für optimierte Zusammenarbeit mit Agents

Als Herzstück der GitLab Duo Agent Platform bietet dir Agentic Chat eine nahtlose Möglichkeit, mit KI-Agents zusammenzuarbeiten. Das neueste Update des Agentic Chat mit GitLab 18.4 verbessert das Chat-Erlebnis und erweitert die Verwaltung und Darstellung von Sessions.

• Chat mit Custom Agents

  Starten wir mit deinem neu erstellten Custom Agent. Einmal designt, kannst du diesen Agent sofort über Agentic Chat einsetzen. Du könntest deinen neuen Agent beispielsweise fragen: „Zeig mir meine Aufgaben für heute", um mit deinen Prioritäten zu starten. Zusätzlich hast du jetzt die Möglichkeit, neue Unterhaltungen mit neuen Agents zu beginnen und vorherige Unterhaltungen fortzusetzen, ohne den Kontext zu verlieren.

• Modellauswahl für Nutzer

  Mit früheren Releases konntest du Modelle auf Namespace-Ebene auswählen, aber mit 18.4 kannst du nun Modelle auf Nutzerebene für eine bestimmte Chat-Session wählen. Das ermächtigt dich, zu entscheiden, welches LLM für die jeweilige Aufgabe geeignet ist, oder mit verschiedenen LLMs zu experimentieren, um zu sehen, welches die beste Antwort für deine Aufgabe liefert.

• Verbesserte Formatierung und visuelles Design

  Wir hoffen, du liebst das neue visuelle Design für GitLab Duo Agentic Chat, einschließlich verbesserter Handhabung von Tool-Call-Genehmigungen für ein angenehmeres Erlebnis.

• Agent Sessions verfügbar über Agentic Chat

  Sessions werden zu einem zentralen Bestandteil des Agentic Chat-Erlebnisses. Jeder Agent-Run oder Flow erscheint nun in der Sessions-Übersicht, die über Agentic Chat verfügbar ist. In jeder Session siehst du detaillierte Informationen wie Job-Logs, Nutzerinformationen und Tool-Metadaten – das bietet wichtige Transparenz darüber, wie Agents in deinem Auftrag arbeiten.

  Hinweis: Sessions in Agentic Chat ist nur auf GitLab.com verfügbar. Diese Verbesserung ist für Self-Managed-Kunden nächsten Monat im 18.5-Update geplant.

Erschließe deine Codebase

Bei Agents ist Kontext entscheidend. Mit Knowledge Graph gibst du deinen Agents mehr Kontext, damit sie schneller analysieren und dir bessere Ergebnisse liefern können.

Neu: Der GitLab Knowledge Graph (Beta)

Der GitLab Knowledge Graph in 18.4 transformiert, wie Entwickler und Agents komplexe Codebasen verstehen und navigieren. Der Knowledge Graph bietet eine vernetzte Karte deines gesamten Projekts und verknüpft Dateien, Routen und Referenzen über den Software-Entwicklungszyklus hinweg. Durch Tools wie Go-to-Definition, Codebase-Suche und Referenz-Tracking über In-Chat-Queries erhalten Entwickler die Möglichkeit, präzise Fragen zu stellen wie „Zeig mir alle Route-Dateien" oder „Was ist noch von dieser Änderung betroffen?"

Dieser tiefere Kontext hilft Teams, schneller und mit mehr Vertrauen zu arbeiten – egal ob es um das Onboarding neuer Mitwirkender geht, tiefgehende Recherche in einem Projekt oder die Untersuchung, wie eine Änderung abhängigen Code beeinflusst. Je mehr von deinem Ökosystem in GitLab lebt, desto mächtiger wird der Knowledge Graph und gibt sowohl Menschen als auch KI-Agents das Fundament, mit Genauigkeit, Geschwindigkeit und vollem Projektbewusstsein zu bauen. In zukünftigen Releases werden wir alle deine GitLab-Daten in den Knowledge Graph einbinden, einschließlich Plans, MRs, Sicherheitslücken und mehr.

Dieses Release des Knowledge Graph fokussiert sich auf lokale Code-Indexierung, bei der das gkg CLI deine Codebase in eine lebendige, einbettbare Graph-Datenbank für RAG verwandelt. Du kannst es mit einem einfachen Einzeiler-Script installieren, lokale Repositories parsen und über MCP verbinden, um deinen Workspace abzufragen.

Unsere Vision für das Knowledge Graph-Projekt ist zweigeteilt: Wir bauen eine lebendige Community Edition, die Entwickler heute schon lokal ausführen können, die als Fundament für einen zukünftigen, vollständig integrierten Knowledge Graph Service innerhalb von GitLab.com und Self-Managed-Instanzen dienen wird.

Automatisiere deine Pipeline-Wartung

Behebe Pipeline-Fehler schneller und bleib im Flow mit dem Fix Failed Pipelines Flow.

Fix Failed Pipelines Flow mit Business-Bewusstsein

Pipelines grün zu halten ist entscheidend für deine Entwicklungsgeschwindigkeit, aber traditionelle Ansätze konzentrieren sich nur auf technische Fehlersuche ohne Berücksichtigung der geschäftlichen Auswirkungen. Der Fix Failed Pipelines Flow adressiert diese Herausforderung, indem er technische Analyse mit strategischem Kontext kombiniert. Er kann beispielsweise automatisch priorisieren, eine fehlgeschlagene Deployment-Pipeline für einen kundenorientierten Service vor einem nächtlichen Test-Job zu reparieren oder Build-Probleme in einem hochpriorisierten Release-Branch anders zu kennzeichnen als in experimentellen Feature-Branches.

• Business-bewusste Fehlererkennung überwacht Pipeline-Ausführungen und versteht dabei die Bedeutung verschiedener Workflows und Deployment-Ziele.
• Kontextuelle Ursachenanalyse analysiert Fehlerprotokolle zusammen mit Geschäftsanforderungen, kürzlichen Änderungen und projektübergreifenden Abhängigkeiten, um die zugrunde liegenden Ursachen zu identifizieren.
• Strategische Fix-Priorisierung generiert geeignete Fixes unter Berücksichtigung von geschäftlichen Auswirkungen, Deadlines und Prioritäten bei der Ressourcenzuweisung.
• Workflow-integrierte Lösung erstellt automatisch Merge Requests mit Fixes, die ordnungsgemäße Review-Prozesse beibehalten und gleichzeitig geschäftlichen Kontext für Priorisierungsentscheidungen liefern.

Dieser Flow hält Pipelines grün und wahrt dabei die strategische Ausrichtung, sodass automatisierte Fixes Geschäftsziele unterstützen, anstatt nur technische Probleme isoliert zu lösen.

Personalisiere deine KI-Umgebung

Automatisierung funktioniert nur, wenn du den Modellen dahinter vertraust. Deshalb liefert 18.4 Governance-Features wie Modellauswahl und GitLab-verwaltete Schlüssel.

GitLab Duo Modellauswahl zur Optimierung der Feature-Performance

Die Modellauswahl ist jetzt allgemein verfügbar und gibt dir direkte Kontrolle darüber, welche Large Language Models (LLMs) GitLab Duo antreiben. Du und dein Team könnt die Modelle eurer Wahl auswählen, sie unternehmensweit anwenden oder pro Feature anpassen. Du kannst Standards setzen, um Konsistenz über Namespaces und Tools hinweg zu gewährleisten, mit Governance-, Compliance- und Sicherheitsanforderungen im Blick.

Für Kunden, die GitLab Duo Self-Hosted nutzen, bietet die neu hinzugefügte Unterstützung für GPT OSS und GPT-5 zusätzliche Flexibilität für KI-gestützte Entwicklungs-Workflows.

Hinweis: GitLab Duo Self-Hosted ist für GitLab.com-Kunden nicht verfügbar, und GPT-Modelle werden auf GitLab.com nicht unterstützt.

Schütze deinen sensiblen Kontext

Neben Governance kommt Datenschutz, der dir feingranulare Kontrolle darüber gibt, was KI sehen kann und was nicht.

GitLab Duo Context Exclusion für granularen Datenschutz

Es ist keine Überraschung – du brauchst granulare Kontrolle darüber, auf welche Informationen KI-Agents zugreifen können. GitLab Duo Context Exclusion in 18.4 bietet Einstellungen auf Projektebene, mit denen Teams bestimmte Dateien oder Dateipfade vom KI-Zugriff ausschließen können. Zu den Funktionen gehören:

• Datei-spezifische Ausschlüsse zum Schutz sensibler Dateien wie Passwort-Konfigurationen, Secrets und proprietäre Algorithmen.
• Pfad-basierte Regeln zur Erstellung von Ausschlussmustern basierend auf Verzeichnisstrukturen oder Dateinamenskonventionen.
• Flexible Konfiguration zur Anwendung von Ausschlüssen auf Projektebene bei gleichzeitiger Aufrechterhaltung der Entwicklungs-Workflow-Effizienz.
• Audit-Sichtbarkeit zur Verfolgung, welche Inhalte ausgeschlossen sind, um die Einhaltung von Daten-Governance-Richtlinien zu unterstützen.

GitLab Duo Context Exclusion hilft dir, sensible Daten zu schützen, während du die Entwicklung mit agentischer KI beschleunigst.

Erweitere deine KI-Fähigkeiten mit neuen MCP-Tools

Erweiterte MCP-Tools erweitern diese Fähigkeiten noch weiter und verbinden deine GitLab-Umgebung mit einem breiteren Ökosystem intelligenter Agents.

Neue Tools für GitLab MCP Server

Aufbauend auf dem in 18.3 eingeführten initialen MCP-Server fügt GitLab 18.4 weitere MCP-Tools hinzu – Funktionen, die definieren, wie MCP-Clients mit GitLab interagieren. Diese neuen Tools erweitern die Integrationsmöglichkeiten und ermöglichen sowohl First-Party- als auch Third-Party-KI-Agents, komplexere Aufgaben zu übernehmen, wie den Zugriff auf Projektdaten, die Durchführung von Code-Operationen oder die Suche über Repositories hinweg – alles unter Beachtung bestehender Sicherheits- und Berechtigungsmodelle. Eine vollständige Liste der MCP-Tools, einschließlich der neuen Ergänzungen in 18.4, findest du in unserer MCP-Server-Dokumentation.

Erlebe die Zukunft der intelligenten Software-Entwicklung

Mit der GitLab Duo Agent Platform können Ingenieure von der Arbeit an einzelnen Issues in sequenzieller Weise zu Multi-Thread-Zusammenarbeit mit asynchronen Agents übergehen, die wie Teamkollegen agieren, um Arbeit schneller zu erledigen. Wir bringen diese einzigartige Vision mit den Präferenzen unserer Kunden für Unabhängigkeit und Wahlfreiheit auf den Markt: Betreibe sie in deinen bevorzugten Cloud-Umgebungen mit den LLMs und KI-Tools, die für dich am besten funktionieren, innerhalb der von dir festgelegten Sicherheits- und Compliance-Leitplanken.

Als integraler Bestandteil dieser Innovation ist GitLab 18.4 mehr als ein Software-Upgrade – es geht darum, das tägliche Erlebnis von Entwicklern reibungsloser, smarter und sicherer zu gestalten. Von wiederverwendbaren Agents bis zu business-bewussten Pipeline-Fixes ist jedes Feature darauf ausgelegt, Teams im Flow zu halten und gleichzeitig Geschwindigkeit, Sicherheit und Kontrolle auszubalancieren. Für einen tieferen Einblick, wie diese Funktionen in der Praxis zusammenkommen, schau dir unser Walkthrough-Video an.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1120288083?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="A day in the life with GitLab Duo Agent Platform"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

GitLab Premium- und Ultimate-Nutzer können diese Funktionen heute auf GitLab.com und in Self-Managed-Umgebungen nutzen, mit Verfügbarkeit für GitLab Dedicated-Kunden nächsten Monat.

Aktiviere Beta- und experimentelle Features in GitLab Duo Agent Platform heute und erlebe, wie Full-Context-KI die Art und Weise transformieren kann, wie deine Teams Software bauen. Neu bei GitLab? Starte deine kostenlose Testversion und entdecke, warum die Zukunft der Entwicklung KI-gestützt, sicher und durch die weltweit umfassendste DevSecOps-Plattform orchestriert ist.

Bleib auf dem neuesten Stand mit GitLab

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

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

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

Für Organisationen, die einen Hands-off-Ansatz wünschen, bietet sich GitLabs Managed Maintenance Service an. Mit Managed Maintenance bleibt dein Team auf Innovation fokussiert, während GitLab-Experten deine Self-Managed-Instanz zuverlässig aktualisiert, sicher und bereit für die Führung in DevSecOps halten. Frage deinen Account Manager nach weiteren Informationen.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in diesen Aussagen reflektierten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass tatsächliche Ergebnisse oder Resultate wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren findest du unter der Überschrift „Risk Factors" in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu überarbeiten, außer wenn gesetzlich erforderlich.

Static Code Analysis erkennt nur Schwachstellen im Quellcode. Runtime-Sicherheitsprobleme bleiben verborgen, wenn Anwendungen mit realen Umgebungen, Drittanbieter-Services und Benutzer-Workflows interagieren. Dynamic Application Security Testing (DAST) schließt diese Lücke. GitLab DAST automatisiert Penetrationstests in CI/CD-Pipelines und validiert Sicherheit kontinuierlich ohne Workflow-Unterbrechung.

Warum DAST für deutsche Unternehmen?

DAST testet Anwendungen in ihrer Betriebsumgebung und identifiziert Schwachstellen, die statische Analysen übersehen. GitLab DAST integriert sich in Shift-Left Security-Workflows und stärkt Compliance und Risikomanagement.

Runtime-Schwachstellen-Erkennung

DAST identifiziert Sicherheitsschwachstellen in laufenden Anwendungen. DAST-Scanner interagieren mit Live-Anwendungen wie externe Angreifer und decken Probleme auf wie:

• Authentifizierungs- und Session-Fehler, die unbefugten Zugang ermöglichen
• Schwachstellen bei der Eingabevalidierung, einschließlich SQL-Injection, Cross-Site-Scripting (XSS) und Command-Injection
• Konfigurationsschwächen in Webservern, Datenbanken und Anwendungs-Frameworks
• Fehler in der Geschäftslogik aus Benutzerinteraktionen
• API-Sicherheitsprobleme, einschließlich unsachgemäßer Authentifizierung, Autorisierung und Datenexposition

DAST ergänzt andere Sicherheitstest-Ansätze für umfassende Anwendungssicherheits-Abdeckung. In Kombination mit Static Application Security Testing (SAST), Software Composition Analysis (SCA), manuellen Penetrationstests und vielen anderen Scanner-Typen füllt DAST kritische Lücken in der Sicherheitsvalidierung:

• Externe Testperspektive, die reale Angriffsszenarien nachahmt
• Umgebungsspezifische Tests, die Sicherheit in tatsächlichen Produktionsumgebungen validieren
• Drittanbieter-Komponenten-Tests, einschließlich APIs, Bibliotheken und externe Services
• Konfigurationsvalidierung über den gesamten Anwendungsstack hinweg

Nahtlose Shift-Left Security Integration

GitLab DAST integriert sich in CI/CD-Pipelines und identifiziert Sicherheitsprobleme früh im Entwicklungszyklus. Dieser Shift-Left-Ansatz bietet Vorteile:

• Kostensenkung – Schwachstellen während der Entwicklung zu beheben kostet 10 bis 100 Mal weniger als Korrekturen in der Produktion.
• Schnellere Markteinführung – Tests eliminieren Engpässe durch manuelle Security-Reviews.
• Entwickler-Stärkung – Sofortiges Feedback baut Sicherheitsbewusstsein auf.

Compliance und Risikomanagement

Regulierungsrahmen und Industriestandards fordern regelmäßige Sicherheitstests von Webanwendungen. DAST erfüllt Compliance-Anforderungen für Standards wie:

• PCI DSS für Anwendungen, die Zahlungskartensdaten verarbeiten
• SOC 2 Sicherheitskontrollen für Service-Organisationen
• ISO 27001 Informationssicherheits-Management-Anforderungen

GitLab DAST automatisiert Tests konsistent und wiederholbar. Auditoren vertrauen den Ergebnissen, während Berichte die nötige Dokumentation für Compliance-Validierung liefern.

DAST implementieren

Vor der Implementierung von GitLab DAST stellen Sie sicher, dass Ihre Umgebung folgende Anforderungen erfüllt:

• GitLab Version und Ultimate-Abonnement – DAST ist in GitLab Ultimate verfügbar und benötigt GitLab 13.4 oder später für volle Funktionalität; jedoch wird die neueste Version empfohlen.
• Anwendungszugänglichkeit – Ihre Anwendung muss über HTTP/HTTPS mit einer öffentlich erreichbaren URL oder innerhalb des Netzwerks Ihres GitLab Runners zugänglich sein.
• Authentifizierung-Setup – Falls Ihre Anwendung Authentifizierung erfordert, bereiten Sie Test-Credentials vor oder konfigurieren Sie Authentifizierungs-Bypass-Mechanismen für Sicherheitstests.

Systematische DAST-Integration: Drei Konfigurationsebenen

Grundkonfiguration für sofortigen Start: Die einfachste DAST-Integration erfolgt durch Template-Einbindung in Ihre .gitlab-ci.yml Datei:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: "https://your-application.example.com"

Diese Basiskonfiguration wird:

• Einen DAST-Scan gegen Ihre spezifizierte Website ausführen
• Einen Sicherheitsbericht in GitLabs Security Dashboard generieren
• Die Pipeline fehlschlagen lassen, falls hochschwere Schwachstellen erkannt werden
• Scan-Ergebnisse als Pipeline-Artefakte speichern

Systematische Pipeline-Integration: Für umfassende CI/CD-Vorteile können Sie zuerst die Anwendung deployen und DAST so konfigurieren, dass es nur nach erfolgtem Deployment läuft:

stages:
  - build
  - deploy
  - dast

include:
  - template: Security/DAST.gitlab-ci.yml

# Konfiguriert DAST für aktive Scans auf Nicht-Main-Branches und passive Scans auf Main-Branch
dast:
  stage: dast
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "false"
    - if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "true"
  dependencies:
    - deploy

Passive vs. Active Scanning verstehen

GitLab DAST verwendet zwei unterschiedliche Scanning-Methodologien (passiv und aktiv), die jeweils verschiedene Sicherheitstest-Bedürfnisse erfüllen.

Passive Scans analysieren Server-Antworten ohne das Senden potenziell schädlicher Anfragen:

• Untersuchen HTTP-Headers, Cookies und Antwortinhalte auf Sicherheits-Fehlkonfigurationen
• Identifizieren Information-Disclosure-Schwachstellen wie exponierte Server-Versionen
• Erkennen fehlende Sicherheits-Headers (CSP, HSTS, X-Frame-Options)
• Analysieren SSL/TLS-Konfiguration und Zertifikatsprobleme

Active Scans senden gestaltete Anfragen, die Schwachstellen auslösen sollen:

• Testen auf Injection-Schwachstellen (SQL-Injection, XSS, Command-Injection)
• Versuchen Authentifizierungs- und Autorisierungs-Fehler auszunutzen
• Validieren Input-Sanitization und Output-Encoding
• Testen auf Business-Logic-Schwachstellen

Hinweis: Der DAST-Scanner ist standardmäßig auf passiv eingestellt.

Authentifizierungs-Konfiguration

Enterprise-Authentifizierung für vollständige Abdeckung: DAST benötigt Authentifizierungs-Konfiguration für umfassende Sicherheitsabdeckung:

variables:
  DAST_AUTH_USERNAME: "admin@tanuki.local"
  DAST_AUTH_PASSWORD: "admin123"
  DAST_AUTH_USERNAME_FIELD: "css:input[id=email]"
  DAST_AUTH_PASSWORD_FIELD: "css:input[id=password]"
  DAST_AUTH_SUBMIT_FIELD: "css:button[id=loginButton]"
  DAST_AUTH_REPORT: "true"
  DAST_REQUEST_COOKIES: "welcomebanner_status:dismiss"

Verfügbare Authentifizierungs-Optionen:

• Einstufige Login-Formulare
• Mehrstufige Login-Formulare
• Authentifizierung zu URLs außerhalb des Zielbereichs

Ergebnisse in Merge Requests anzeigen

GitLabs DAST integriert Sicherheits-Scanning nahtlos in Ihren Entwicklungsworkflow durch direkte Anzeige der Ergebnisse in Merge Requests. Diese umfassen umfassende Schwachstellen-Daten, die Entwicklern helfen, Sicherheitsprobleme vor der Integration zu identifizieren und zu beheben.

Schwachstellen-Details

• Schwachstellen-Name und -Typ (z.B. SQL-Injection, XSS, CSRF)
• Schweregrad (Critical, High, Medium, Low, Info)
• CVSS-Score wenn anwendbar
• Common Weakness Enumeration (CWE) Identifier
• Vertrauensniveau des Befunds

Standort-Informationen

• URL/Endpoint, wo die Schwachstelle erkannt wurde
• Verwendete HTTP-Methode (GET, POST, etc.)
• Request/Response-Details der verwundbaren Interaktion
• Parameter-Namen, die verwundbar sind
• Nachweis der Schwachstelle

Systematische Schwachstellen-Governance

Schwachstellen im Default-Branch verwalten Sie über den GitLab Vulnerability Report - ein zentralisiertes Dashboard, das alle Sicherheitsbefunde über Ihr Projekt oder Organisation zeigt. Diese Ansicht sammelt alle Sicherheitstest-Ergebnisse und bietet Filter- und Sortier-Funktionen, um Behebungsmaßnahmen zu priorisieren.

Die Vulnerability-Seite bietet umfassende Schwachstellen-Daten. Von hier aus können Sie Schwachstellen durch Status-Zuweisung triagieren:

• Needs triage (Standard)
• Confirmed
• Dismissed (Acceptable risk, False positive, Mitigating control, Used in tests, Not applicable)
• Resolved

Wenn ein Schwachstellen-Status geändert wird, enthält das Audit-Log eine Notiz darüber, wer es geändert hat, wann es geändert wurde und den Grund für die Änderung. Dieses umfassende System ermöglicht Sicherheitsteams effiziente Priorisierung, Tracking und Management von Schwachstellen während ihres gesamten Lebenszyklus.

On-Demand und geplante DAST-Scans

GitLab bietet flexible Scanning-Optionen über Standard-CI/CD-Pipeline-Integration hinaus durch On-Demand und geplante DAST-Scans. On-Demand-Scans ermöglichen Sicherheitsteams und Entwicklern, DAST-Tests manuell bei Bedarf zu initiieren, ohne auf Code-Änderungen oder Pipeline-Trigger zu warten.

On-Demand-Scans können mit benutzerdefinierten Parametern, Ziel-URLs und Scanning-Profilen konfiguriert werden. Geplante DAST-Scans bieten automatisierte, zeitbasierte Sicherheitstests unabhängig vom Entwicklungsworkflow.

DAST in Compliance-Workflows

GitLabs Security-Policy-Framework ermöglicht Organisationen die Durchsetzung konsistenter Sicherheitsstandards über alle Projekte hinweg. Sicherheitsrichtlinien ermöglichen zentrale Governance von DAST-Scanning-Anforderungen.

Scan/Pipeline Execution Policies können konfiguriert werden, um DAST-Scans automatisch basierend auf spezifischen Bedingungen auszulösen. Merge Request Approval Policies bieten eine zusätzliche Sicherheits-Governance-Ebene durch erzwungene menschliche Review für Code-Änderungen, die Sicherheit beeinträchtigen könnten.

Für Compliance bietet GitLab Security Inventory und Compliance Center, die Ihnen ermöglichen zu überwachen, ob DAST in Ihrer Umgebung läuft und wo es erforderlich ist.

Zusammenfassung

GitLab DAST stellt eine mächtige Lösung für die Integration dynamischer Sicherheitstests in moderne Entwicklungsworkflows dar. Durch DAST-Implementierung in Ihrer CI/CD-Pipeline gewinnt Ihr Team die Fähigkeit, Runtime-Schwachstellen automatisch zu erkennen, Compliance mit Sicherheitsstandards aufrechtzuerhalten und sicherere Anwendungen ohne Geschwindigkeitseinbußen zu erstellen.

Der Schlüssel zur erfolgreichen DAST-Implementierung liegt darin, mit Grundkonfiguration zu beginnen und schrittweise zu sophistizierteren Scanning-Profilen entsprechend Ihrer Sicherheits-Reife zu expandieren. Beginnen Sie mit einfachem Website-Scanning, fügen Sie dann progressiv Authentifizierung, Custom Exclusions und erweiterte Berichte hinzu.

Denken Sie daran, dass DAST am effektivsten ist, wenn es mit anderen Sicherheitstest-Ansätzen kombiniert wird. Verwenden Sie es neben statischer Analyse, Dependency-Scanning und manuellen Security-Reviews für eine umfassende Sicherheitstest-Strategie.

Für detaillierte Implementierungsschritte, Authentifizierungs-Konfiguration und technische Setup-Anleitungen siehe den umfassenden englischen Implementierungsguide.