Pipeline-Variables ermöglichen die Anpassung von GitLab CI/CD-Pipelines zur Laufzeit. Mit der Entwicklung von CI/CD-Sicherheits-Best-Practices wurde jedoch deutlich, dass stärkere Kontrollen bei der Pipeline-Anpassung erforderlich sind. Uneingeschränkte Pipeline-Variables erlauben Nutzern mit Pipeline-Trigger-Berechtigungen das Überschreiben von Werten ohne Validierung oder Typ-Prüfung. Dies schafft Sicherheitsrisiken durch Variable-Injection-Angriffe.

Pipeline-Variables fehlt zudem eine explizite Deklaration und Dokumentation. Dadurch ist schwer nachvollziehbar, welche Eingaben erwartet werden und wie diese in der Pipeline verwendet werden. Dies erschwert die Wartung und etabliert keine klare Governance über CI/CD-Prozesse.

Pipeline-Inputs als sichere Alternative

GitLab Pipeline-Inputs bieten eine systematische Lösung mit folgenden Eigenschaften:

Explizite Deklaration: Inputs müssen in der .gitlab-ci.yml explizit deklariert werden und sind selbstdokumentierend.

Typ-Sicherheit: Unterstützung verschiedener Input-Typen (string, boolean, number, array) mit automatischer Validierung.

Integrierte Validierung: Automatische Validierung von Input-Werten gegen definierte Constraints.

Verbesserte Sicherheit: Kein Risiko von Variable-Injection-Angriffen, da nur deklarierte Inputs von außen übergeben werden können.

Grundlegendes Beispiel

    spec:
      inputs:
        deployment_env:
          description: "Target deployment environment"
          type: string
          options: ["staging", "production"]
          default: "staging"
        enable_tests:
          description: "Run test suite"
          type: boolean
          default: true

    test:
      script:
        - echo "Running tests"
      rules:
        - if: $[[ inputs.enable_tests ]] == true

    deploy:
      script:
        - echo "Deploying to $[[ inputs.deployment_env ]]"

Weitere Details zur typ-sicheren Parameter-Übergabe mit Validierung finden sich im CI/CD-Inputs-Tutorial.

Restriktion von Pipeline-Variables

Für die Migration zu Pipeline-Inputs ist die Konfiguration der Einstellung "Minimum role to use pipeline variables" erforderlich. Diese Einstellung ermöglicht granulare Kontrolle darüber, welche Rolle Pipeline-Variables beim Triggern von Pipelines verwenden darf.

Auf Projekt-Ebene: Navigation zu Settings > CI/CD > Variables > Minimum role to use pipeline variables.

Verfügbare Optionen:

• No one allowed (no_one_allowed) – Empfohlene und sicherste Option. Verhindert alle Variable-Overrides.
• Developer (developer) – Erlaubt Developern und höheren Rollen das Überschreiben von Variables
• Maintainer (maintainer) – Erfordert Maintainer-Rolle oder höher
• Owner (owner) – Nur Projekt-Owner können Variables überschreiben

Auf Group-Ebene: Group-Maintainer können unter Settings > CI/CD > Variables > Default role to use pipeline variables sichere Defaults für alle neuen Projekte innerhalb der Group festlegen. Dies gewährleistet konsistente Sicherheitsrichtlinien. Auch hier wird No one allowed als Default-Wert empfohlen, sodass neue Projekte mit sicherer Standardeinstellung erstellt werden. Projekt-Owner können die Einstellung weiterhin ändern.

Bei vollständiger Restriktion von Pipeline-Variables (mit "No one allowed") erscheinen die prefilled variables nicht im "New Pipeline UI"-Formular.

Migration von Pipeline-Variables

Lücken schließen

Gruppen können Projekte enthalten, bei denen Pipeline-Variables standardmäßig aktiviert sind, obwohl sie nie beim Triggern einer Pipeline verwendet wurden. Diese Projekte können ohne Unterbrechungsrisiko zur sichereren Einstellung migriert werden. GitLab bietet Migrationsfunktionalität über Group-Einstellungen:

• Navigation zu Settings > CI/CD > Variables
• In Disable pipeline variables in projects that don't use them auf Start migration klicken

Diese Migration ist ein Background-Job, der Pipeline-Variables über Projekt-Einstellungen für alle Projekte deaktiviert, die diese historisch nicht verwendet haben.

Konvertierung von Pipeline-Variables zu Inputs

Für jede identifizierte Pipeline-Variable ist ein entsprechender Pipeline-Input zu erstellen.

Vorher (mit Pipeline-Variables):

    variables:
      DEPLOY_ENV:
        description: "Deployment environment"
        value: "staging"
      ENABLE_CACHE:
        description: "Enable deployment cache"
        value: "true"
      VERSION:
        description: "Application version"
        value: "1.0.0"

    deploy:
      script:
        - echo "Deploying version $VERSION to $DEPLOY_ENV"
        - |
          if [ "$ENABLE_CACHE" = "true" ]; then
            echo "Cache enabled"
          fi

Nachher (mit Pipeline-Inputs):

    spec:
      inputs:
        deploy_env:
          description: "Deployment environment"
          type: string
          default: "staging"
          options: ["dev", "staging", "production"]
        enable_cache:
          description: "Enable deployment cache"
          type: boolean
          default: true
        version:
          description: "Application version"
          type: string
          default: "1.0.0"
          regex: '^[0-9]+\.[0-9]+\.[0-9]+$'

    deploy:
      script:
        - echo "Deploying version $[[ inputs.version ]] to $[[ inputs.deploy_env ]]"
        - |
          if [ "$[[ inputs.enable_cache ]]" = "true" ]; then
            echo "Cache enabled"
          fi

Migration von Trigger-Jobs

