Software Supply Chain Security: Ein risikobasiertes Reifegradmodell für CI/CD

In zwölf Tagen im März 2026 hat sich eine einzelne Angreifergruppe namens TeamPCP durch fünf große Open-Source-Projekte kaskadiert — und zwar ausgerechnet über die Security-Scanner, die eigentlich vor solchen Angriffen schützen sollten. Aus Trivys CI/CD-Pipeline gestohlene Credentials öffneten die Tür zu den PyPI-Publishing-Tokens von LiteLLM. Diese Tokens wiederum entriegelten das nächste Ziel — und das übernächste. Parallel dazu haben nordkoreanische staatliche Akteure Axios mit einer Backdoor versehen — 70 Millionen wöchentliche npm-Downloads — über einen einzigen kompromittierten Maintainer-Account. Und im gesamten IDE-Ökosystem sammelten 72 bösartige VS-Code-Extensions mit neun Millionen Installationen still und leise Entwickler-Credentials ein, lange bevor Code überhaupt eine Pipeline erreichte.

Die Software-Lieferkette ist längst kein Randthema mehr. Sie ist die primäre Angriffsfläche.

Dieser Artikel stellt ein risikobasiertes Reifegradmodell für CI/CD-Sicherheit vor — von grundlegender Hygiene bis zur vollständigen Zero-Trust-Attestierung — und stützt sich dabei auf die realen Vorfälle der Jahre 2024 bis Anfang 2026. Ob Sie als CISO eine Sicherheits-Roadmap aufsetzen oder als Engineering-Verantwortliche Ihre Pipelines härten wollen: Das Modell liefert einen klaren, stufenweisen Weg nach vorn.

Wenn Sie eine hands-on Ergänzung zu diesem Modell suchen, empfehlen wir unseren praxisnahen Leitfaden zu Container Supply Chain Security mit Sigstore, Cosign und Policy Enforcement, der eine funktionierende Implementierung von Artefakt-Signierung und -Verifikation Schritt für Schritt durchgeht.

Die wichtigsten Erkenntnisse

Die Kosten von Supply-Chain-Angriffen werden bis 2026 voraussichtlich 80,6 Milliarden US-Dollar überschreiten, und Gartner prognostizierte, dass bis 2025 45 % der Organisationen von einem Supply-Chain-Angriff betroffen sein werden.
Angreifer nehmen inzwischen zuerst die Beschützer ins Visier. Security-Scanner wie Trivy und Checkmarx laufen mit den weitreichendsten Berechtigungen in der CI/CD-Umgebung — genau das macht sie zu hochwertigen Pivot-Punkten. Die Kompromittierung von Trivy kaskadierte bis in einen bestätigten Einbruch in Ciscos Entwicklungsumgebung.
Veränderbare Git-Tags sind eine kritische Sicherheitsgrenze. Tag-Repointing-Angriffe leiten Konsumenten still und leise auf vergifteten Code um, ohne die Commit-Historie zu verändern.
Der Entwickler-Arbeitsplatz gehört zur Lieferkette. IDE-Extensions und Editor-Plugins sind ausführbare Bestandteile der Software-Lieferkette und müssen entsprechend gesteuert werden.
Statische Credentials sind die Wurzel kaskadierender Kompromittierungen. Just-In-Time-Credentials (Level 3), die nur kurz gültig sind, verhindern, dass eine einzelne Kompromittierung das nächste Ziel aufschließt.
EU CRA und NIS2 machen das rechtlich verbindlich. SBOM-Pflicht, Lieferantenrisikomanagement und Meldepflichten bei Vorfällen sind für Organisationen im EU-Markt keine Option mehr.
Ein vierstufiges Reifegradmodell — von der Basishygiene bis zur Zero-Trust-Attestierung — liefert eine strukturierte Roadmap im Einklang mit SLSA und dem NIST SSDF.

Die eskalierende Bedrohungslage in CI/CD

Warum ist die Software-Lieferkette die primäre Angriffsfläche?

Angreifer haben ihren Fokus verlagert: weg von der Ausnutzung einzelner Endpunkt-Schwachstellen, hin zur Kompromittierung der vorgelagerten Prozesse, die vertrauenswürdige Software-Artefakte erzeugen. Eine einzige Kompromittierung innerhalb einer CI/CD-Pipeline führt zu Code-Ausführung auf potenziell Tausenden nachgelagerter Systeme — die vertrauenswürdige Infrastruktur des Herstellers wird damit zum Verteilkanal für Schadcode.

Die Angriffe auf SolarWinds und 3CX haben dieses Modell vorgeführt. Die Vorfälle 2024–2026 haben es industrialisiert.

Wie hoch ist der finanzielle Schaden durch Supply-Chain-Angriffe?

Das finanzielle Risiko wächst rasant. Cybersecurity Ventures prognostiziert, dass die Kosten von Supply-Chain-Angriffen im Jahr 2025 weltweit 60 Milliarden US-Dollar übersteigen werden. Eine separate Studie von Juniper Research schätzt die Schäden bis 2026 auf über 80,6 Milliarden US-Dollar — ein Anstieg um 76 % gegenüber 2023. Gartner ging davon aus, dass 45 % der Organisationen bis 2025 einen Supply-Chain-Angriff erleben würden — eine Verdreifachung gegenüber 2021. Diese Zahlen machen CI/CD-Pipeline-Sicherheit zu einer treuhänderischen Verantwortung, nicht nur zu einem technischen Thema. Präventive Maßnahmen allein reichen nicht — Organisationen brauchen Resilienz, schnelle Erkennung und Eindämmung.

Signifikante Supply-Chain-Vorfälle: 2024–2026

XZ Utils: Die geduldige Backdoor (2024)

