01Die OWASP Top 10 CI/CD Security Risks
Mit den Top 10 CI/CD Security Risks (v1.0, 2022) hat die OWASP Foundation die typischen Schwachstellen von Build- und Deployment-Umgebungen systematisch katalogisiert: „Insufficient Flow Control Mechanisms“ (CICD-SEC-1), „Inadequate Identity and Access Management“ (CICD-SEC-2), „Dependency Chain Abuse“ (CICD-SEC-3), „Poisoned Pipeline Execution“ (CICD-SEC-4), „Insufficient PBAC (Pipeline-Based Access Controls)“ (CICD-SEC-5), „Insufficient Credential Hygiene“ (CICD-SEC-6), „Insecure System Configuration“ (CICD-SEC-7), „Ungoverned Usage of 3rd Party Services“ (CICD-SEC-8), „Improper Artifact Integrity Validation“ (CICD-SEC-9) und „Insufficient Logging and Visibility“ (CICD-SEC-10). Der Katalog eignet sich als Prüfraster für ein strukturiertes Assessment der eigenen Pipeline-Landschaft – unabhängig davon, ob GitHub Actions, GitLab CI/CD oder Jenkins im Einsatz ist.
02Poisoned Pipeline Execution (CICD-SEC-4)
Bei Poisoned Pipeline Execution manipuliert ein Angreifer mit Zugriff auf das Quellcode-System den Build-Prozess, ohne die Build-Umgebung selbst kompromittieren zu müssen. OWASP unterscheidet drei Varianten: Bei Direct PPE (D-PPE) verändert der Angreifer die CI-Konfigurationsdatei direkt, bei Indirect PPE (I-PPE) schleust er Code in referenzierte Dateien wie Makefiles oder Test-Skripte ein, und Public PPE (3PE) nutzt Pull Requests anonymer Beitragender in öffentlichen Repositories. Wirksame Gegenmaßnahmen: ungeprüften Code nur auf isolierten Runnern ohne Zugriff auf Secrets ausführen, Pipelines externer Beitragender erst nach manueller Freigabe starten und CI-Konfigurationen aus geschützten Branches laden.
03Dependency Confusion und Dependency Chain Abuse (CICD-SEC-3)
„Dependency Chain Abuse“ bündelt Angriffe über die Paket-Lieferkette: Dependency Confusion, Dependency Hijacking, Typosquatting und Brandjacking. Bei Dependency Confusion veröffentlicht der Angreifer in einer öffentlichen Registry ein Paket unter dem Namen eines internen Pakets mit höherer Versionsnummer – löst der Paketmanager die Abhängigkeit bevorzugt aus der öffentlichen Quelle auf, gelangt der Schadcode in den Build. Der Sicherheitsforscher Alex Birsan wies die Technik 2021 in den Build-Systemen von mehr als 35 Organisationen nach, darunter Apple, Microsoft und PayPal. Gegenmaßnahmen sind ein interner Registry-Proxy als einzige Bezugsquelle, das Festschreiben von Paketversionen über Lock-Dateien samt Checksummen- und Signaturprüfung, Organisations-Scopes für private Pakete sowie die Ausführung von Installationsskripten in isolierten Kontexten ohne Zugriff auf Secrets.
04Secrets in Pipelines: kurzlebige OIDC-Credentials statt statischer Secrets
Pipelines benötigen Zugriff auf Registries, Cloud-Umgebungen und Deployment-Ziele – entsprechend sammeln sich dort Credentials. „Insufficient Credential Hygiene“ (CICD-SEC-6) beschreibt die Folgen: langlebige, breit berechtigte Secrets, die in Logs, Artefakten oder geforkten Repositories landen können. Der wirksamste Hebel ist der Umstieg auf föderierte, kurzlebige Credentials: Über OpenID Connect (OIDC) stellt die CI-Plattform pro Job ein signiertes Identitäts-Token aus, das der Cloud-Provider gegen eine zuvor definierte Vertrauensbeziehung prüft und gegen ein kurzlebiges Access-Token tauscht, das nur für diesen einen Job gilt und automatisch abläuft. Statisch hinterlegte Cloud-Credentials und manuelle Rotation entfallen damit weitgehend; Secret-Scanning und ein zentrales Secrets-Management bleiben als flankierende Maßnahmen notwendig.
05Härtung: Least-Privilege-Runner, Branch Protection, Signaturen
Least Privilege gilt auch für die Ausführungsumgebung: Runner sollten pro Pipeline nur die minimal nötigen Berechtigungen erhalten und idealerweise ephemer betrieben werden, also nach jedem Job verworfen. Branch-Protection-Regeln mit verpflichtenden Reviews und Status-Checks verhindern, dass ungeprüfte Änderungen – einschließlich manipulierter CI-Konfigurationen – den Hauptbranch erreichen; signierte Commits sichern die Urheberschaft von Änderungen ab. Signierte Artefakte und Provenance-Attestierungen erlauben es, vor dem Deployment kryptografisch zu prüfen, dass ein Artefakt tatsächlich aus der erwarteten Pipeline stammt – mit Sigstore/Cosign auch „keyless“ über kurzlebige, an eine OIDC-Identität gebundene Zertifikate und das öffentliche Transparenzlog Rekor. Damit adressieren Sie zugleich „Improper Artifact Integrity Validation“ (CICD-SEC-9); gegen „Insufficient Logging and Visibility“ (CICD-SEC-10) hilft eine lückenlose, zentral ausgewertete Protokollierung aller Pipeline-Aktivitäten.
06SLSA als Referenzrahmen für Build-Integrität
Supply-chain Levels for Software Artifacts (SLSA) ist eine branchenübergreifende Spezifikation unter dem Dach der OpenSSF (Linux Foundation), die Härtungsmaßnahmen in überprüfbare Stufen übersetzt. Der Build Track definiert die Levels L1 bis L3: von automatisch erzeugter Provenance, die dokumentiert, wie ein Artefakt gebaut wurde (L1), über signierte Provenance einer gehosteten Build-Plattform (L2) bis zu gehärteten, gegeneinander isolierten Builds, bei denen das Signaturmaterial für nutzerdefinierte Build-Schritte unerreichbar bleibt (L3). Die aktuelle Version 1.2 (Status „Approved“, 11/2025) ergänzt erstmals einen Source Track, der die Integrität des Quellcode-Managements adressiert. Ergänzende Umsetzungshilfen liefert NIST SP 800-204D (02/2024); eine vertiefte Einordnung finden Sie in unserem Wissensbeitrag zur SLSA-Supply-Chain-Security.