Bei Verwendung von Trigger-Jobs mit dem trigger-Keyword ist sicherzustellen, dass diese keine Job-Level-variables definieren oder das Erben von Variables von Top-Level variables, extends oder include deaktivieren. Variables könnten implizit als Pipeline-Variables downstream übergeben werden. Bei restriktiven Pipeline-Variables im Downstream-Projekt schlägt die Pipeline-Erstellung fehl.

Die CI-Konfiguration sollte auf Pipeline-Inputs statt Pipeline-Variables aktualisiert werden:

    variables:
      FOO: bar

    deploy-staging:
      inherit:
        variables: false  # sonst würde FOO downstream als Pipeline-Variable gesendet
      trigger:
        project: myorg/deployer
        inputs:
          deployment_env: staging
          enable_tests: true

Zusammenfassung

Die Migration von Pipeline-Variables zu Pipeline-Inputs ist eine Sicherheitsverbesserung, die CI/CD-Infrastruktur vor Variable-Injection schützt und gleichzeitig bessere Dokumentation, Typ-Sicherheit und Validierung bietet. Die Implementierung dieser Restriktionen und Übernahme von Pipeline-Inputs verbessert nicht nur die Sicherheit, sondern macht Pipelines wartbarer, selbstdokumentierend und robuster.

Die Transition erfordert initialen Aufwand, die langfristigen Vorteile überwiegen jedoch die Migrationskosten. Der Einstieg erfolgt durch Restriktion von Pipeline-Variables auf Group-Ebene für neue Projekte, gefolgt von systematischer Migration bestehender Pipelines mittels der oben beschriebenen Vorgehensweise.

Sicherheit ist ein kontinuierlicher Prozess. Pipeline-Inputs sind ein wichtiger Schritt zur Schaffung einer sichereren CI/CD-Umgebung und ergänzen weitere GitLab-Sicherheitsfunktionen wie Protected Branches, Job-Token-Allowlists und Container-Registry-Protections.

Für den Einstieg mit Pipeline-Inputs: Kostenlose GitLab-Ultimate-Testversion anfordern.

Für deutsche Unternehmen ist dieser systematische Ansatz besonders relevant: Die Automatisierung von Security-Detections unterstützt Compliance-Anforderungen wie ISO 27001 (technisches Schwachstellenmanagement nach A.12.6.1), DSGVO Artikel 32 (angemessene technische Maßnahmen) und BSI Grundschutz OPS.1.1.5 (Protokollierung und Monitoring). Die vollständige Versionierung aller Detection-Änderungen durch das Framework schafft einen lückenlosen Audit-Trail für Compliance-Nachweise. In der deutschen SIEM-Landschaft nutzen Unternehmen primär Plattformen wie Splunk, Elastic SIEM oder IBM QRadar – GUARD abstrahiert Detection-Logik vom jeweiligen SIEM-System, wodurch Herstellerunabhängigkeit gewährleistet wird.

GUARD deckt alle Aspekte der Security-Detection ab, darunter:

• Erstellung
• Wartung
• Alert-Routing und -Handling
• Metriken-Erfassung
• Workflow für Alert-Closure oder Incident-Eskalation

Die Ziele von GUARD

GUARD wurde mit einer Reihe zentraler Ziele entwickelt und konzipiert:

1. Standardisierung der Detection- und Alerting-Pipeline von SIRT zur Produktion qualitativ hochwertiger Detections mit Fokus auf Peer-Reviews und Automatisierung
2. Reduktion von Alert-Fatigue durch Alert-Konsolidierung, Deduplizierung, Risk-Scoring und automatisiertes Feedback
3. Metriken zur Messung der Response-Effizienz und frühzeitigen Identifikation von Problemen
4. GitLab als Kern durch Nutzung von GitLab als Single Source of Truth für Detection-Definitionen

Die Design-Prinzipien von GUARD

GUARD entstand aus operativer Notwendigkeit mit klarer Zielvorstellung. Vor GUARD folgten Detections keinem Standardformat, Alert-Metriken waren nicht verfügbar, Detection-Erstellung und -Wartung erfolgten ad-hoc. Ein skalierbares, GitLab-zentriertes Framework mit Automatisierung manueller Aufgaben war zentral für den Erfolg von GUARD. Durch die realisierten Zeiteffizienzgewinne haben SecOps-Engineers mehr Kapazität für komplexe Probleme und anspruchsvolle Incidents.

GUARD-Komponenten

Das GUARD-Framework besteht aus mehreren Modulen. Im Zentrum steht die GitLab-Plattform selbst – sie fungiert als Single Source of Truth für Detection-Rules und ermöglicht SIRT das automatische Deployment von Detections as Code mittels GitLab CI/CD.

GUARD umfasst folgende Komponenten:

• Detection as Code (DaC) - Deployed Detections durch die GitLab-CI/CD-Pipeline.
• User Attestation Module - Ermöglicht GitLab-Teammitgliedern, zu potenziell bösartigen Aktivitäten Stellung zu nehmen.
• Enrichments - Abfrage historischer und kontextueller Informationen zur Alert-Anreicherung für einfachere Triage.
• Alert Triage and Response - Bereitstellung eines standardisierten Formats für Alert-Triage und vordefinierter Eskalationsaktionen.
• Metrics Generation - Erfassung von Insights zum Alert-Handling.

Jedes GUARD-Modul arbeitet zusammen, um GitLabs Security-Detections und Alert-Pipeline zu standardisieren, automatisieren und iterativ zu verbessern.

GitLab als Kern

GitLab ist zentral für kritische GUARD-Komponenten: als Single Source für Threat-Detections, zur Automatisierung der Detection-as-Code-Pipeline durch GitLab CI/CD und als "Frontend" für GUARD, über das Security-Engineers Threat-Detections hinzufügen, bearbeiten und löschen können.

Wie GitLab-Features GUARD nutzen:

