Pipeline-Sicherheit: Lehren aus den Supply-Chain-Angriffen im März

Hinweis: Das GitLab-Produkt hat keine der in diesem Beitrag genannten kompromittierten Paketversionen verwendet.

Innerhalb von 12 Tagen haben vier separate Supply-Chain-Angriffe gezeigt, dass CI/CD-Pipelines zu einem bevorzugten Ziel für versierte Bedrohungsakteure geworden sind.

Zwischen dem 19. und 31. März 2026 kompromittierten Angreifer:

• einen Open-Source-Security-Scanner (Trivy)
• einen Infrastructure-as-Code-Scanner (Checkmarx KICS)
• ein AI-Model-Gateway (LiteLLM)
• einen JavaScript-HTTP-Client (axios)

Alle Angriffe teilten dieselbe Angriffsfläche: die Build-Pipeline.

Dieser Artikel zeigt, was passiert ist, warum Pipelines besonders anfällig sein können und wie zentrale Policy-Durchsetzung mit GitLab – mithilfe der unten beschriebenen Policies – diese Angriffsklassen blockieren, erkennen und eindämmen kann, bevor sie die Produktion erreichen.

Millionenfach vertraut, in Minuten kompromittiert

Hier die Zeitleiste der Supply-Chain-Angriffe:

19. März: Trivy-Security-Scanner wird zum Angriffsvektor

Trivy ist einer der weltweit am häufigsten eingesetzten Open-Source-Vulnerability-Scanner. Es ist das Tool, das Teams innerhalb ihrer Pipelines ausführen, um Schwachstellen zu finden.

Am 19. März nutzte eine Bedrohungsgruppe namens TeamPCP kompromittierte Zugangsdaten, um Schadcode per Force-Push in 76 von 77 Versions-Tags der GitHub Action aquasecurity/trivy-action sowie alle 7 Tags von aquasecurity/setup-trivy einzuschleusen. Gleichzeitig veröffentlichten sie ein trojanisiertes Trivy-Binary (v0.69.4) über offizielle Distributionskanäle. Die Payload war eine Credential-Stealing-Malware, die Umgebungsvariablen, Cloud-Tokens, SSH-Schlüssel und CI/CD-Secrets aus jeder Pipeline exfiltrierte, die einen Trivy-Scan ausführte.

Dem Vorfall wurde CVE-2026-33634 mit einem CVSS-Score von 9,4 zugewiesen. Die Cybersecurity and Infrastructure Security Agency (CISA) nahm ihn innerhalb weniger Tage in den Katalog der bekannten ausgenutzten Schwachstellen auf.

23. März: Checkmarx KICS als nächstes Ziel

Mit gestohlenen Zugangsdaten wandte sich TeamPCP dem Open-Source-Projekt KICS (Keeping Infrastructure as Code Secure) von Checkmarx zu. Sie kompromittierten die GitHub Actions ast-github-action und kics-github-action und schleusten dieselbe Credential-Stealing-Malware ein. Zwischen 12:58 und 16:50 UTC am 23. März exfiltrierte jede CI/CD-Pipeline, die diese Actions referenzierte, im Hintergrund sensible Daten – darunter API-Schlüssel, Datenbankpasswörter, Cloud-Access-Tokens, SSH-Schlüssel und Service-Account-Zugangsdaten.

24. März: LiteLLM über gestohlene Trivy-Zugangsdaten kompromittiert

LiteLLM, ein LLM-API-Proxy mit 95 Millionen monatlichen Downloads, war das nächste Ziel. TeamPCP veröffentlichte kompromittierte Versionen (1.82.7 und 1.82.8) auf PyPI – mithilfe von Zugangsdaten, die aus LiteLLMs eigener CI/CD-Pipeline erbeutet wurden, in der Trivy zum Scannen eingesetzt wurde.

