01The OWASP Top 10 CI/CD Security Risks
With the Top 10 CI/CD Security Risks (v1.0, 2022), the OWASP Foundation has systematically catalogued the typical weaknesses of build and deployment environments: "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) and "Insufficient Logging and Visibility" (CICD-SEC-10). The catalogue works well as an assessment grid for a structured review of your own pipeline landscape – regardless of whether GitHub Actions, GitLab CI/CD or Jenkins is in use.
02Poisoned Pipeline Execution (CICD-SEC-4)
In poisoned pipeline execution, an attacker with access to the source code system manipulates the build process without having to compromise the build environment itself. OWASP distinguishes three variants: in Direct PPE (D-PPE), the attacker modifies the CI configuration file directly; in Indirect PPE (I-PPE), they inject code into referenced files such as makefiles or test scripts; and Public PPE (3PE) exploits pull requests from anonymous contributors to public repositories. Effective countermeasures: run unreviewed code only on isolated runners without access to secrets, start pipelines from external contributors only after manual approval, and load CI configurations from protected branches.
03Dependency Confusion and Dependency Chain Abuse (CICD-SEC-3)
"Dependency Chain Abuse" bundles attacks via the package supply chain: dependency confusion, dependency hijacking, typosquatting and brandjacking. In dependency confusion, the attacker publishes a package in a public registry under the name of an internal package with a higher version number – if the package manager resolves the dependency preferentially from the public source, the malicious code ends up in the build. Security researcher Alex Birsan demonstrated the technique in 2021 in the build systems of more than 35 organizations, including Apple, Microsoft and PayPal. Countermeasures include an internal registry proxy as the sole source of packages, pinning package versions via lock files together with checksum and signature verification, organization scopes for private packages, and executing installation scripts in isolated contexts without access to secrets.
04Secrets in Pipelines: Short-Lived OIDC Credentials Instead of Static Secrets
Pipelines need access to registries, cloud environments and deployment targets – so credentials naturally accumulate there. "Insufficient Credential Hygiene" (CICD-SEC-6) describes the consequences: long-lived, broadly privileged secrets that can end up in logs, artifacts or forked repositories. The most effective lever is switching to federated, short-lived credentials: via OpenID Connect (OIDC), the CI platform issues a signed identity token per job, which the cloud provider validates against a previously defined trust relationship and exchanges for a short-lived access token that is valid only for that single job and expires automatically. Statically stored cloud credentials and manual rotation are thus largely eliminated; secret scanning and centralized secrets management remain necessary as flanking measures.
05Hardening: Least-Privilege Runners, Branch Protection, Signatures
Least privilege also applies to the execution environment: runners should receive only the minimum permissions required per pipeline and ideally be operated ephemerally, i.e. discarded after every job. Branch protection rules with mandatory reviews and status checks prevent unreviewed changes – including manipulated CI configurations – from reaching the main branch; signed commits secure the authorship of changes. Signed artifacts and provenance attestations make it possible to cryptographically verify before deployment that an artifact actually originates from the expected pipeline – with Sigstore/Cosign even "keyless", using short-lived certificates bound to an OIDC identity and the public transparency log Rekor. This simultaneously addresses "Improper Artifact Integrity Validation" (CICD-SEC-9); against "Insufficient Logging and Visibility" (CICD-SEC-10), the answer is complete, centrally analyzed logging of all pipeline activity.
06SLSA as a Reference Framework for Build Integrity
Supply-chain Levels for Software Artifacts (SLSA) is a cross-industry specification under the umbrella of the OpenSSF (Linux Foundation) that translates hardening measures into verifiable levels. The Build Track defines levels L1 to L3: from automatically generated provenance documenting how an artifact was built (L1), through signed provenance from a hosted build platform (L2), to hardened, mutually isolated builds in which the signing material remains out of reach of user-defined build steps (L3). The current version 1.2 (status "Approved", 11/2025) adds a Source Track for the first time, addressing the integrity of source code management. NIST SP 800-204D (02/2024) provides complementary implementation guidance; you will find a deeper discussion in our knowledge article on SLSA supply chain security.