• GitLab Projects: GUARD nutzt ein GitLab-Projekt-Repository als Single Source für GUARD-Threat-Detections, gespeichert im JSON-Format.
• GitLab MRs: Alle Änderungen an GUARD-Detections, einschließlich neuer Detections, nutzen GitLab-MRs gegen das Haupt-GUARD-Projekt. Ein detailliertes MR-Template wird verwendet, in dem Details zur hinzugefügten, bearbeiteten oder gelöschten Detection validiert und dokumentiert werden. MR-Approval-Rules, einschließlich CodeOwners und Protected Branches, stellen sicher, dass ordnungsgemäße Detection-Reviews vor dem Merge abgeschlossen sind.
• GitLab Issues: Bug-Reports oder andere Engineering-Aufgaben im Zusammenhang mit GUARD werden in GitLab Issues erfasst.
• GitLab Labels: Ein Set standardisierter Labels stellt sicher, dass Security-Engineers GUARD-Änderungen auf leicht nachvollziehbare Weise dokumentieren.
• GitLab CI/CD: GUARD nutzt eine GitLab-CI-Pipeline zur Automatisierung des Deployments neuer, geänderter oder gelöschter Detections in GitLabs Security Incident and Event Management (SIEM). Die CI-Pipeline von GUARD führt zahlreiche Validierungs-, Test- und Qualitätschecks durch, bevor die Pipeline erfolgreich passiert wird und Änderungen in GitLabs SIEM-Plattform committed werden.

Metriken-Generierung

Interaktionen mit der Alert-Handling-Oberfläche werden erfasst, um zentrale Performance-Metriken zu generieren: Time to Respond, Time to Resolve sowie Insights zu Alerts wie True/False-Positive-Rates. Zusätzlich erfasste Metadaten beinhalten eine Emoji-basierte Sentiment-Analyse. Engineers, die Alerts bearbeiten, geben "Feedback" zu behandelten Alerts in Form von Emojis, sodass dieses Feedback bei der Iteration von Detection-Rules berücksichtigt werden kann.

Alert-Handling-Metriken werden in einer separaten Datenbank gespeichert, um Visualisierungen zu erstellen, die von Engineers und Management konsultiert werden. Diese sind zentral für das Verständnis der Team-Performance bei Alert-Resolution und Alert-Fidelity, sodass kontinuierliche Verbesserung möglich ist.

Gemeinsam iterieren

Die Nutzung von GitLab als Single Source of Truth für Threat-Detection-Code ermöglichte GUARD, Prozesse von spezifischer SIEM-Technologie zu extrahieren. Dies unterstützt größere Flexibilität, einfachere Nutzung, Modularisierung und Audit-Fähigkeit. Für deutsche Unternehmen mit strengen Datenschutzanforderungen ist relevant: Die Lösung funktioniert vollständig mit GitLab Self-Managed, sodass keine Detection-Daten externe Cloud-Systeme verlassen müssen.

Iteration ist ein zentraler GitLab-Wert – wir starten mit dem kleinsten wertvollen Element, um schnelles Feedback zu erhalten und effizient ein gewünschtes Endziel zu erreichen. GUARD ist keine Ausnahme. Wir hoffen, dass das Teilen von GUARD Lesern hilft, in Richtung eigener Automatisierungsverbesserungen zu iterieren.

Dieser Artikel ist der erste einer Serie über GitLab GUARD. Als Nächstes werden wir Details zu verschiedenen Aspekten unserer iterativen Journey zur Implementierung von GUARD bei GitLab teilen. Der zweite Teil der Serie, "Cybersecurity-Bedrohungen mit GitLab CI/CD automatisieren", beschreibt den Detection-as-Code-Workflow mit CI/CD-Pipeline-Details, automatisierten Quality-Gates und praktischen Implementierungsbeispielen.

Die Erstellung und Bereitstellung von Security-Threat-Detections in einem Security Information Event Management System (SIEM) ist zentrale Komponente erfolgreicher Cybersecurity-Programme. Der Übergang von manueller Detection-Erstellung zu vollautomatisierten Prozessen durch Detection as Code (DaC) gewährleistet Konsistenz, Qualität, Audit-Fähigkeit und automatisierte Tests. Bei GitLab haben wir DaC-Funktionen in GUARD integriert, unser vollautomatisiertes Detection- und Response-Framework.

Für deutsche Unternehmen ist dieser systematische Ansatz besonders relevant: Die Automatisierung von Security-Detections unterstützt Compliance-Anforderungen wie ISO 27001 (technisches Schwachstellenmanagement nach A.12.6.1), DSGVO Artikel 32 (angemessene technische Maßnahmen) und BSI Grundschutz OPS.1.1.5 (systematische Protokollierung). Die vollständige Versionierung aller Detection-Änderungen schafft zudem einen lückenlosen Audit-Trail für Compliance-Nachweise.

Die Herausforderung: Source Control und automatisierte Tests

Die Signals-Engineering- und SIRT-Teams bei GitLab teilen sich die Verantwortung für Erstellung, Aktualisierung und Außerbetriebnahme von Threat-Detections im SIEM. Die Aufrechterhaltung einer Single Source of Truth für Detections ist kritisch, um Konsistenz und Qualitätsstandards sicherzustellen. Unsere Teams entschieden bewusst, den Detection-Erstellungsprozess vom SIEM zu abstrahieren. Dadurch verbesserten sich Issue-Tracking, Konsistenz, Rollback-Prozesse und Metriken.

Zusätzlich stellten Pre-Commit-Detection-Tests außerhalb des SIEM sicher, dass neu erstellte Detections keine übermäßig False-Positive-lastigen Alerts einführten, die Tuning oder Deaktivierung während der Fehlerkorrektur erfordert hätten.

Die Lösung: GitLab CI/CD für Detection-Testing und -Validierung nutzen

Um diese Herausforderungen zu adressieren, entwickelten wir einen Workflow mit GitLab CI/CD, der zu einem sicheren SIEM-Detection-Deployment-Prozess mit systematischer Validierung führte.

Kernkomponenten der GUARD-DaC-Pipeline