Die Malware in Version 1.82.7 nutzte eine Base64-kodierte Payload, die direkt in litellm/proxy/proxy_server.py injiziert wurde und beim Import ausgeführt wurde. Die Version für 1.82.8 verwendete eine .pth-Datei – ein Python-Mechanismus, der automatisch beim Interpreter-Start ausgeführt wird. Allein die Installation von LiteLLM reichte aus, um die Payload auszulösen. Die Angreifer verschlüsselten die erbeuteten Daten (SSH-Schlüssel, Cloud-Tokens, .env-Dateien, Kryptowährungs-Wallets) und exfiltrierten sie an models.litellm.cloud, eine Lookalike-Domain.

31. März: Quellcode eines AI-Coding-Assistenten durch einfachen Packaging-Fehler geleakt

Während die TeamPCP-Kampagne noch andauerte, lieferte ein Softwareunternehmen ein npm-Paket mit einer 59,8 MB großen Source-Map-Datei aus – die den vollständigen, unminifizierten TypeScript-Quellcode seines AI-Coding-Assistenten referenzierte, gehostet im eigenen Cloudflare-R2-Bucket des Unternehmens.

Das Leak legte 1.900 TypeScript-Dateien, über 512.000 Codezeilen, 44 versteckte Feature-Flags, unveröffentlichte Modell-Codenamen und den vollständigen System-Prompt offen – für jeden, der wusste, wo er suchen musste. Wie der Entwickler Gabriel Anhaia erklärte: „Eine einzige falsch konfigurierte .npmignore- oder files-Angabe in der package.json kann alles offenlegen."

31. März: axios und ein weiterer Trojaner in der Supply Chain

Am selben Tag zielte eine weitere Kampagne auf das npm-Paket axios – einen JavaScript-HTTP-Client mit über 100 Millionen wöchentlichen Downloads.

Über ein kompromittiertes Maintainer-Konto wurden manipulierte Versionen (1.14.1 und 0.30.4) veröffentlicht. Eine eingeschleuste Dependency ([email protected]) installierte einen Remote-Access-Trojaner, der unter macOS, Windows und Linux lauffähig war. Beide Release-Branches wurden innerhalb von 39 Minuten getroffen, und die Malware war so konzipiert, dass sie sich nach der Ausführung selbst löschte.

Die Muster hinter diesen Angriffen

Über alle fünf Vorfälle hinweg zeichnen sich drei Angriffsmuster ab – und alle nutzen das implizite Vertrauen aus, das CI/CD-Pipelines ihren Eingaben entgegenbringen.

Muster 1: Vergiftete Tools und Actions

Die TeamPCP-Kampagne nutzte eine grundlegende Annahme aus: dass die Sicherheitstools, die innerhalb der Pipeline laufen, selbst vertrauenswürdig sind. Wenn ein GitHub-Action-Tag oder eine PyPI-Paketversion auf Schadcode verweist, führt die Pipeline diesen mit vollem Zugriff auf Umgebungs-Secrets, Cloud-Zugangsdaten und Deployment-Tokens aus. Es gibt keinen Verifizierungsschritt, weil die Pipeline dem Tag vertraut.

Empfohlene Pipeline-Kontrolle: Tools und Actions an unveränderliche Referenzen (Commit-SHAs oder Image-Digests) pinnen statt an veränderliche Versions-Tags. Wo Pinning nicht praktikabel ist, die Integrität von Tools und Dependencies gegen bekannte Prüfsummen oder Signaturen verifizieren. Die Ausführung blockieren, wenn die Verifizierung fehlschlägt.

Muster 2: Packaging-Fehlkonfigurationen, die IP leaken

Eine fehlkonfigurierte Build-Pipeline lieferte Debugging-Artefakte direkt im Produktionspaket aus. Eine falsch konfigurierte .npmignore- oder files-Angabe in der package.json reicht dafür aus. Ein Validierungsschritt vor der Veröffentlichung sollte das jedes Mal abfangen.