Die Kampagne rund um die XZ-Utils-Backdoor (CVE-2024-3094) hat einen bisher unerreichten Grad an Tarnung gezeigt. Ein Angreifer unter dem Pseudonym „Jia Tan” baute über rund zwei Jahre systematisch Vertrauen als Co-Maintainer auf, bevor er eine verschlüsselte Backdoor in die weit verbreitete XZ-Komprimierungsbibliothek einschleuste. Die Backdoor nutzte glibc-IFUNC-Tricks, um sich in den RSA-Authentifizierungspfad von OpenSSH einzuhaken, und ermöglichte damit uneingeschränkten Remote-Zugriff auf betroffene Systeme. Entdeckt wurde die Backdoor vom Microsoft-Ingenieur Andres Freund, dem Latenz-Anomalien beim SSH-Login aufgefallen waren. Der Vorfall hat bestätigt, dass selbst fundamentale Open-Source-Komponenten inzwischen Ziel hochentwickelter geopolitischer Operationen sind.

Die Aufarbeitung offenbarte eine anhaltende Lücke bei der Artefakt-Hygiene. Zwar wurden stabile Versionen schnell gepatcht, doch Forscher fanden später Debian-Docker-Entwicklungs-Images auf Docker Hub, die nach wie vor die kompromittierte XZ-Utils-Backdoor enthielten. Das ist deshalb relevant, weil latente Bedrohungen in ungepflegten Registries bereinigte Produktionssysteme erneut infizieren können. Eine wirksame Sicherheitsreife erfordert eine kontinuierliche Integritätsprüfung von Artefakten, die über die Produktion hinaus auch alle Entwicklungs- und Staging-Registries umfasst.

Polyfill.io: Domain-Hijack im großen Stil (2024)

Die CDN-Domain Polyfill.io wurde Anfang 2024 von einem chinesischen Unternehmen (Funnull) übernommen. Der ursprüngliche Autor Andrew Betts warnte die Community sofort, sämtliche Referenzen auf die Domain zu entfernen. Bis Juni 2024 bestätigte Sansec, dass das Script aktiv Schadcode einschleuste — mobile Nutzer wurden über eine gefälschte Google-Analytics-Domain auf Betrugsseiten umgeleitet, Daten wurden gestohlen und potenziell Remote-Code ausgeführt. Der Angriff erstreckte sich zudem auf verwandte CDNs wie BootCDN, Bootcss und Staticfile, die alle demselben Betreiber zugeordnet werden konnten.

Die Reaktion der Branche war alarmierend langsam. Trotz umfangreicher Benachrichtigungen stellte Censys fest, dass am 2. Juli 2024 noch über 384.000 Hosts das Schadscript einbanden — Monate nachdem die Kompromittierung öffentlich bekannt geworden war. Google reagierte damit, Anzeigen für Websites zu blockieren, die auf polyfill.io verwiesen, und Cloudflare setzte automatisches URL-Rewriting ein, um Referenzen auf einen sicheren Mirror umzuleiten. Diese Lücke zwischen Offenlegung und Behebung zeigt ein systemisches Unvermögen, kompromittierte externe Assets zu auditieren, zu tracken und zu blockieren. Eine wirksame Gegenmaßnahme braucht kontinuierliches Risiko-Scoring für alle Lieferanten und automatisierte Policy-as-Code-Durchsetzung (PaC), die Verbindungen zu kompromittierten Drittressourcen unverzüglich kappen kann.

Red Hat GitLab-Einbruch: Wenn die Entwicklungsumgebung selbst zum Ziel wird (Okt. 2025)

Der Einbruch im Oktober 2025 in eine GitLab-Instanz von Red Hat Consulting — zugeschrieben der Erpressergruppe Crimson Collective — hat den strategischen Wert offenbart, den die Kompromittierung von Build- und Kollaborationsumgebungen für Angreifer hat. Red Hat bestätigte, dass Angreifer rund 570 GB komprimierte Daten aus über 28.000 internen Repositories exfiltrierten (BleepingComputer, SecurityWeek, 404 Media), darunter CI-Secrets, Konfigurationen und Hunderte von Customer Engagement Reports (CERs) mit Architekturdiagrammen, Netzwerkkarten und Authentifizierungs-Tokens. Die Folgeschäden waren erheblich — Nissan bestätigte, dass 21.000 Kunden betroffen waren. Die FINRA gab einen Cybersecurity-Alert heraus und forderte Finanzdienstleister auf, ihre Exposition zu prüfen.

Der Verlust von Blaupausen der Kundeninfrastruktur wiegt weit schwerer als gestohlener Quellcode. Der Vorfall belegt: Organisationen müssen alle CI/CD-Umgebungen verteidigen — einschließlich derer für interne Beratung oder Sekundärprojekte — und zwar mit Zero-Trust-Kontrollen, Mikrosegmentierung und Just-In-Time-Zugriffsrichtlinien (JIT).

tj-actions/changed-files: Der Proof of Concept (März 2025)

Im März 2025 zeigte ein Supply-Chain-Angriff auf tj-actions/changed-files — eine GitHub Action, die in über 23.000 Repositories eingesetzt wird — die Tag-Repointing-Technik, die zwölf Monate später von TeamPCP industrialisiert werden sollte. Die Angriffskette nutzte transitives Vertrauen: Der Angreifer kompromittierte zunächst reviewdog/action-setup (CVE-2025-30154), das wiederum eine Dependency von tj-actions/eslint-changed-files war, das seinerseits von tj-actions/changed-files konsumiert wurde (CVE-2025-30066).

Indem er Versions-Tags nachträglich auf bösartige Commits umbog, schleuste der Angreifer ein Base64-kodiertes Payload ein, das auf den Speicher des Runner.Worker-Prozesses zugriff, CI/CD-Secrets extrahierte und diese in die Build-Logs schrieb — womit Secrets in jedem öffentlichen Repository, das die Action nutzte, offen einsehbar waren.

Palo Alto Networks’ Unit 42 belegte, dass die Kampagne ursprünglich Coinbase-Repositories ins Visier nahm, bevor sie in einen breiten, wahllosen Angriff eskalierte. Dieses Muster — zielgerichtete Erstinfektion gefolgt von opportunistischer Massenausnutzung — entspricht der Vorgehensweise fortgeschrittener persistenter Bedrohungen (APT).