1. Detections in JSON-Format in GitLab-Projekt gespeichert

GitLab nutzt das JSON-Format für Threat-Detections. Das Template enthält essenzielle Informationen wie SIEM-Query-Logik, Detection-Titel und -Beschreibung sowie Runbook-Page-Link, MITRE-Tactic und -Technique zur Detection und weitere notwendige Details.

2. Merge Requests initiieren

Wenn ein GitLab-Teammitglied eine neue Threat-Detection erstellen, eine existierende aktualisieren oder eine aktuelle Detection löschen möchte, initiiert es den Prozess durch Einreichen eines Merge Request (MR) im DaC-Projekt, das das Detection-JSON-Template enthält. Die Erstellung des MR löst automatisch eine CI/CD-Pipeline aus.

3. Automatisierte Validierung durch CI/CD-Jobs

Jeder MR enthält automatisierte Checks via GitLab CI/CD:

• Query-Format-Validierung: SIEM-API-Abfrage stellt sicher, dass die Detection-Query valide ist
• JSON-Detection-Fields-Validierung: Validiert, dass alle erforderlichen Felder vorhanden sind und im korrekten Format vorliegen
• Neue Detections und Detection-Modifikationen lösen SIEM-API-Calls aus, um sicherzustellen, dass die Detection keine Fehler enthält und keine Probleme in Production-Detection-Rules eingeführt werden
• Detection-Deletion-MRs lösen Pipeline-SIEM-API-Queries aus, um zu prüfen, dass die zu löschende Detection noch aktiv ist und gelöscht werden kann

4. Peer Review und Approval

Wenn ein Detection-MR-Job erfolgreich abgeschlossen ist, ist ein Peer Review erforderlich, um zu prüfen und zu bestätigen, dass der MR die erforderlichen Qualitäts- und Content-Standards erfüllt, bevor der Detection-MR gemergt werden kann. Merge-Request-Approval-Rules werden genutzt, um den Peer-Review-Prozess auszulösen.

5. Merge und finales Deployment

Nach MR-Approval wird dieser in den Main-Branch gemergt. Als Teil der CI/CD-Pipeline führt ein automatisierter Job einen SIEM-API-Command aus, um zwei Aufgaben durchzuführen:

• Die neue Detection erstellen oder die existierende Detection aktualisieren/löschen, falls erforderlich
• MITRE-ATT&CK-Tactic- und -Technique-Informationen zur Alert aus den JSON-Dateien extrahieren und diese Details an eine Lookup-Table im SIEM übermitteln. Diese Lookup-Table spielt eine wichtige Rolle beim Mapping unserer Alerts zu MITRE-Tactics und -Techniques und hilft uns, unsere Threat-Analyse zu verbessern und Lücken in unseren Detection-Capabilities in Alignment mit dem MITRE-Framework zu identifizieren.

Hinweis: Die notwendigen Credentials für diese Aktionen werden sicher in CI/CD-Variablen gespeichert, um sicherzustellen, dass der Prozess vertraulich und sicher bleibt.

Nachfolgend ein Template für eine GitLab-CI/CD-gitlab-ci.yml-Konfigurationsdatei für eine DaC-Pipeline:

#
---------------------------------------------------------------------------
#
# GitLab CI/CD Pipeline for SIEM Detection Management
#
---------------------------------------------------------------------------
#

image: python:3.12

#
---------------------------------------------------------------------------
#
# Global Configuration
#
---------------------------------------------------------------------------
#

before_script:
  - apt-get update && apt-get install -y jq
  - pip install --upgrade pip
  - pip install -r requirements.txt

#
---------------------------------------------------------------------------
#

stages:
  - fetch
  - test
  - process
  - upload

#
---------------------------------------------------------------------------
#
# Fetch Stage
#
---------------------------------------------------------------------------
#

fetch_changed_files:
  stage: fetch
  script:
    - echo "Fetching changed files..."
    - git branch
    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000
    - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        git diff --name-status HEAD^1...HEAD > changed-files-temp.txt
      else
        git fetch origin $CI_COMMIT_BRANCH:$CI_COMMIT_BRANCH --depth 2000
        git diff --name-status ${CI_DEFAULT_BRANCH}...${CI_COMMIT_SHA} > changed-files-temp.txt
      fi
    - grep -E '\.json$' changed-files-temp.txt > changed-files.txt || true
    - flake8 .
    - pytest
  artifacts:
    paths:
      - changed-files.txt
    expose_as: 'changed_files'

#
---------------------------------------------------------------------------
#
# Test Stage
#
---------------------------------------------------------------------------
#

flake8:
  stage: test
  script:
    - echo "Running Flake8 for linting..."
    - flake8 .

pytest:
  stage: test
  script:
    - echo "Running Pytest for unit tests..."
    - pytest
  artifacts:
    when: always
    reports:
      junit: report.xml

#
---------------------------------------------------------------------------
#
# Process Stage
#
---------------------------------------------------------------------------
#

process_files:
  stage: process
  script:
    - echo "Processing changed files..."
    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL
    - mkdir -p modified_rules delete_file new_file
    - python3 move-files.py -x changed-files.txt
    - python3 check-alerts-format.py
  artifacts:
    paths:
      - modified_rules
      - delete_file
      - new_file
#
---------------------------------------------------------------------------
#
# Upload Stage
#
---------------------------------------------------------------------------
#

update_rules:
  stage: upload
  script:
    - echo "Uploading updated rules and lookup tables..."
    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000
    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL 
    - python3 update-rules.py
    - python3 update-exceptions.py
    - python3 create_ttps_layers.py
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE != "schedule"
      changes:
        - detections/**/*
        - exceptions/**/*

Das folgende Diagramm illustriert den Workflow des oben beschriebenen CI/CD-Prozesses mit seinen vier Phasen: Fetch (Änderungen identifizieren), Test (Linting und Tests), Process (Dateien kategorisieren) und Upload (Rules und Lookup-Tables aktualisieren).