Empfohlene Pipeline-Kontrolle: Vor jeder Paketveröffentlichung automatisierte Prüfungen ausführen, die den Paketinhalt gegen eine Allowlist validieren, unerwartete Dateien (Source Maps, interne Konfigurationen, .env-Dateien) kennzeichnen und den Publish-Schritt blockieren, wenn die Prüfungen fehlschlagen.

Muster 3: Schwachstellen in transitiven Dependencies

Der axios-Angriff zielte nicht nur auf direkte axios-Nutzer, sondern auf jeden, dessen Dependency-Tree auf die kompromittierte Version auflöste. Eine einzige vergiftete Dependency in einem Lockfile kann sich so über die gesamte Build-Infrastruktur einer Organisation ausbreiten.

Empfohlene Pipeline-Kontrolle: Dependency-Prüfsummen gegen den bekannten Lockfile-Stand vergleichen. Unerwartete neue Dependencies oder Versionsänderungen erkennen. Builds blockieren, die nicht verifizierte Pakete einführen.

Wie GitLab Pipeline Execution Policies jedes Angriffsmuster adressieren

GitLab Pipeline Execution Policies (PEPs) ermöglichen es Security- und Plattformteams, verpflichtende CI/CD-Jobs in jede Pipeline einer Organisation einzufügen – unabhängig davon, was in der .gitlab-ci.yml definiert ist. Durch PEPs definierte Jobs können nicht übersprungen werden, auch nicht mit den Direktiven [skip ci] oder [no_pipeline]. Jobs können in reservierten Stages (.pipeline-policy-pre und .pipeline-policy-post) ausgeführt werden, die die Pipeline des Entwicklungsteams einrahmen.

Wir haben einsatzbereite Pipeline Execution Policies für alle drei Muster als Open-Source-Projekt veröffentlicht: Supply Chain Policies. Diese Policies sind unabhängig voneinander deploybar, und jede wird mit Testdaten für Verstöße ausgeliefert, um sie vorab zu testen. So funktioniert jede einzelne.

Use Case 1: Versehentliche Offenlegung beim Package-Publishing verhindern

Problem: Eine Source-Map-Datei landete im npm-Paket eines AI-Coding-Tools, weil die Build-Pipeline die Validierung beim Publishing übersprungen hatte.

PEP-Ansatz: Wir haben eine Open-Source Pipeline Execution Policy für genau diese Fehlerklasse erstellt: Artifact Hygiene.

Die Policy injiziert .pipeline-policy-pre-Jobs, die den Artefakttyp (npm-Paket, Docker-Image oder Helm-Chart) automatisch erkennen und den Inhalt prüfen, bevor ein Publish-Schritt ausgeführt wird. Für npm-Pakete führt sie drei Prüfungen durch:

1. File-Pattern-Blocklist. Scannt die npm-pack-Ausgabe nach Source Maps (.map), Testverzeichnissen, Build-Konfigurationen, IDE-Einstellungen und src/-Verzeichnissen.
2. Package-Size-Gate. Blockiert Pakete über 50 MB – wie das 59,8-MB-Paket, das den AI-Tool-Quellcode leakte.
3. sourceMappingURL-Scan. Erkennt externe URLs (das R2-Bucket-Muster, das den Quellcode eines großen AI-Unternehmens offenlegte), Inline-data:-URIs und lokale Dateireferenzen in JavaScript-Bundles.

Wenn Verstöße gefunden werden, schlägt die Pipeline mit einem klaren Bericht in den CI-Job-Logs fehl:

      =============================================
FAILED: 3 violation(s) found
=============================================
BLOCKED: dist/index.js.map (matched: \.map$)
BLOCKED: dist/index.js contains external sourceMappingURL
BLOCKED: dist/utils.js contains inline sourceMappingURL

This check is enforced by a Pipeline Execution Policy.
If this is a false positive, contact the security team to update the policy project or exclude this project.

    