Der Angriff wurde in Echtzeit von StepSecurity’s Harden-Runner erkannt, einem eBPF-basierten Security-Agenten für CI/CD, der anomale Netzwerk-Egress-Aktivitäten meldete. Ohne kernel-nahe Sichtbarkeit auf das Netzwerkverhalten der Runner wäre die Secret-Exfiltration lautlos durchgelaufen. CISA veröffentlichte formale Advisories zu den CVEs, und die OpenSSF publizierte Handreichungen für Maintainer zur Härtung von GitHub-Actions-Pipelines. Der tj-actions-Vorfall etablierte das Playbook — Tag-Repointing, Missbrauch transitiver Dependencies und Secret-Ernte —, das TeamPCP zwölf Monate später im industriellen Maßstab ausführen sollte.

TeamPCP: Fünf Angriffe in zwölf Tagen (März 2026)

Zwischen dem 19. und 31. März 2026 führte TeamPCP (von Google als UNC6780 getrackt) eine Kaskadenkampagne durch, die in schneller Folge fünf große Open-Source-Projekte kompromittierte und ein verheerendes Muster demonstrierte: Aus einer Kompromittierung gewonnene Credentials finanzieren die nächste. Die Kampagne begann damit, Security-Tooling selbst zu waffnen — Tools, die mit erhöhten CI/CD-Rechten laufen — und nutzte dann gestohlene Credentials, um in höherwertige Ziele über mehrere Paket-Ökosysteme hinweg zu pivotieren (Unit-42-Analyse, ReversingLabs, CrowdStrike).

Phase 1 — Trivy (19. März). TeamPCP nutzte einen fehlkonfigurierten pull_request_target-Workflow in den GitHub Actions von Aqua Security aus, um ein privilegiertes Access-Token zu extrahieren — das Credential hatte eine unvollständige Rotation am 1. März überlebt. Sie force-pushten 76 von 77 Versions-Tags in aquasecurity/trivy-action und alle 7 Tags in aquasecurity/setup-trivy und lenkten damit vertrauenswürdige Referenzen auf bösartige Commits um, die einen mehrstufigen Credential-Stealer enthielten. Eine infizierte Trivy-Binary (v0.69.4) wurde auf GitHub Releases und in Container-Registries veröffentlicht (GitHub Advisory GHSA-69fq-xp46-6x23, The Hacker News, Microsoft Security Blog, Wiz). Weil Trivy der am weitesten verbreitete Open-Source-Vulnerability-Scanner im Cloud-Native-Ökosystem ist, wurde der Credential-Stealer in Tausenden CI/CD-Pipelines mit erhöhten Rechten ausgeführt.

Phase 2 — Checkmarx (23. März). Dasselbe Credential-Stealer-Muster kompromittierte die AST GitHub Actions von Checkmarx (The Hacker News, Sysdig, Kaspersky). Dass ein zweiter Security-Anbieter ins Visier geriet, bestätigte die Strategie: Zuerst die Beschützer kompromittieren, weil Security-Tools die weitreichendsten Rechte in der Pipeline besitzen.