graph TD;
    fetch[Fetch Stage: Identify Changed Files] --> test[Test Stage: Run Linting and Tests];
    test --> process[Process Stage: Categorize Files];
    process --> upload[Upload Stage: Update Rules and Lookup Tables];
    fetch --> fetch_details[Details: Filter JSON files, Output 'changed-files.txt'];
    test --> test_details[Details: Run Flake8 for linting, Pytest for testing];
    process --> process_details[Details: Categorize into 'modified', 'new', 'deleted', Prepare for upload];
    upload --> upload_details[Details: Update repo, Update detections in SIEM and SIEM lookup table];

In der deutschen SIEM-Landschaft nutzen Unternehmen primär Plattformen wie Splunk, Elastic SIEM oder IBM QRadar. Der hier beschriebene DaC-Ansatz abstrahiert Detection-Logik vom jeweiligen SIEM-System durch JSON-Templates, wodurch Herstellerunabhängigkeit gewährleistet wird. Für deutsche Unternehmen mit strengen Datenschutzanforderungen ist relevant: Die Lösung funktioniert vollständig mit GitLab Self-Managed, sodass keine Detection-Daten externe Cloud-Systeme verlassen müssen.

Benefits und Ergebnisse

Die Automatisierung unseres Detection-Lifecycles durch einen DaC-CI/CD-gestützten Workflow bringt zahlreiche Benefits für unseren Threat-Detection-Deployment-Prozess:

• Automatisierung: Die Automatisierung von Erstellung und Validierung der SIEM-Detections reduziert manuelle Fehler durch systematische Validierungsstufen und spart Zeit durch Pipeline-Automatisierung.
• Enhanced Security: Der CI-gesteuerte Workflow setzt eine Least-Privilege-Policy um und gewährleistet Konsistenz, Peer Reviews und Qualitätsstandards für Erstellung, Aktualisierung oder Löschung von Threat-Detections.
• Effizienz: Das standardisierte JSON-Detection-Format und die automatisierte Erstellung verkürzen den Deployment-Cycle von Detection-Erstellung bis SIEM-Integration.
• Kollaboration: Der MR- und Review-Prozess implementiert das in Deutschland übliche Vier-Augen-Prinzip: Jede Detection-Änderung durchläuft systematische Peer-Reviews, bevor sie in Production gelangt. Dies gewährleistet nicht nur fachliche Qualität, sondern erfüllt auch Governance-Anforderungen für kritische Sicherheitssysteme.
• Version Control: Die Behandlung von Threat-Detections als Code abstrahiert die Detections von der SIEM-Plattform, in der sie letztlich gespeichert werden. Diese Abstraktion liefert einen historischen Record von Änderungen, erleichtert Kollaboration und ermöglicht Rollbacks zu vorherigen Konfigurationen, falls Probleme auftreten.

Mit DaC starten

Die Nutzung von GitLab CI/CD und einer Least-Privilege-Policy hat unser SIEM-Detection- und Alert-Management mit definierten Quality-Gates systematisiert. Automatisierung hat Effizienz verbessert und Risiken reduziert und bietet ein hilfreiches Beispiel für andere, die ihre Security und Compliance verbessern möchten. Sie können dieses Tutorial ausprobieren, indem Sie sich für eine kostenlose Testversion von GitLab Ultimate anmelden. Für Unternehmen mit Data-Sovereignty-Anforderungen steht GitLab Self-Managed zur Verfügung.

Value Stream Management ist in der deutschen Industrie als Wertstromanalyse etabliert – insbesondere in der Fertigung und Automobilbranche wird diese Lean-Methode zur Identifikation von Verschwendung eingesetzt. GitLabs VSM-Funktionen übertragen diesen systematischen Ansatz auf Software-Entwicklungsprozesse und ermöglichen die Unterscheidung zwischen wertschöpfenden und nicht-wertschöpfenden Aktivitäten im Entwicklungsworkflow.

Die Herausforderung: Engpässe in MR-Reviews identifizieren

Trotz gut definierter Workflows stellte ein Team fest, dass Merge Requests länger als erwartet brauchten, um geprüft und gemerged zu werden. Die Herausforderung bestand nicht nur in den Verzögerungen selbst, sondern darin zu verstehen, wo im Review-Prozess diese Verzögerungen auftraten und warum.

Das Ziel des Teams war klar:

• Identifizieren, wo Zeit vom initialen Konzept bis zum finalen Merge eines MR verbracht wurde
• Spezifische Engpässe im Review-Prozess lokalisieren
• Verstehen, wie MR-Größe, Komplexität oder Dokumentationsqualität die Review-Zeit beeinflussen

Der Ansatz: MR-Review-Zeit in GitLab Value Stream Analytics messen

Value Stream Analytics (VSA) ermöglicht es Organisationen, ihren gesamten Workflow von der Idee bis zur Auslieferung abzubilden und dabei zwischen wertschöpfenden Aktivitäten (VA) und nicht-wertschöpfenden Aktivitäten (NVA) im Prozessfluss zu unterscheiden. Durch die Berechnung des Verhältnisses von wertschöpfender Zeit zur gesamten Lead Time kann das Team verschwenderische Aktivitäten identifizieren, die zu Verzögerungen bei MR-Reviews führen.

Um die notwendigen Metriken zu erhalten, passte das Team GitLab VSA an, um bessere Sichtbarkeit in den MR-Review-Prozess zu erhalten.

1. Custom Stage für MR-Review einrichten

Das Team fügte eine neue Custom Stage in VSA mit dem Namen Review Time to Merge hinzu, um spezifisch die Zeit vom ersten Zuweisen eines Reviewers bis zum Merge des MR zu tracken.

• Start-Event: MR first reviewer assigned
• End-Event: MR merged