Die Policy hat keine vom Nutzer konfigurierbaren CI-Variablen. Das Entwicklungsteam kann sie weder deaktivieren noch umgehen. Ausnahmen werden vom Security-Team auf Policy-Ebene verwaltet – das gewährleistet einen bewussten Prozess und einen lückenlosen Audit-Trail.

Das Repository enthält ein Testprojekt mit absichtlichen Verstößen (examples/leaky-npm-package/), um die Policy in Aktion zu sehen, bevor sie in der Organisation ausgerollt wird. Die README enthält eine vollständige Schnellstart-Anleitung für Einrichtung und Deployment.

Was das abfängt: Jede einzelne dieser Kontrollen hätte das Source-Code-Leak des AI-Unternehmens wahrscheinlich verhindert:

• Die Source-Map-Datei löst die File-Pattern-Blocklist aus.
• Die Größe von 59,8 MB löst das Size-Gate aus.
• Die sourceMappingURL mit Verweis auf einen externen R2-Bucket löst den URL-Scan aus.

Use Case 2: Dependency-Tampering und Lockfile-Manipulation erkennen

Problem: Der axios-Angriff führte eine bösartige transitive Dependency (plain-crypto-js) ein, die bei der Installation einen RAT ausführte. Jeder, der während des Kompromittierungsfensters npm install ausführte, zog den Trojaner mit.

PEP-Ansatz: Die Dependency Integrity Policy injiziert .pipeline-policy-pre-Jobs, die das Paket-Ökosystem (npm oder Python) automatisch erkennen und drei Prüfungen durchführen:

Für npm-Projekte (ausgelöst durch package-lock.json, yarn.lock oder pnpm-lock.yaml):

1. Lockfile-Integrität. Führt npm ci --ignore-scripts aus, was fehlschlägt, wenn sich node_modules vom Lockfile-Stand unterscheiden würden. Dies erkennt Fälle, in denen die package.json aktualisiert, aber das Lockfile nicht neu generiert wurde, und verifiziert gleichzeitig SRI-Integritäts-Hashes.
2. Blocked-Package-Scan. Gleicht den vollständigen Dependency-Tree des Lockfiles mit blocked-packages.yml ab – einer von GitLab gepflegten Liste bekannter kompromittierter Paketversionen. Die mitgelieferte Blocklist enthält [email protected], [email protected] und [email protected].
3. Erkennung nicht deklarierter Dependencies. Vergleicht nach der Installation den Inhalt von node_modules mit dem Lockfile. Jedes Paket, das auf der Festplatte vorhanden, aber nicht im Lockfile aufgeführt ist, deutet auf Manipulation hin (z. B. ein kompromittiertes postinstall-Skript, das zusätzliche Pakete nachlädt).

Für Python-Projekte (ausgelöst durch requirements.txt, Pipfile.lock, poetry.lock oder uv.lock):