Phase 3 — LiteLLM (24. März). Mit den in der Trivy-Phase geernteten CI/CD-Credentials veröffentlichte TeamPCP bösartige Versionen von BerryAIs LiteLLM-AI-Proxy-Bibliothek auf PyPI (Versionen 1.82.7 und 1.82.8). Die LiteLLM-Maintainer bestätigten, dass sie an eine kompromittierte Trivy-Version gepinnt waren, wodurch ihr PyPI-Publishing-Token offengelegt wurde (Sonatype, Datadog Security Labs, GitHub Issue #24518). Die Malware installierte eine .pth-Datei, die bei jedem Start eines Python-Prozesses ausgeführt wurde — ohne dass ein expliziter Import nötig gewesen wäre — und sammelte Umgebungsvariablen, SSH-Schlüssel, Cloud-Credentials und Kubernetes-Konfigurationen ein. Die bösartigen Pakete wurden von PyPI innerhalb von rund drei Stunden in Quarantäne genommen.

Phase 4 — Telnyx (27. März). Dieselbe Credential-Kaskade veröffentlichte bösartige Versionen des Telnyx-Python-SDK auf PyPI (Versionen 4.87.1 und 4.87.2) und dehnte den Angriff damit auf das Ökosystem der Telekommunikations-APIs aus (The Hacker News, JFrog, Akamai).

Phase 5 — Axios (31. März). Zwar wird der Axios-Vorfall einem separaten Akteur zugeschrieben (siehe eigenen Abschnitt weiter unten), doch er fiel in dasselbe Zwölf-Tage-Fenster und verstärkte damit die Vertrauenskrise in offene Paket-Registries.

Die nachgelagerten Folgen — Cisco (31. März). Die schwerwiegendste reale Konsequenz der TeamPCP-Kampagne wurde deutlich, als Cisco offenlegte, dass Angreifer in seine interne Entwicklungsumgebung eingedrungen waren — mit Credentials, die über die kompromittierte Trivy-GitHub-Action gestohlen worden waren. Die Auswirkungen waren gravierend: Angreifer klonten über 300 interne GitHub-Repositories mit Quellcode für Ciscos KI-Produkte (AI Assistant, AI Defense und unveröffentlichte Projekte) sowie Repositories von Unternehmenskunden — darunter Banken, BPOs und US-Regierungsbehörden (SDxCentral, SC Media). Mehrere AWS-Keys wurden entwendet und für nicht autorisierte Aktivitäten in Ciscos AWS-Accounts verwendet. Dutzende Entwickler- und Lab-Arbeitsplätze waren betroffen. Cisco isolierte Systeme, spielte kompromittierte Geräte neu auf und führte eine großflächige Rotation aller Credentials durch. In der Folge stellte die Erpressergruppe ShinyHunters eine Lösegeldforderung mit Deadline zum 3. April und behauptete zusätzlich, über 3 Millionen Salesforce-Datensätze von Cisco zu besitzen. Der Cisco-Vorfall verwandelt die TeamPCP-Kampagne von einem Open-Source-Supply-Chain-Vorfall in eine bestätigte Unternehmens-Kompromittierung — genau die Art kaskadierender Auswirkung, die Supply Chain Security zum Vorstandsthema macht.

Was bedeutet TeamPCP für Ihre Sicherheitsstrategie? Drei Dinge:

Die Integrität von Git-Tags ist eine kritische Sicherheitsgrenze. Veränderbare Tags erlauben es Angreifern, Konsumenten still auf vergifteten Code umzuleiten, ohne die Commit-Historie zu berühren. Erzwingen Sie Tag-Immutabilität und die Verifikation von Tag-Signaturen als Deployment-Gate.
Security-Tooling braucht denselben Zero-Trust-Ansatz wie produktive Dependencies. Pinnen Sie Tools per Digest, nicht per veränderbaren Tags. Überwachen Sie das Verhalten Ihrer Scanner mit unabhängigen Runtime-Kontrollen wie eBPF.
Skopieren Sie CI/CD-Secrets pro Job mit kurzlebigen Credentials. Wenn eine einzelne Kompromittierung über mehrere Ökosysteme kaskadieren kann, sind Ihre Secrets zu breit skopiert. Google-Forscher warnten, dass “hunderttausende gestohlener Secrets möglicherweise in Umlauf sind” — als Folge der TeamPCP-Kampagne (TechRadar).

Axios: Staatlich gesteuerter Dependency-Hijack (März 2026)

Am 31. März 2026 wurden zwei mit einer Backdoor versehene Versionen von Axios — dem JavaScript-HTTP-Client mit über 70 Millionen wöchentlichen npm-Downloads — veröffentlicht, nachdem ein nordkoreanischer staatlicher Akteur den npm-Account eines Haupt-Maintainers kompromittiert hatte (Google Cloud Blog, The Hacker News). Innerhalb eines rund dreistündigen Fensters (00:21–03:25 UTC) erschienen die Versionen 1.14.1 und 0.30.4 mit einer einzigen neuen Dependency: plain-crypto-js, dessen postinstall-Hook stillschweigend plattformspezifische Remote-Access-Trojaner (RAT) nachlud (Elastic Security Labs, Huntress, Snyk). Beide bösartigen Versionen wurden inzwischen von npm entfernt.

Microsoft Threat Intelligence schrieb den Angriff Sapphire Sleet zu, einem nordkoreanischen staatlichen Akteur, der auch als CryptoCore/CageyChameleon getrackt wird. Die Threat Intelligence Group (GTIG) von Google ordnete die Infrastruktur UNC1069 zu, einem finanziell motivierten, mit Nordkorea assoziierten Akteur, der mindestens seit 2018 aktiv ist — basierend auf einem aktualisierten WAVESHAPER-Implantat (Palo Alto Unit 42). Der RAT unterstützte macOS, Windows und Linux — jede CI/CD-Pipeline und jede Entwicklungsumgebung, die während des Expositionsfensters eine frische Installation durchführte, konnte still kompromittiert worden sein. Die Cyber Security Agency of Singapore veröffentlichte daraufhin ein formales Advisory.

Der Axios-Vorfall legt ein Risiko offen, das weder Code-Reviews noch SBOM-Analysen abfangen können: die Übernahme eines einzigen Maintainer-Accounts, über den bösartiger Code auf legitimem Wege veröffentlicht wird. Das früheste erkennbare Signal war das unerwartete Auftauchen von plain-crypto-js im Dependency-Baum — womit die Integritätsprüfung der Lockfile zur kritischen ersten Verteidigungslinie wird.

GlassWorm: Die IDE als Angriffsfläche (Okt. 2025 – März 2026)

Die GlassWorm-Kampagne zielte auf die Entwicklungsumgebung selbst — die IDE anstelle der Paket-Registry oder der CI/CD-Pipeline. Erstmals im Oktober 2025 in sieben OpenVSX-Extensions entdeckt, eskalierte die Kampagne Anfang 2026 dramatisch: Bis März 2026 waren mindestens 72 bösartige Open-VSX-Extensions mit über 9 Millionen kumulierten Installationen identifiziert (Socket.dev, BleepingComputer, Dark Reading).

Die Angreifer veröffentlichten harmlos wirkende Extensions, die beliebte Entwickler-Werkzeuge nachahmten — ESLint, Prettier, vscode-icons, WakaTime — sowie KI-basierte Coding-Assistenten, die sich als Claude Code und Codex ausgaben. Nachdem die Extensions den Marketplace-Review passiert und Nutzervertrauen aufgebaut hatten, wurden sie so aktualisiert, dass sie über den Missbrauch von extensionPack und extensionDependencies Abhängigkeiten auf separate Extensions mit dem GlassWorm-Loader deklarierten. Das VS-Code-Extension-Modell installiert referenzierte Dependencies automatisch — und zog damit das bösartige Payload ohne Nutzerinteraktion nach. Die Kampagne nutzte zudem gestohlene GitHub-Tokens, um Malware in über 151 Repositories zu force-pushen (März 2026).

Der Loader setzte fortgeschrittene Evasion-Techniken ein: unsichtbare Unicode-Zeichen, um bösartigen Code zu verstecken, Runtime-Entschlüsselung, EtherHiding (Solana-Blockchain-Transaktionen als Dead-Drop-C2-Resolver) und Locale-Prüfungen, um Systeme mit russischem Locale zu verschonen (Snyk, Malwarebytes). Zu den Zielen gehörten Credential-Diebstahl, Exfiltration von SSH-Schlüsseln, das Leerräumen von Kryptowährungs-Wallets sowie die Zwangsverpflichtung von Entwickler-Endpunkten als Netzwerk-Proxys.

Die zentrale Botschaft: Der Entwickler-Arbeitsplatz gehört zur Lieferkette. Kompromittierte Entwicklungsumgebungen lassen Credentials, Signaturschlüssel und Repository-Zugriffs-Tokens abfließen, lange bevor Code die Pipeline erreicht. IDE-Extensions und Editor-Plugins müssen wie ausführbare Bestandteile der Lieferkette behandelt werden — mit Allowlisting und Integritätsprüfung.

Was sind die zentralen CI/CD-Risiken?

Die oben genannten Vorfälle lassen sich sechs Risikokategorien zuordnen, die das Reifegradmodell adressiert:

Leaks bei Credentials und Secrets. Statische, langlebige Tokens, die von CI-Agents konsumiert werden, bleiben die am leichtesten ausnutzbare Bedrohung. Selbst in einem Vault verwahrte Secrets sind gefährlich, sobald sie länger als für ihren unmittelbaren Einsatz bestehen — gestohlene statische Credentials verschaffen Angreifern einen dauerhaften Zugang.
Bösartige Dependencies. Über die klassische Dependency Confusion und verwundbare Open-Source-Bibliotheken hinaus erstreckt sich das Risiko nun auch auf KI/ML — vergiftete Datensätze und mit Backdoors versehene Modelle (wie im NullifAI-Vorfall 2025) eröffnen Vektoren für versteckte Backdoors und verzerrte Ausgaben.
Vergiftete Pipelines (Configuration Injection). Angreifer modifizieren Pipeline-Definitionen (YAML, Build-Scripte), um beliebige Befehle in der hochprivilegierten Build-Umgebung auszuführen. Unsichere Voreinstellungen — großzügig gesetzte Agent-Scopes, keine Netzwerk-Mikrosegmentierung — verschärfen das Problem.
Manipulation von Artefakten. Unsignierte oder nicht verifizierte Build-Outputs können nach dem Build, aber vor dem Deployment ausgetauscht oder verändert werden. Ohne durchgängige Provenance-Prüfung (z. B. SLSA-Attestierungsketten) rutschen Backdoors unbemerkt durch.
Code- und Datenexfiltration. In einer kompromittierten Umgebung ziehen bösartige Jobs Quellcode, Konfigurationen, Kundendaten und Secrets ab. Egress-Filterung und Runtime-Monitoring sind hier unverzichtbar.
Unsichere Voreinstellungen und breiter Zugriff. Zu weit gefasste Konfigurationen — Self-Service-Provisionierung von Runnern, ungeprüfter Egress, unzureichendes IAM — ermöglichen rasches Lateral Movement nach der Erstinfektion.

Das Reifegradmodell für CI/CD-Sicherheit

Welche vier Reifegrade gibt es?

Das Modell integriert etablierte Standards des NIST Secure Software Development Framework (SSDF) sowie der Supply-chain Levels for Software Artifacts (SLSA). Jeder Level ist additiv — höhere Level enthalten alle Kontrollen der vorangegangenen.

Level 1 — Grundhygiene und Sichtbarkeit. Basiskontrollen zur Beseitigung einfach ausnutzbarer Schwachstellen: verpflichtende MFA, grundlegendes RBAC, initiales Vulnerability-Scanning, Protected Branches.

Level 2 — Automatisierte Prävention und Durchsetzung. Automatisierte präventive Kontrollen: SBOM-Erzeugung, initiales Code-Signing, Allowlists für zugelassene Actions. Deckt die Grundanforderungen des NIST SSDF ab und legt das Fundament für höhere SLSA-Level.

Level 3 — Assume Breach: Segmentierung und JIT-Zugriff. Eine „Assume Breach”-Haltung mit Fokus auf Blast-Radius-Reduktion: Just-In-Time-Credentials, unveränderliche Build-Agents, kontinuierliche Telemetrie, SBOM-Enforcement als Build-Gate.

Level 4 — Zero-Trust und durchgängige Attestierung. Verifizierbare Integrität über die gesamte Lieferkette hinweg: reproduzierbare Builds, Multi-Party-Code-Signing, flächendeckende Zero-Trust-Segmentierung, automatisierte Incident Response (MTTR < 1 Stunde). Erfüllt die höchsten SLSA-Attestierungsanforderungen.

Übersicht des Reifegradmodells

Domäne	Level 1 (Baseline)	Level 2 (Automatisierte Prävention)	Level 3 (JIT / segmentiert)	Level 4 (Zero-Trust / attestiert)
Identität / Zugriff	MFA verpflichtend; grundlegendes RBAC	Minimierung langlebiger Tokens; Review von Überberechtigung	JIT / zeitlich begrenzter Zugriff; automatisierte Rotation	Kontinuierliche Authentifizierung; Zero-Trust-Networking; Schlüsselrotation <24 h
Build-Konfiguration	Protected Branches; PR-Checks	Allowlist für Actions; initiales Code-Signing	Unveränderliche Agents; umfassendes Logging (OpenSSF)	Reproduzierbare Builds; vollständige SLSA-L4-Attestierung
Dependency-Governance	Grundlegende SCA-Scans; vertrauenswürdige Repos	Verpflichtende SBOM-Erzeugung; Allow-/Block-Listen	SBOM-Enforcement (Build-Stop bei Verwundbarkeit); Vendor-Review	Kontinuierliches Lieferanten-Risiko-Scoring; AI-BOMs
Secret-Management	Keine Secrets im Code; grundlegendes Scanning	Zentrale Vault-Anbindung (KMS); automatisiertes CI-Scanning	Ephemere Secrets (Token-Exchange pro Job)	Null statische Credentials; tägliche Rotation aller Schlüssel/Tokens
Monitoring / IR	Grundlegendes Logging	Anomalieerkennung; EDR auf Build-Nodes	Telemetrie ins SIEM; regelmäßiges Konfigurations-Audit	Automatisierte Remediation; Live Threat Hunting (eBPF Runtime)

Domänenweise Umsetzungs-Roadmap

Identity und Access Management: Von Vaults zu ephemeren Tokens

Wirksames Secret-Management muss über die reine Ablage von Secrets in einem Vault hinausgehen. Level 1 und 2 fordern zentrale Vaults (Cloud KMS, HashiCorp Vault) und Scanning-Tools wie Gitleaks, um „keine Secrets im Code” durchzusetzen. Level 3 verlangt die vollständige Abschaffung statischer Zugriffsrechte.

Was ist Just-In-Time-Zugriff (JIT)? JIT-Auslieferung bedeutet, dass Credentials, Tokens oder Schlüssel nur im exakten Moment der legitimen Nutzung verfügbar sind — und unmittelbar nach Abschluss des Jobs wieder entzogen werden. Das beruht auf ephemeren Credentials — Einmal-Tokens, die dynamisch für die Dauer eines konkreten Build-Jobs erzeugt und danach sofort deprovisioniert werden.

JIT-Auslieferung adressiert die zentrale Schwäche statischer Credentials: Standing Privilege. Selbst ein sicher im Vault verwahrtes Secret ist gefährlich, wenn ein kompromittierter CI-Agent es für Lateral Movement ausnutzen kann. JIT setzt Zero Standing Privilege durch — kompromittierte Server oder Logs werden nach Job-Ende wertlos. Damit wird direkt das Credential-Leakage-Risiko adressiert, das der Red-Hat-Vorfall demonstriert hat.

Level 4 verlangt kontinuierliche Authentifizierung basierend auf dem Echtzeit-Verhalten der Workloads sowie eine Rotation aller nicht-maschinenbezogenen Identitätsschlüssel innerhalb einer maximalen Lebensdauer von 24 Stunden.

Build-Konfiguration und Integrität

Level 2 setzt eine Allowlist zugelassener CI-Actions, Plugins und Drittanbieter-Tools durch — plus initiales Code-Signing von Commits oder Build-Rezepten.

Level 3 verlangt unveränderliche Build-Agents — containerisierte Runner, die für einen einzelnen Job provisioniert und unmittelbar danach zerstört werden. Damit können Angreifer keine Persistenz in der Build-Umgebung etablieren.

Level 4 fordert reproduzierbare (deterministische) Builds, bei denen identische Inputs stets identische Outputs erzeugen. Das ist das Fundament für vollständige SLSA-Build-Attestierung, die die komplette Provenance — Herkunft, Dependencies und Prozess — jedes Artefakts verifiziert und einen fälschungssicheren, manipulations-evidenten Nachweis liefert, dass das finale Artefakt dem intendierten Quellcode entspricht.

Dependency- und Open-Source-Governance

Level 2 verlangt verpflichtende SBOM-Erzeugung für alle Builds, Allow-/Block-Listen für Komponenten und eingecheckte Lockfiles.

Level 3 markiert den Übergang von Dokumentation zu Durchsetzung: SBOMs werden zum Policy-Gate. Builds brechen automatisch ab, wenn SBOMs fehlen oder Komponenten mit bekannten hochkritischen Schwachstellen entdeckt werden. Level 3 fordert außerdem strukturierte Sicherheitsprüfungen von Drittanbietern.

Level 4 institutionalisiert kontinuierliches Risiko-Scoring aller Lieferanten und Komponenten auf Basis von Schwachstellen-, Lizenz- und Provenance-Risiko. Die Governance erstreckt sich auf KI/ML durch AI-BOMs (ML-BOMs) für Daten und Modelle, unter Verwendung von Formaten wie CycloneDX 1.5+. Dies deckt die Dokumentationsanforderungen des EU Cyber Resilience Act (CRA) und der NIS2-Richtlinie ab.

Monitoring, Telemetrie und Incident Response

Level-1-Logging ist reaktiv. Level 3 fordert kontinuierliche Telemetrie, die in ein SIEM eingespeist wird, Anomalieerkennung (etwa das Flaggen neuer Admin-Tokens oder ungewöhnlicher IPs) und EDR auf persistenten Build-Nodes.

Level 4 erreicht Runtime-Verteidigung durch den Einsatz eBPF-basierten Monitorings innerhalb ephemerer CI/CD-Runner. Tools wie StepSecuritys Harden-Runner liefern kernel-nahe Sichtbarkeit und Netzwerk-Egress-Filterung, die den Traffic per Default auf zugelassene Endpunkte beschränkt.

Warum ist das wichtig? Fortgeschrittene Angriffe wie XZ Utils operieren verdeckt innerhalb der Ausführungsumgebung. Klassische Endpoint-Security funktioniert in ephemeren, containerisierten CI-Umgebungen häufig gar nicht. eBPF verwandelt die passive Build-Umgebung in eine aktive Verteidigungsfläche, die bösartiges Verhalten auf Kernel-Ebene mitten im Build erkennt und stoppt. Level 4 verlangt darüber hinaus kontinuierliches Threat Hunting und automatisierte Remediation-Playbooks, um die MTTR unter einer Stunde zu halten.

Absicherung der KI/ML-Lieferkette

Was sind die neuen Risiken in der KI/ML-Lieferkette?

Die Integration von KI/ML-Modellen in kommerzielle Produkte bringt neuartige Risiken in der Lieferkette. ML-Modelle sind nicht bloß Daten — sie sind ausführbare Artefakte.

Der NullifAI-Vorfall (Februar 2025) hat das bestätigt: Angreifer luden trojanisierte ML-Modelle auf Hugging Face hoch und nutzten einen „Broken Pickle”-Serialisierungstrick, um den Picklescan-Security-Scanner von Hugging Face zu umgehen. Beim Laden dieser Modelle wurde eine Reverse Shell aufgebaut, die die Entwicklersysteme kompromittierte. ML-Modell-Dateien — PyTorch-.pt-Dateien, serialisierte Pickle-Formate — müssen als potenziell bösartige ausführbare Dateien behandelt werden.

Diese Risiken lassen sich der OWASP GenAI Top 10 zuordnen:

LLM04 — Data and Model Poisoning: Manipulation von Trainings-, Fine-Tuning- oder Embedding-Daten, um Backdoors oder Verzerrungen einzuschleusen.
LLM02 — Sensitive Information Disclosure: LLMs, die unabsichtlich proprietäre Daten aus Trainingsdatensätzen oder System-Prompts preisgeben.

Welche KI/ML-Kontrollen fordert das Modell?

Level 3 verlangt verpflichtende Data-Provenance-Kontrollen, um Quelle und Transformationen aller Trainingsdaten nachzuverfolgen, sowie Prüfungen auf Bias, Toxizität und adversariale Robustheit vor dem Deployment.

Level 4 fordert:

AI-BOMs für alle produktiven Modelle, die Software-Dependencies, Datensätze, Trainingskonfigurationen und Modell-Lineage dokumentieren (CycloneDX 1.5+ unterstützt die ML-BOM-Spezifikation).
Fortgeschrittene Backdoor-Erkennung mit Techniken wie Interpretable Deep Learning (IBD) oder informationstheoretischen Verfahren, die unter Black-Box-Bedingungen signifikante Verbesserungen der Erkennungsgenauigkeit bei kompromittierten Modellen gezeigt haben.

Governance und Compliance

EU Cyber Resilience Act (CRA): Das SBOM wird zum Gesetz

Der CRA wurde Ende 2024 verabschiedet und tritt in einer gestaffelten Zeitschiene in Kraft. Er verpflichtet zu „Secure-by-Design”-Praktiken und legt strikte Pflichten für Softwareanbieter fest (Übersicht der EU-Digitalstrategie). Die vollständige Produkt-Compliance — inklusive umfassender SBOMs — ist bis Dezember 2027 verpflichtend.

Level 2–3 adressieren die Anforderungen aus CRA Artikel 10: verpflichtende SBOM-Erzeugung und -Durchsetzung, akribische Komponentendokumentation und proaktives Schwachstellenmanagement.
Level 4 sichert die Bereitschaft für die gestaffelten Deadlines ab: Meldepflichten für Schwachstellen und Vorfälle gelten ab September 2026, die vollständige Compliance ab Dezember 2027. Das KPI von MTTR < 1 Stunde ist mit den vorgeschriebenen Offenlegungsfristen kompatibel.

EU-NIS2-Richtlinie: Governance des Lieferketten-Risikos

NIS2 (mit einer bis Oktober 2024 vorgesehenen Umsetzung und unterschiedlicher Implementierung in den Mitgliedsstaaten) fordert Supply-Chain-Risikomanagement ausdrücklich (Übersicht der EU-Digitalstrategie).

NIS2 Artikel 21 verlangt das Management von Lieferketten-Risiken durch vertragliche Cybersicherheitsverpflichtungen der Lieferanten — direkt gedeckt durch die Vendor-Reviews aus Level 3 und die Governance-Praktiken aus Level 4.
Die Vorgaben von NIS2 zu Incident Handling und Meldung werden durch die automatisierte IR-Fähigkeit auf Level 4, forensische Bereitschaft und schnelle Meldeprozesse erfüllt.

US Executive Order 14028 und NIST-Alignment

Das Modell bewegt sich im Einklang mit der US Executive Order 14028 (2021) sowie den nachfolgenden Vorgaben von CISA und NIST. Die vierstufige Struktur von SLSA liefert einen präskriptiven Pfad, um die Anforderungen des NIST Secure Software Development Framework (SSDF) zu erfüllen.

Wie institutionalisieren Sie Compliance?

Machen Sie aus Compliance keine periodische Prüfung mehr, sondern kontinuierliche automatisierte Assurance:

Policy-as-Code-Enforcement. Kodieren Sie Policies (SBOM-Vorhandensein, Branch Protection, Schwellwerte des Secret-Scannings) mit Tools wie dem Open Policy Agent (OPA). Compliance-Gates werden in der Pipeline automatisch durchgesetzt — konsistent angewendet, prüfbar und manuell nicht umgehbar.
Der Evidenzpfad für Auditoren. Vollständige SLSA-Provenance-Logs, CI-Telemetrie und ML-BOMs liefern verifizierbare Nachweise sicherer Entwicklungspraktiken. Audits verschieben sich damit von manueller Dokumenten-Prüfung zur Echtzeit-Bestätigung.

Referenz technischer Kontrollen

Härtung der Source-Repositories

Signierte Commits. Verpflichtende kryptografische Signatur aller Commits zur Nicht-Abstreitbarkeit und um unautorisierte Code-Einschleusung zu verhindern (Level 2).
Branch Protection und RBAC. Kein direkter Push auf main, verpflichtender Review, striktes RBAC mit MFA für jeden Repository-Zugriff.
Action-Allowlisting. Beschränken Sie CI/CD-Actions und -Plugins auf eine freigegebene Allowlist.

Secret-Management und JIT-Umsetzung

Nutzung zentraler Vaults. Zentrale Vaults oder KMS (HashiCorp Vault, AWS Secrets Manager) für alle nicht-entwicklungsbezogenen Secrets verpflichtend machen (Level 2).
Architektur ephemerer Credentials. Token-Exchange, bei dem CI/CD-Agents sich mit einer nicht sensiblen Maschinen-Identität authentifizieren und daraufhin kurzlebige Session-Tokens für konkrete Operationen erhalten (Level 3).
Rotations-Policy. Automatische Credential-Rotation aller statischen Schlüssel und Tokens mit einer maximalen Lebensdauer von 24 Stunden (Level 4).

Least-Privilege-CI-Runner und Netzwerksegmentierung

Ephemere Agents. Containerisierte Build-Agents, die nach einer einzelnen Ausführung zerstört werden, verhindern Angreifer-Persistenz (Level 3).
Netzwerk-Mikrosegmentierung und Egress-Filterung. Beschränken Sie ausgehenden Traffic auf zugelassene Endpunkte (Paket-Registries, Vault-Server). Deaktivieren Sie den standardmäßigen Internet-Egress.
Runtime-Monitoring (eBPF). Kernel-nahe EDR auf der CI-Infrastruktur mittels eBPF, um unautorisierte Aktivitäten, ungewöhnliche Prozessausführungen und Host-Manipulationen zu erkennen (Level 4).

Artefakt-Integrität und Provenance

Code- und Artefakt-Signierung. Signieren Sie alle Binaries, Container und Deployment-Manifeste kryptografisch mit vertrauenswürdigen Schlüsseln des Build-Systems (Level 2/3).
Attestierungsketten. Vollständige Attestierung mit Frameworks wie in-toto, um Ausführungsumgebung, Dependencies und Build-Parameter zu dokumentieren (Level 3).
Anforderungen für SLSA L4. Reproduzierbare Builds und unveränderliche Registries, die unsignierte oder nicht-attestierte Artefakte ablehnen (Level 4).

KI/ML-spezifische Kontrollen

Modell-Scanning. Statische und dynamische Analyse importierter ML-Modelle auf bekannte bösartige Muster (Level 3). Siehe Hugging Face Picklescan für grundlegende Scanning-Fähigkeiten.
ML-BOM-Erzeugung. Automatische Erzeugung von ML-BOMs mit CycloneDX, die die Provenance der Trainingsdaten, die Modellarchitektur und Hyperparameter dokumentieren (Level 4).
Fortgeschrittene Backdoor-Erkennung. Multivariate-Interaction-basierte oder interpretable Deep-Learning-Techniken zur Backdoor-Erkennung in Black-Box-Modellen vor dem Deployment (Level 4).

Incident-Vorbereitung und forensische Bereitschaft

CI/CD-spezifischer IR-Plan. Ein eigenständiger Incident-Response-Plan, zugeschnitten auf Pipeline-Kompromittierungen (Level 3).
Forensische Aufbewahrung. Manipulations-evidente Logs aller Build-Metadaten, Ausführungstelemetrie und Pipeline-Konfigurationsänderungen, eingespeist ins SIEM (Level 3).
Playbooks für regulatorische Meldungen. Automatisierte Playbooks im Einklang mit den CRA- und NIS2-Meldefristen — 24-Stunden- und 72-Stunden-Fenster (Level 4).

Was sollten Sie als Nächstes tun?

Wenn Sie den Status quo in Ihrer Organisation einschätzen wollen, hier ein praktischer Ausgangspunkt für jeden Reifegrad:

Wenn Sie auf Level 0–1 stehen (keine formalen Kontrollen):

Erzwingen Sie MFA auf allen Repository- und CI/CD-Plattform-Accounts — das blockiert den häufigsten Account-Takeover-Vektor.
Aktivieren Sie Branch Protection auf allen main-Branches mit verpflichtendem Code-Review.
Führen Sie einen Secret-Scanner (z. B. Gitleaks) über Ihre Repositories und beseitigen Sie alle Funde.

Wenn Sie auf Level 1–2 stehen (grundlegende Kontrollen, keine Automatisierung):

Erzeugen Sie SBOMs für alle Builds und checken Sie Lockfiles ein — der CRA macht das verpflichtend.
Erstellen Sie eine freigegebene Allowlist für CI/CD-Actions und Drittanbieter-Plugins.
Bewegen Sie Secrets aus Umgebungsvariablen in einen zentralen Vault (KMS, HashiCorp Vault).

Wenn Sie auf Level 2–3 stehen (automatisiert, aber nicht segmentiert):

Implementieren Sie ephemere CI/CD-Credentials — ersetzen Sie statische Tokens durch JIT-Token-Exchange.
Wechseln Sie zu unveränderlichen Einweg-Build-Agents.
Machen Sie die SBOM-Validierung zum Build-Gate — Builds müssen scheitern, wenn SBOMs fehlen oder bekannte verwundbare Komponenten enthalten sind.

Wenn Sie auf Level 3 stehen (auf dem Weg zu Level 4):

Implementieren Sie reproduzierbare Builds und vollständige SLSA-L4-Attestierung.
Setzen Sie eBPF-basiertes Runtime-Monitoring (z. B. StepSecurity Harden-Runner) auf CI/CD-Runnern ein.
Pinnen Sie alle Dependencies — einschließlich Security-Tools — per Digest, nicht per veränderbaren Tags.
Etablieren Sie automatisierte Incident-Response-Playbooks mit einem MTTR-Ziel unter einer Stunde.

Fazit

Die signifikanten Vorfälle der Jahre 2024 bis Anfang 2026 — von der tiefen Tarnung des XZ-Utils-Angriffs über die TeamPCP-Kaskadenkampagne, die Security-Scanner selbst zur Waffe machte, den staatlich gesteuerten Hijack von Axios bis hin zur systematischen Kompromittierung von Entwickler-IDEs durch GlassWorm — bestätigen, dass die klassischen Sicherheitsmodelle überholt sind.

Das Reifegradmodell für CI/CD-Sicherheit liefert einen strukturierten Weg von der Basishygiene zu kontinuierlicher Assurance und Zero Trust. Die Weiterentwicklung erfordert drei strategische Schwenks:

Standing Privilege beseitigen. Weg von im Vault verwahrten Secrets hin zu Just-In-Time-Credentials (Level 3). Damit können Angreifer gestohlene Tokens nicht mehr für Persistenz oder Lateral Movement nutzen.
Zur Laufzeit und auf Artefakt-Ebene verifizieren. Vollständige SLSA-L4-Attestierung und reproduzierbare Builds — kombiniert mit eBPF-Runtime-Verteidigung (Level 4) — verwandeln die Pipeline in eine verifizierbare Produktionsstätte, die Einschleusungsversuche mitten im Build erkennt.
Governance institutionalisieren. SBOM-Enforcement erfüllt die Transparenzanforderungen des EU CRA. Kontinuierliches Lieferanten-Risiko-Scoring und schnelle Incident Response stehen im Einklang mit NIS2. ML-BOMs schaffen Bereitschaft für die aufkommende regulatorische Landschaft rund um die KI-Lieferkette.

Die CI/CD-Pipeline ist der zentrale Knotenpunkt für geistiges Eigentum und Vertrauen. Verteidigen Sie sie entsprechend.

Quellen

Finanzieller Schaden und Branchenanalysen

XZ Utils (CVE-2024-3094)

Andres Freund — Ursprüngliche Offenlegung auf oss-security (29. März 2024)
Red Hat — Urgent Security Alert for Fedora 41 and Rawhide Users (29. März 2024)
CISA Alert — CVE-2024-3094 (29. März 2024)

Polyfill.io

Sansec — Polyfill Supply Chain Attack Hits 100K+ Sites (25. Juni 2024)
BleepingComputer — Polyfill.io Supply Chain Attack Impacts Over 100K Sites (25. Juni 2024)
Censys — Over 384,000 Hosts Still Referencing Malicious Polyfill.io Domain (2. Juli 2024)

tj-actions/changed-files (CVE-2025-30066, CVE-2025-30154)

Standards und Frameworks

Regulatorik

EU Cyber Resilience Act — Verordnung (EU) 2024/2847 (Verabschiedet Oktober 2024)
EU CRA — Übersicht der EU-Digitalstrategie
EU-NIS2-Richtlinie — Richtlinie (EU) 2022/2555 (Verabschiedet November 2022)
EU NIS2 — Übersicht der EU-Digitalstrategie
US Executive Order 14028 — Improving the Nation’s Cybersecurity (12. Mai 2021)