Durch die Definition dieser Stage begann VSA, die Dauer des MR-Review-Prozesses zu messen und lieferte präzise Daten darüber, wo Zeit verbracht wurde.

2. Total Time Chart für Klarheit nutzen

Mit der Custom Stage eingerichtet, nutzte das Team das Total Time Chart auf der VSA Overview-Seite (Analyze > Value Stream), um zu visualisieren, wie viel Zeit während der neuen MR-Review-Stage verbracht wurde. Durch den Vergleich der Werte, die durch jeden Bereich im Chart dargestellt wurden, konnte das Team schnell identifizieren, wie diese Stage zur gesamten Software-Delivery-Lifecycle-Zeit (SDLC) beitrug.

3. Für tiefere Erkenntnisse detailliert analysieren

Um spezifische Verzögerungen zu untersuchen, nutzte das Team die Stage Navigation Bar, um tiefer in die MR-Review-Stage einzutauchen. Diese Ansicht ermöglichte:

• MRs nach Review-Zeit sortieren: Die Stage-Tabelle zeigte alle zugehörigen MRs sortiert nach Review-Dauer, sodass langsame MRs leicht erkennbar waren
• Individuelle MRs analysieren: Für jeden MR konnte das Team Faktoren wie Verzögerungen bei der Reviewer-Zuweisung, mehrere Feedback-Runden, Leerlaufzeit nach Approval und MR-Größe/Komplexität untersuchen

Das Ergebnis: Umsetzbare Erkenntnisse und Verbesserungen

Durch die Anpassung von VSA zur Verfolgung der MR-Review-Zeit deckte das Team mehrere zentrale Erkenntnisse auf:

• Verzögerungen bei Reviewer-Zuweisung: Einige MRs erfuhren Verzögerungen, weil Reviewer spät zugewiesen wurden oder Reviewer zu viele MRs in ihrer Queue hatten
• Langsame Review-Start-Zeiten: Selbst nach Zuweisung lagen bestimmte MRs untätig, bevor Reviews begannen – oft aufgrund von Kontextwechseln oder konkurrierenden Prioritäten
• Mehrere Feedback-Schleifen: Größere MRs erforderten oft mehrere Feedback-Runden, was die Review-Zeit erheblich verlängerte
• Leerlaufzeit nach Approval: Einige MRs wurden approved, aber nicht zeitnah gemerged – oft aufgrund von Deployment-Koordinationsproblemen

Für den Engineering Manager im Team erwies sich VSA als wertvoll für die Verwaltung des Team-Workflows: "Ich habe VSA genutzt, um zu begründen, wo wir Zeit bei der MR-Fertigstellung verbrachten. Wir haben VSA auf unsere Bedürfnisse angepasst, und es war sehr hilfreich für unsere Untersuchungen nach Verbesserungsmöglichkeiten."

Aus dieser Dogfooding-Erfahrung entwickeln wir nun eine wichtige Erweiterung zur Verbesserung der Sichtbarkeit in den Review-Prozess. Wir fügen ein neues Event zu VSA hinzu – Merge request last approved at – das eine Stage erzeugt, die MR-Review-Schritte noch granularer aufschlüsselt.

Die Kraft datengestützter Entscheidungen

Durch die Nutzung von GitLabs VSA haben wir nicht nur Engpässe identifiziert – wir erhielten umsetzbare Erkenntnisse, die zu Verbesserungen bei der MR-Review-Zeit und der allgemeinen Entwickler-Produktivität führten. Wir optimierten Merge-Request-Review-Zyklen und erhöhten den Entwickler-Durchsatz, was unser Commitment zu kontinuierlicher Verbesserung durch Messung bestätigt.

Möchtest du erfahren, wie VSA deinem Team helfen kann? Starte eine kostenlose GitLab Ultimate-Testversion, passe deine Value Streams an und sieh, wie du Verbesserungen im gesamten SDLC für deine Teams erreichen kannst. Teile dann dein Feedback und deine Erfahrungen in diesem Issue.

Weiterführende Informationen

• Optimize value stream efficiency to do more with less, faster
• New Scheduled Reports Generation tool simplifies value stream management
• Value stream analytics documentation
• Value stream management: Total Time Chart simplifies top-down optimization flow

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 liefert eine modernisierte User Experience mit einem intuitiveren Interface, das auf einem neuen Panel-basierten Layout basiert.

Panels zeigen wichtige Informationen nebeneinander an, sodass sich kontextbezogen arbeiten lässt, ohne die Position zu verlieren. Wenn beispielsweise auf ein Issue in der Issue-Liste geklickt wird, öffnen sich die Details automatisch in einem Side Panel. Das GitLab Duo Panel lässt sich rechts öffnen und bringt Duo an jeden Ort in GitLab. So können kontextbezogene Fragen gestellt oder Anweisungen gegeben werden, direkt neben der eigentlichen Arbeit.

Mehrere Usability-Verbesserungen erleichtern die Navigation. Die globale Suchleiste erscheint nun in der oberen Mitte für bessere Zugänglichkeit. Globale Navigationselemente wie Issues, Merge Requests, To-Dos und der Avatar sind in die obere rechte Ecke gewandert. Zusätzlich lässt sich die linke Sidebar nun ein- und ausklappen für mehr Kontrolle über den Workspace.

Teams, die experimentelle Features und GitLab Duo Beta-Features nutzen, erhalten das neue Interface zuerst. Danach können alle GitLab.com-Nutzer diese Experience über einen Toggle aktivieren, der sich unter dem User-Icon befindet. Mehr Details zu diesem Feature in der Dokumentation. Feedback oder Issues können gemeldet werden – damit lässt sich GitLab besser gestalten!

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.

Die Duo Agent Platform reduziert mehrere Stunden Codeanalyse auf wenige Minuten durch automatisierte Analyse, kontinuierliche menschliche Kontrolle und systematische Dokumentationserstellung. Die folgende Demonstration zeigt die Erstellung einer vollständigen gRPC-Dokumentation für ein Golang-Projekt.