1. Lockfile-Integrität. Installation in einer isolierten virtuellen Umgebung mit Verifizierung, dass die Installation aus dem Lockfile erfolgreich ist.
2. Blocked-Package-Scan. Derselbe Blocklist-Ansatz. Die mitgelieferte Liste enthält litellm==1.82.7 und litellm==1.82.8.
3. .pth-Datei-Erkennung. Scannt site-packages nach .pth-Dateien, die ausführbare Code-Muster enthalten (import os, exec(, eval(, __import__, subprocess, socket). Genau diesen Mechanismus nutzte die LiteLLM-Backdoor.

Bei einem erkannten Verstoß:

      =============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: [email protected] is a known-compromised package

This check is enforced by a Pipeline Execution Policy.

    

Die Policy läuft im Strict Mode: Jede Dependency, die nicht im committeten Lockfile vorhanden ist, blockiert die Pipeline. Wenn eine neue Dependency hinzugefügt werden soll, wird das aktualisierte Lockfile committet. Die Policy verifiziert, dass die installierte Version mit der committeten Version übereinstimmt. Wenn etwas auftaucht, das nicht committet wurde (z. B. eine transitive Dependency, die über ein kompromittiertes Upstream-Paket injiziert wurde), blockiert die Pipeline.

Was das abfängt: Die Einführung von plain-crypto-js als neue, bisher unbekannte Dependency würde durch die Erkennung nicht deklarierter Dependencies gemeldet. Die Version [email protected] wird durch den Blocked-Package-Scan erkannt. Die .pth-Datei von LiteLLM wird durch die .pth-Erkennung gefunden. Jeder Angriff hat mindestens ein – und oft zwei – unabhängige Erkennungssignale.

Use Case 3: Kompromittierte Tools vor der Ausführung erkennen und blockieren

Problem: TeamPCP ersetzte vertrauenswürdige Trivy- und Checkmarx-GitHub-Action-Tags durch bösartige Versionen. Jede Pipeline, die diese Tags referenzierte, führte Credential-Stealing-Malware aus.

PEP-Ansatz: Die Tool Integrity Policy injiziert einen .pipeline-policy-pre-Job, der die GitLab CI Lint API abfragt (oder als Fallback die .gitlab-ci.yml auswertet), die Container-Image-Referenzen extrahiert und mit einer vom Security-Team gepflegten Allowlist genehmigter Images abgleicht.

Die Allowlist (approved-images.yml) unterstützt drei Kontrollen pro Image:

Genehmigte Repositories: Nur Images aus gelisteten Repositories sind zulässig. Ein unbekanntes Repository blockiert die Pipeline.

Erlaubte Tags: Innerhalb eines genehmigten Repositorys sind nur bestimmte Tags zulässig. Das verhindert den Drift zu ungetesteten Versionen.

Blockierte Tags: Bekannte kompromittierte Versionen können explizit blockiert werden, selbst wenn das Repository genehmigt ist. Die mitgelieferte Allowlist blockiert aquasec/trivy:0.69.4 bis 0.69.6 – genau die Versionen, die TeamPCP trojanisiert hatte.

Bei einem erkannten Verstoß schlägt die Pipeline fehl, bevor ein anderer Job ausgeführt wird:

      =============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)
 - tag '0.69.4' is known-compromised
This check is enforced by a Pipeline Execution Policy.

    

Die Allowlist wird über Merge Requests gegen das Policy-Projekt gepflegt. Um ein neues genehmigtes Image hinzuzufügen, öffnet das Security-Team einen MR. Um auf eine neue Kompromittierung zu reagieren, wird ein blockierter Tag hinzugefügt. Keine Code-Änderungen nötig – nur YAML.

Was das abfängt: Wenn Images mit nicht genehmigten Tags erkannt werden, vergleicht die Policy die Image-Repository-Namen und Tags mit der Allowlist. Ein fehlgeschlagener Abgleich blockiert die Pipeline, bevor ein Scanner ausgeführt wird – und verhindert so die Exfiltration von Zugangsdaten.

Hinweis: Durch Erweiterung des obigen Beispiels können PEPs auch das Pinning auf Digests statt Tags erzwingen, was gegen Force-Pushes immun ist. Dieses Beispiel demonstriert ein einfacheres Tag-basiertes Enforcement-Muster.

Über PEPs hinaus: GitLabs Supply-Chain-Schutzmaßnahmen

Pipeline Execution Policies sind die Enforcement-Schicht – sie funktionieren aber am besten als Teil einer breiteren Defense-in-Depth-Strategie. GitLab bietet mehrere Funktionen, die PEPs beim Supply-Chain-Schutz ergänzen:

Secret Detection

GitLab Secret Detection verhindert, dass Zugangsdaten überhaupt im Repository landen, und reduziert so erheblich, was ein kompromittiertes Pipeline-Tool abgreifen kann. Im Kontext der Angriffe vom März 2026:

• In Repositories gespeicherte Zugangsdaten sind sowohl leichter für Angreifer auffindbar als auch langsamer zu rotieren. Der Trivy-Vorfall zeigte, dass selbst der Rotationsprozess ausgenutzt werden kann: Die Rotation von Aqua Security war nicht atomar, und der Angreifer erbeutete neu ausgestellte Tokens, bevor die alten vollständig widerrufen waren. GitLab Secret Detection umfasst die automatische Revokation geleakter GitLab-Tokens sowie eine Partner-API, die Drittanbieter benachrichtigt, damit diese ihre Zugangsdaten widerrufen – das beschleunigt die Reaktion im Falle eines Sicherheitsvorfalls.
• Secret Detection in Kombination mit ordnungsgemäßem Secret-Management (kurzlebige Tokens, Vault-gestützte Zugangsdaten, minimale Pipeline-Secret-Exposition) begrenzt, was ein Angreifer erreichen kann – selbst wenn ein vertrauenswürdiges Tool kompromittiert wird.

Dependency Scanning via Software Composition Analysis (SCA)

GitLab Dependency Scanning identifiziert bekannte Schwachstellen in Projektabhängigkeiten durch Analyse von Lockfiles und Manifests. Im Kontext der Angriffe vom März 2026:

• Für LiteLLM werden die kompromittierten Versionen (1.82.7, 1.82.8) in GitLabs Advisory-Datenbank geführt und betroffene Python-Projekte automatisch gemeldet.
• Für axios identifiziert Dependency Scanning die kompromittierten Versionen (1.14.1, 0.30.4) über alle Projekte der Organisation hinweg – das gibt Security-Teams eine zentrale Ansicht zur Bewertung des Blast-Radius und zur Priorisierung der Credential-Rotation.
• Ebenso werden alle npm-Pakete, die durch die CanisterWorm-Propagation von TeamPCP kompromittiert wurden, gemeldet, wenn sie in Verwendung sind.

GitLab Container Scanning erkennt verwundbare Container-Images in den Deployments. Für den Trivy-Vorfall meldet Container Scanning die trojanisierten Trivy-Docker-Images (0.69.4 bis 0.69.6), wenn sie in der Container Registry oder in Deployment-Manifests auftauchen.

Merge-Request-Approval-Policies

Merge-Request-Approval-Policies können die Genehmigung durch das Security-Team erfordern, bevor Änderungen an Dependency-Lockfiles oder CI/CD-Konfigurationen gemergt werden. Das stellt einen menschlichen Kontrollpunkt für genau die Art von Änderungen sicher, die Supply-Chain-Angriffe typischerweise einführen.

Demnächst: Dependency Firewall, Artifact Registry und SLSA Level 3 Attestation & Verification

Kommende Supply-Chain-Sicherheitsfunktionen in GitLab härten die Policy-Durchsetzung an zwei kritischen Kontrollpunkten: der Registry und der Pipeline. Die Dependency Firewall und Artifact Registry werden nicht-konforme Pakete blockieren, während die SLSA-Level-3-Attestation kryptografischen Nachweis liefert, dass Artefakte von genehmigten Pipelines erzeugt wurden und unverändert geblieben sind. Zusammen geben sie Security-Teams verifizierbare Kontrolle darüber, was in die Software-Supply-Chain eingeht und diese verlässt.

Was das für deine Organisation bedeutet

Inmitten zunehmender AI-gestützter Bedrohungen werden Angriffe auf CI/CD-Pipelines alltäglich. Die TeamPCP-Kampagne zeigt, wie ein einziges kompromittiertes Zugangsdaten-Set über ein Ökosystem vertrauenswürdiger Tools kaskadieren kann.

Wenn deine Organisation eine der betroffenen Komponenten eingesetzt hat, gehe davon aus, dass alle Pipeline-Secrets kompromittiert wurden: Rotiere sie umgehend und überprüfe Systeme auf persistente Backdoors. Unabhängig davon begrenzt die regelmäßige Rotation von Zugangsdaten und die Verwendung kurzlebiger Tokens den Blast-Radius jeder zukünftigen Kompromittierung.

Folgendes empfehlen wir:

1. Dependencies wenn möglich an Prüfsummen pinnen. Veränderliche Versions-Tags (wie die, die TeamPCP gekapert hat) sind keine Sicherheitsgrenze. SHA-gepinnte Referenzen für alle CI/CD-Komponenten oder Actions und Container-Images verwenden.
2. Pre-Execution-Integritätsprüfungen ausführen. Pipeline Execution Policies nutzen, um die Integrität von Tools und Dependencies vor der Ausführung jedes Pipeline-Jobs zu verifizieren. Das ist die .pipeline-policy-pre-Stage.
3. Prüfen, was veröffentlicht wird. Jeder Package-Publish-Schritt sollte eine automatisierte Validierung des Artefaktinhalts umfassen. Source Maps, Environment-Dateien und interne Konfigurationen sollten die Build-Umgebung niemals verlassen. Das Supply Chain Policy-Projekt bietet einen sofort einsetzbaren Ausgangspunkt für npm-, Docker- und Helm-Artefakte.
4. Dependency-Drift erkennen. Dependency-Auflösungen bei jedem Pipeline-Lauf gegen committete Lockfiles vergleichen. Auf unerwartete neue Dependencies achten.
5. Policy-Management zentralisieren. Sich nicht darauf verlassen, dass Entwicklungsteams daran denken, Security-Checks einzubinden. Diese auf Gruppen- oder Instanzebene über Policies durchsetzen, die nicht entfernt oder übersprungen werden können.
6. Davon ausgehen, dass Security-Tools selbst Ziele sind. Wenn dein Vulnerability-Scanner, SAST-Tool oder AI-Gateway kompromittiert werden kann, wird es das auch. Jedes Tool auf die minimal notwendigen Berechtigungen beschränken und sicherstellen, dass es auf nichts anderes zugreifen kann.

Schütze deine Pipelines mit GitLab

Innerhalb von zwei Wochen kompromittierten Angreifer Produktions-Pipelines bei Organisationen, die einige der am weitesten verbreiteten Tools im Software-Entwicklungs-Ökosystem einsetzten.

Die Lektion ist klar: Build-Pipelines brauchen denselben Grad an zentralem, Policy-gesteuertem Schutz, den wir auf Netzwerke und Cloud-Infrastruktur anwenden.

GitLab Pipeline Execution Policies bieten diese Enforcement-Schicht. Sie stellen sicher, dass Security-Checks in jeder Pipeline und in jedem Projekt ausgeführt werden – unabhängig von den einzelnen Projektkonfigurationen. In Kombination mit Dependency Scanning, Secret Detection und Merge-Request-Approval-Policies können sie die Angriffsklassen, die wir im März 2026 erlebt haben, blockieren, erkennen und eindämmen.

Das Supply Chain Policies-Projekt bietet eine funktionsfähige Pipeline Execution Policy, die genau die Fehlerklasse abfängt, die hinter dem Leak des großen AI-Unternehmens steckt – mit Abdeckung für npm-Pakete, Docker-Images und Helm-Charts. Klone es, deploye es in deiner Gruppe und stelle sicher, dass alle deine Pipelines für kommende Supply-Chain-Angriffe gewappnet sind.

Um mit zentralen Pipeline-Policies zu starten, registriere dich für eine kostenlose Testversion von GitLab Ultimate.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Abschnitt 27A des Securities Act von 1933 in der jeweils gültigen Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir davon ausgehen, dass die in diesen Aussagen wiedergegebenen Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse 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 Blogbeitrags zu aktualisieren oder zu revidieren, sofern dies nicht gesetzlich vorgeschrieben ist.