Warum CI/CD-Pipelines zum bevorzugten Angriffsziel geworden sind
Der SolarWinds-Angriff begann nicht mit einer Phishing-E-Mail oder einem falsch konfigurierten S3-Bucket. Er begann innerhalb einer Build-Pipeline. Angreifer injizierten schädlichen Code direkt in den Software-Build-Prozess — und dieser Code wurde an mehr als 18.000 Kunden ausgeliefert, ohne dass ein einziger Sicherheitsalarm ausgelöst wurde. Das war 2020. Bis 2026 haben sich Supply-Chain-Angriffe auf CI/CD-Infrastrukturen laut CISA-Bericht zur Software-Supply-Chain-Bedrohung mehr als verdreifacht.
Die unbequeme Wahrheit: Die meisten Entwicklungsteams haben stark in Anwendungssicherheit investiert — SAST-Scans, DAST-Tests, Abhängigkeitsprüfungen — die Pipeline selbst aber nahezu ungeschützt gelassen. Wer die CI/CD-Umgebung kompromittiert, muss keine Kontrollen umgehen. Er schaltet sie einfach ab oder lässt sie scheinbar erfolgreich bestehen.
Dieser Leitfaden erklärt, was CI/CD-Sicherheit in der Praxis bedeutet, welche OWASP-Risiken am gefährlichsten sind, welche Tools in die Pipeline gehören und wie Best Practices umgesetzt werden können, ohne die Deployment-Geschwindigkeit zu bremsen.
Was ist CI/CD-Sicherheit?
CI/CD-Sicherheit schützt die gesamte Pipeline — vom Code-Commit über Build, Test und Artefaktspeicherung bis zur Auslieferung — vor Manipulation, unberechtigtem Zugriff, geheimem Datenverlust und bösartiger Paketinjektion. Sie verbindet Anwendungssicherheit, Infrastruktursicherheit und Supply-Chain-Integrität.
Die Pipeline ist im Wesentlichen eine privilegierte Ausführungsumgebung. Ein kompromittierter CI-Runner besitzt Zugangsdaten für Cloud-Provider, Container-Registries, Kubernetes-Cluster und Secrets Manager. Der Explosionsradius entspricht dem eines Senior-SRE mit Admin-Rechten in allen Umgebungen — kein Übertreibung, sondern die dokumentierte Angriffskette bei GitHub-Actions-Token-Hijacking-Schwachstellen.
OWASP Top 10 CI/CD-Sicherheitsrisiken
OWASP führt seine CI/CD Security Risks als eigenständige Taxonomie — getrennt von der klassischen Web-Application-Top-10. Die folgenreichsten Risiken im Überblick:
CICD-SEC-1: Unzureichende Flow-Kontrollmechanismen
Code gelangt ohne Review-Gates von Feature-Branches in die Produktion. Erzwingen Sie Branch-Protection-Regeln, Pflichtreviewer und Status-Checks, die nicht vom Committer übergangen werden können.
CICD-SEC-2: Unzureichendes Identity- und Access-Management
Gemeinsam genutzte Service-Accounts, langlebige API-Keys als Umgebungsvariablen, CI-Tokens mit organisationsweitem Scope. Jeder Pipeline-Job sollte kurzlebige, eng begrenzte Credentials verwenden — idealerweise OIDC-Federation mit dem Cloud-Provider.
CICD-SEC-3: Dependency-Chain-Missbrauch
Dependency-Confusion-Angriffe, Typosquatting und kompromittierte Maintainer-Accounts treffen hier. Sperren Sie Dependency-Dateien, nutzen Sie einen privaten Artefakt-Proxy und scannen Sie jedes Paket mit einem SCA-Tool.
CICD-SEC-4: Poisoned Pipeline Execution (PPE)
Ein Angreifer mit Schreibzugriff auf ein Repository — auch einen Fork — löst einen CI-Workflow aus, der im Kontext der Zielorganisation ausgeführt wird. Schränken Sie ein, welche Workflows bei Pull Requests aus Forks ausgelöst werden können.
CICD-SEC-5 bis CICD-SEC-10
Unzureichende PBAC, schlechte Credential-Hygiene, unsichere Systemkonfigurationen, fehlende Protokollierung, fehlende Artefakt-Integrität und unkontrollierte Drittanbieter-Services vervollständigen die Liste. Build-Artefakte sollten mit Sigstore/cosign signiert werden. Pipeline-Logs sollten manipulationssicher in einem SIEM gespeichert werden. Secret Detection sollte jeden Commit und jedes Build-Log nach Credential-Mustern durchsuchen.
Best Practices für CI/CD-Pipeline-Sicherheit
Shift Left — aber nicht dabei aufhören
SAST bei jedem Pull Request ist ein Muss. Aber Shift-Left adressiert nur den Quellcode. Zusätzlich braucht es Scans in der Build-Phase, der Artefaktphase (Signierung, SBOM) und der Deployment-Phase (Policy-Enforcement). Sicherheitsgates bei jedem Übergang.
SBOM-Generierung ist heute Standard
Generieren Sie für jeden Build-Artefakt ein Software-Bill-of-Materials im CycloneDX- oder SPDX-Format. Ihre Vulnerability-Management-Plattform sollte diese SBOMs konsumieren und mit NVD- und EPSS-Scores korrelieren.
Unveränderliche Artefakte und signierte Builds
Signieren Sie Container-Images mit cosign beim Build. Verifizieren Sie Signaturen beim Deployment mit Admission-Controllern. Container Image Scanning muss vor dem Push in die Registry erfolgen.
Policy as Code
Policy-as-Code definiert Pipeline-Sicherheitsanforderungen als maschinenlesbare Regeln — blockiert Builds mit Root-Container-Images, lehnt unsignierte Artefakte ab, verhindert Produktions-Deployments ohne Change-Ticket.
Top CI/CD-Security-Tools 2026
Semgrep für SAST, Gitleaks und TruffleHog für Secrets-Scanning, Trivy für Container-Images und SBOM-Generierung, Sigstore für Artefakt-Signierung. Plattformen wie SECRAILS integrieren diese Funktionen in einen einheitlichen DevSecOps-Workflow. Für Infrastructure-as-Code bieten Checkov und KICS Misconfiguration-Erkennung vor dem Deployment, ergänzt durch eine CSPM-Plattform für die Live-Umgebung.
CI/CD-Sicherheitsreife messen
Das SLSA-Framework, OpenSSF Scorecard und die OWASP CI/CD-Risikotaxonomie sind geeignete Maßstäbe. Ergebnisse sollten in das Compliance-Programm einfließen. Das größte Problem ist selten fehlende Tooling — es sind Prozesse ohne echte Blocking-Regeln und Sicherheitsgates mit zu vielen Ausnahmen. Starten Sie mit wenigen hochpräzisen Regeln. Erweitern Sie von dort aus.