Das folgende Video dokumentiert den vollständigen Workflow:

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1098569263?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="AI Agent Generates Complete gRPC Documentation in Minutes | GitLab Duo Agent Platform Demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Aufgabenstellung: gRPC-Kommunikationsflüsse analysieren

Das Beispielprojekt "Duo Workflow Executor" kommuniziert mit einem gRPC-Server über bidirektionale Streaming-Verbindungen. Die Dokumentationsaufgabe umfasst die Darstellung des vollständigen Kommunikationsflusses mit empfangenen Payloads, ausgeführten Aktionen und zurückgesendeten Responses.

Die Implementierung erfolgt in VS Code mit installierter GitLab Workflow Extension. Der spezifische Prompt für die Duo Agent Platform definiert die Anforderungen präzise:

"Can you prepare a mermaid diagram that shows the gRPC connection between duo-workflow-service and this project. It should show what this project receives in gRPC payload, and what actions it executes based on the payload, and what it sends back. Study internal/services/runner/runner.go, especially the Run method, and write the mermaid output to a grpc.md file."

Die Duo Agent Platform analysiert die Anforderung und erstellt einen systematischen Ausführungsplan. Der Agent führt automatisch folgende Schritte aus:

• Durchsuchen relevanter Go-Dateien im Projekt
• Lesen der spezifizierten Datei runner.go
• Identifizierung zusätzlicher Dateien für notwendigen Kontext
• Analyse der Codebase-Struktur zur Erfassung der gRPC-Implementierung

Diese kontextbasierte Analyse unterscheidet Agenten-Systeme mit vollständigem Projektverständnis von einfachen Code-Generierungs-Tools. Die Duo Agent Platform erfasst die Beziehungen zwischen verschiedenen Komponenten des Projekts und berücksichtigt diese bei der Dokumentationserstellung.

Kollaborative Verfeinerung

Die Duo Agent Platform ist darauf ausgelegt, bei kritischen Momenten der Aufgabenausführung menschliche Rückmeldung einzuholen. Im vorliegenden Beispiel pausiert der Agent zur Klärung des gewünschten Detailgrads.

Agent: "Should I include error handling details in the diagram?"

Antwort: "Don't focus on error handling. Include all actions. Focus on gRPC payload."

Dieser iterative Verfeinerungs-Prozess stellt sicher, dass die Dokumentation die spezifischen Anforderungen erfüllt. Der Agent arbeitet kollaborativ mit dem Entwickler zusammen, anstatt Annahmen über die gewünschte Ausgabe zu treffen.

Ausführung und Ergebnisse

Nach der Klärung finalisiert die Duo Agent Platform den Ausführungsplan und fordert Bestätigung vor der Ausführung an. Der Plan kann zu diesem Zeitpunkt noch angepasst werden.

Der Agent führt anschließend die Aufgaben sequenziell aus und liefert Fortschrittsmeldungen in Echtzeit. Innerhalb weniger Minuten werden folgende Ergebnisse erstellt:

• Analyse aller relevanten Dateien im Projekt
• Erstellung detaillierter Dokumentation mit vollständigem Mermaid-Diagramm
• Speicherung in der angeforderten Datei grpc.md
• Integration wertvoller Kontextinformationen zu ausgehenden Payloads und Verbindungsverwaltung

Die resultierende Dokumentation ist nicht nur ein grundlegendes Diagramm, sondern eine detaillierte, präzise und unmittelbar verwendbare Architekturübersicht.

Analyse der Ausgabe

Das folgende Mermaid-Diagramm zeigt den vollständigen gRPC-Kommunikationsfluss, den die Duo Agent Platform erstellt hat:

sequenceDiagram
participant DWS as duo-workflow-service
participant DWE as duo-workflow-executor
participant Runner as ExecutionRunner
participant ActionExecutor as Action Executor
participant FileSystem as File System/Commands


Note over DWS, DWE: gRPC Bidirectional Streaming (ExecuteWorkflow)

%% Connection Establishment
DWE->>DWS: gRPC Connection with Headers
Note over DWE, DWS: Headers: authorization (Bearer token)<br/>x-gitlab-authentication-type: oidc<br/>x-gitlab-realm, x-gitlab-global-user-id<br/>x-gitlab-oauth-token, x-gitlab-base-url<br/>x-gitlab-instance-id, x-request-id<br/>x-gitlab-namespace-id, x-gitlab-project-id


%% Workflow Start Request
DWE->>DWS: ClientEvent{StartWorkflowRequest}
Note over DWE, DWS: StartWorkflowRequest:<br/>- ClientVersion<br/>- WorkflowDefinition<br/>- Goal<br/>- WorkflowID<br/>- WorkflowMetadata<br/>- ClientCapabilities[]


%% Action Processing Loop
loop Action Processing
    DWS->>DWE: Action Message
    Note over DWS, DWE: Action Types:<br/>- Action_RunCommand {program, flags[], arguments[]}<br/>- Action_RunGitCommand {command, arguments[], repositoryUrl}<br/>- Action_RunReadFile {filepath}<br/>- Action_RunWriteFile {filepath, contents}<br/>- Action_RunEditFile {filepath, oldString, newString}<br/>- Action_RunHTTPRequest {method, path, body}<br/>- Action_ListDirectory {directory}<br/>- Action_FindFiles {namePattern}<br/>- Action_Grep {searchDirectory, pattern, caseInsensitive}<br/>- Action_NewCheckpoint {}<br/>- Action_RunMCPTool {}


    DWE->>Runner: Receive Action
    Runner->>Runner: processWorkflowActions()
    Runner->>ActionExecutor: executeAction(ctx, action)
    
    alt Action_RunCommand
        ActionExecutor->>FileSystem: Execute Shell Command
        Note over ActionExecutor, FileSystem: Executes: program + flags + arguments<br/>in basePath directory
        FileSystem-->>ActionExecutor: Command Output + Exit Code
    
    else Action_RunReadFile
        ActionExecutor->>FileSystem: Read File
        Note over ActionExecutor, FileSystem: Check gitignore rules<br/>Read file contents
        FileSystem-->>ActionExecutor: File Contents
    
    else Action_RunWriteFile
        ActionExecutor->>FileSystem: Write File
        Note over ActionExecutor, FileSystem: Check gitignore rules<br/>Create/overwrite file
        FileSystem-->>ActionExecutor: Success/Error Message
    
    else Action_RunEditFile
        ActionExecutor->>FileSystem: Edit File
        Note over ActionExecutor, FileSystem: Read → Replace oldString with newString → Write<br/>Check gitignore rules
        FileSystem-->>ActionExecutor: Edit Result Message
    
    else Action_RunGitCommand
        ActionExecutor->>FileSystem: Execute Git Command 
        Note over ActionExecutor, FileSystem: Git operations with authentication<br/>Uses provided git config
        FileSystem-->>ActionExecutor: Git Command Output
    
    else Action_RunHTTPRequest
        ActionExecutor->>DWS: HTTP Request to GitLab API
        Note over ActionExecutor, DWS: Method: GET/POST/PUT/DELETE<br/>Path: API endpoint<br/>Body: Request payload<br/>Headers: Authorization
        DWS-->>ActionExecutor: HTTP Response
    
    else Action_ListDirectory
        ActionExecutor->>FileSystem: List Directory Contents
        Note over ActionExecutor, FileSystem: Respect gitignore rules
        FileSystem-->>ActionExecutor: Directory Listing
    
    else Action_FindFiles
        ActionExecutor->>FileSystem: Find Files by Pattern
        Note over ActionExecutor, FileSystem: Recursive search with name pattern<br/>Respect gitignore rules
        FileSystem-->>ActionExecutor: File Paths List
    
    else Action_Grep
        ActionExecutor->>FileSystem: Search Text Pattern
        Note over ActionExecutor, FileSystem: Recursive text search<br/>Case sensitive/insensitive option
        FileSystem-->>ActionExecutor: Search Results
    
    else Action_NewCheckpoint/Action_RunMCPTool
        ActionExecutor->>ActionExecutor: No-op Action
        Note over ActionExecutor: Returns empty success result
    end


    ActionExecutor-->>Runner: Action Result (string)
    
    alt Result Size Check
        Runner->>Runner: Check if result > 4MB
        Note over Runner: If result exceeds MaxMessageSize (4MB)<br/>Replace with error message about size limit
    end


    Runner->>DWE: ActionResponse
    DWE->>DWS: ClientEvent{ActionResponse}
    Note over DWE, DWS: ActionResponse:<br/>- RequestID (matches Action.RequestID)<br/>- Response (execution result string)
end


%% Workflow Completion
DWE->>DWS: CloseSend()
Note over DWE, DWS: Signal end of workflow execution


%% Analytics and Cleanup
Runner->>Runner: Send Analytics Event (Finish)
DWE->>DWE: Token Revocation (if enabled)
DWE->>DWS: Close gRPC Connection

Das Diagramm zeigt mehrere wichtige Architektur-Aspekte, deren manuelle Erfassung erhebliche Zeit erfordern würde:

• Bidirektionale Kommunikation: Der Workflow Executor initiiert Requests und antwortet auf Service-Aktionen.
• Strukturierte Payload-Definitionen: Jeder Aktionstyp definiert spezifische Parameter und erwartete Responses.
• Multiple Integrationspunkte: Der Executor interagiert mit lokalem Filesystem, Git-Repositories und GitLab-APIs.
• Vollständiger Aktionssatz: Neun verschiedene Aktionstypen decken Dateioperationen, HTTP-Requests und Git-Kommandos ab.
• Lebenszyklus-Verwaltung: Klare Muster für Verbindungsaufbau, Ausführung und Token-Widerruf.

Der Agent integriert automatisch die detaillierten Payload-Strukturen für jeden Aktionstyp in das Diagramm. Dieser Detailgrad transformiert eine Übersicht auf hohem Level in eine unmittelbar verwendbare technische Dokumentation für Entwickler-Teams.

Systematische Anwendungsfälle

Der Agent-Workflow folgt einem systematischen Ansatz: Kontexterfassung durch Analyse relevanter Dateien, kollaborative Verfeinerung durch gezielte Rückfragen, Erstellung eines Ausführungsplans zur Bestätigung, schrittweise Ausführung mit Fortschrittsmeldungen. Diese Transparenz entspricht den Anforderungen an nachvollziehbare Automatisierung in Entwicklungsteams.

Das demonstrierte Vorgehen kann auf weitere DevSecOps-Aufgaben übertragen werden:

• Code Reviews: Agenten analysieren Merge Requests mit vollständigem Projekt-Kontext
• Testing: Generierung umfassender Test-Suites basierend auf tatsächlichen Nutzungsmustern
• Debugging: Nachverfolgung von Problemen über multiple Services und Komponenten
• Security Scanning: Identifizierung von Schwachstellen unter Berücksichtigung der spezifischen Architektur
• CI/CD-Optimierung: Verbesserung der Pipeline-Performance basierend auf historischen Daten

Die GitLab Duo Agent Platform tritt demnächst in die öffentliche Beta-Phase ein. Registrierung für die Warteliste möglich.

Weitere Updates zum Stand der Entwicklung werden im GitLab Blog sowie über die Social-Media-Kanäle veröffentlicht. Die Roadmap umfasst spezialisierte Agenten, Custom Workflows und Community-Extensions.

Weitere Informationen

• Agentic AI Guides und Ressourcen
• GitLab Duo Agent Platform: Die Zukunft intelligenter DevSecOps
• Was ist Agentic AI?
• Von Vibe Coding zu Agentic AI: Roadmap für technische Führungskräfte

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.