Key takeaways
- The main OWASP Top 10 (see our guide to the 2025 edition) scopes to risks in a deployed web application itself.
- Each risk's References section ties the definition to a specific, named incident rather than a hypothetical.
- Start with CICD-SEC-1 and CICD-SEC-4 together.
The OWASP Top 10 CI/CD Security Risks project is OWASP's risk taxonomy for the pipeline infrastructure that moves code from a developer's workstation to production — source control, CI orchestration, artifact repositories, secrets management and the third-party services wired into all of them. Per its own introduction, the list is "the result of extensive research into attack vectors associated with CI/CD, and the analysis of high profile breaches and security flaws," naming the SolarWinds build-system compromise, the Codecov secrets breach, a backdoored PHP release pushed straight to the project's own git repository, the Dependency Confusion flaw, and the ua-parser-js/coa/rc NPM package compromises as the incidents that motivated it. The project is led by Daniel Krivelevich and Omer Gil of Cider Security, with Ory Segal (then of Palo Alto Networks) as a third project leader on OWASP's own repository, and its content is dual-licensed Apache-2.0 / CC BY-SA 4.0.
Why a separate Top 10 for the pipeline
The main OWASP Top 10 (see our guide to the 2025 edition) scopes to risks in a deployed web application itself. CI/CD systems are a distinct attack surface: an attacker who compromises the pipeline doesn't need to find a vulnerability in the shipped application at all — they can inject one during the build, or ship a malicious artifact that was never reviewed. The project's own framing makes this explicit: CI/CD systems are "the beating heart of any modern software organization," and because "the integration of a new service typically requires no more than adding 1-2 lines of code," the attack surface has grown faster than most organizations' controls around it.
The ten risks
Each of the ten follows the same Definition / Description / Impact / Recommendations / References structure in the source document:
| # | Risk | What it is |
|---|---|---|
| CICD-SEC-1 | Insufficient Flow Control Mechanisms | An attacker with access to one pipeline system (SCM, CI, artifact repository) pushes malicious code or artifacts downstream — "without being required to undergo a strict set of reviews and approvals" |
| CICD-SEC-2 | Inadequate Identity and Access Management | Poorly managed human and programmatic identities spread across SCM, CI, artifact repository and deployment systems increase "the potential and the extent of damage" of any one account's compromise |
| CICD-SEC-3 | Dependency Chain Abuse | Flaws in how workstations and build environments fetch code dependencies let "a malicious package inadvertently [be] fetched and executed locally when pulled" |
| CICD-SEC-4 | Poisoned Pipeline Execution (PPE) | An attacker with source-control access, but no build-environment access, injects malicious commands into pipeline configuration to run code as part of the build |
| CICD-SEC-5 | Insufficient PBAC (Pipeline-Based Access Controls) | Once code runs inside a pipeline node, an attacker abuses that node's own permissions "for moving laterally within or outside the CI/CD system" |
| CICD-SEC-6 | Insufficient Credential Hygiene | Weak access controls, insecure secret storage or overly permissive credentials let an attacker obtain and reuse secrets and tokens scattered through the pipeline |
| CICD-SEC-7 | Insecure System Configuration | Hardening and configuration gaps across SCM, CI and artifact-repository systems become "low hanging fruits" for an attacker expanding their foothold |
| CICD-SEC-8 | Ungoverned Usage of 3rd Party Services | Third-party integrations "effectively expand[] the attack surface of the organization" because granting them access is trivially easy |
| CICD-SEC-9 | Improper Artifact Integrity Validation | Insufficient validation of code or artifacts lets an attacker with access to one pipeline system push malicious — but seemingly benign — content downstream |
| CICD-SEC-10 | Insufficient Logging and Visibility | Gaps in logging let an adversary operate inside the CI/CD environment undetected, and hamper reconstructing their techniques during a post-incident investigation |
Worked incidents, not just abstract categories
Each risk's References section ties the definition to a specific, named incident rather than a hypothetical. CICD-SEC-1's references include the PHP git backdoor (an attacker pushed malicious unreviewed code directly to the PHP project's main branch, which shipped in an official PHP release) and a documented bypass of GitHub's required-reviews mechanism via GitHub Actions. That pattern — a concrete, cited precedent attached to each risk — is what distinguishes this project from a generic pipeline-hardening checklist: the Recommendations in each entry are written to close the specific technique the attached incidents used, not just general best practice.
How this maps onto firmware and device supply-chain controls
For a firmware or embedded device maker, CICD-SEC-3 (Dependency Chain Abuse) and CICD-SEC-9 (Improper Artifact Integrity Validation) describe the same gaps that SLSA's provenance levels and in-toto attestation are designed to close — a build pipeline that can't prove where an artifact came from or verify its integrity before shipping it is exposed to both. CICD-SEC-2 and CICD-SEC-5 (identity and pipeline-based access control) overlap with the CI-runner and service-account scoping checks in OpenSSF Scorecard. Because the same pipeline that compiles and signs a firmware image typically also generates its SBOM (see Firmware SBOM), a successful CICD-SEC-4 (Poisoned Pipeline Execution) attack or a CICD-SEC-9 integrity-validation gap can corrupt the firmware image and invalidate the SBOM's accuracy in the same incident — which is why pipeline hardening and SBOM/provenance work are best treated as one workstream rather than two.
A workable starting point
Start with CICD-SEC-1 and CICD-SEC-4 togetherFlow control (who can push unreviewed code to production) and Poisoned Pipeline Execution (who can inject commands into the pipeline configuration itself) are the two risks with the most direct path from a single compromised account to a shipped malicious artifact. Inventory third-party CI/CD integrations before adding new onesCICD-SEC-8's own framing — that granting a new service access takes "no more than adding 1-2 lines of code" — means the attack surface tends to grow by default unless someone is actively reviewing what has access to what. Treat pipeline service-account permissions as a lateral-movement risk, not just a build dependencyCICD-SEC-5 (PBAC) exists because pipeline nodes often hold credentials far broader than the specific build step needs — scope them to the job, not the project. Pair artifact integrity checks (CICD-SEC-9) with existing SBOM and provenance work, rather than building a separate verification pipeline — if a build already produces an SBOM and a SLSA provenance attestation, use the same point in the pipeline to verify an artifact's origin before it ships. Check logging coverage (CICD-SEC-10) against the specific incident references in the other nine risks— if the pipeline couldn't reconstruct a PHP-git-backdoor-style direct push or a credential-theft-style secret access after the fact, that's the gap to close first.
SoftWSP's device and firmware security assessments can review a build pipeline's flow control, credential handling and artifact integrity validation against these ten risks, alongside the SBOM and provenance evidence it produces: see Device & Firmware Security.
This guide summarizes and quotes the OWASP Top 10 CI/CD Security Risks project (dual-licensed Apache-2.0 / CC BY-SA 4.0 by OWASP and its named authors); it is not a substitute for the full per-risk Definition/Description/Impact/Recommendations/References text published in the project repository.
Sources
- OWASP: Top 10 CI/CD Security Risks — official project page (introduction, authors/leaders, license, list of CICD-SEC-1 through CICD-SEC-10)
- OWASP (GitHub): www-project-top-10-ci-cd-security-risks — full per-risk Definition/Description/Impact/Recommendations/References pages, LICENSE (CC BY-SA 4.0), project.owasp.yaml (license, leaders)
- Cider Security Research: top-10-cicd-security-risks — original research repository referenced by the OWASP project
- OWASP Cheat Sheet Series: CI/CD Security Cheat Sheet (companion control checklist)
Frequently asked questions
What is the OWASP Top 10 CI/CD Security Risks project, and who maintains it?
OWASP Top 10 CI/CD Security Risks is an OWASP Lab Project documenting the ten most significant risk categories in continuous integration/continuous delivery environments — the systems (source control, build, artifact repository, deployment) that move code from a developer's workstation to production. Per the project's own introduction, it is "the result of extensive research into attack vectors associated with CI/CD, and the analysis of high profile breaches and security flaws," citing the SolarWinds build-system compromise, the Codecov secrets-exfiltration breach, a backdoored PHP release pushed directly to the project's git repository, the Dependency Confusion flaw, and compromises of the ua-parser-js, coa and rc NPM packages as its motivating incidents. The project's listed leaders are Daniel Krivelevich (co-founder/CTO, Cider Security) and Omer Gil (Director of Research, Cider Security), with Ory Segal (then Senior Director of Product Management, Palo Alto Networks) added as a project leader on the OWASP repository; the project's own metadata lists its content under a dual Apache-2.0 / CC BY-SA 4.0 license, and the GitHub project repository under the OWASP organization was created in July 2022.
What do the ten CICD-SEC risks cover?
Each risk follows a consistent Definition / Description / Impact / Recommendations / References structure. In the project's own numbering: CICD-SEC-1, Insufficient Flow Control Mechanisms — an attacker with access to one pipeline system pushing malicious code or artifacts downstream with no required review; CICD-SEC-2, Inadequate Identity and Access Management — poorly managed human and programmatic identities scattered across SCM, CI, artifact repository and deployment systems; CICD-SEC-3, Dependency Chain Abuse — flaws in how workstations and build environments fetch code dependencies, letting a malicious package get fetched and executed; CICD-SEC-4, Poisoned Pipeline Execution (PPE) — an attacker with source-control access but no build-environment access injecting malicious commands into pipeline configuration to run code during the build; CICD-SEC-5, Insufficient PBAC (Pipeline-Based Access Controls) — abusing a pipeline execution node's own permissions to move laterally once malicious code runs inside it; CICD-SEC-6, Insufficient Credential Hygiene — obtaining and reusing secrets/tokens due to weak access controls, insecure secret storage or overly broad credential scope; CICD-SEC-7, Insecure System Configuration — hardening and configuration flaws across SCM, CI and artifact-repository systems; CICD-SEC-8, Ungoverned Usage of 3rd Party Services — third-party integrations expanding the attack surface because they're trivially easy to grant access to CI/CD resources; CICD-SEC-9, Improper Artifact Integrity Validation — insufficient mechanisms to verify code or artifacts before they move further down the pipeline; and CICD-SEC-10, Insufficient Logging and Visibility — gaps that let an attacker operate inside the CI/CD environment, and complicate post-incident reconstruction of their techniques, undetected.
How is this different from the general OWASP Top 10 or a CI/CD security checklist?
The general OWASP Top 10 (see our guide to the 2025 edition) categorizes risks in deployed web applications; this project is scoped specifically to the pipeline infrastructure that builds and ships that application — source control, CI orchestration, artifact repositories, secrets and third-party integrations — a distinct attack surface the main Top 10 doesn't cover. OWASP's own companion CI/CD Security Cheat Sheet is a shorter, control-oriented checklist for hardening specific tools; this Top 10 project is the longer-form risk taxonomy each CICD-SEC entry's Recommendations section draws from, with worked incident References (the PHP git backdoor, a Homebrew auto-merge bypass, a documented GitHub Actions required-reviews bypass) attached to specific risks rather than generic tool settings.
How does this map onto firmware/device supply-chain practices like SLSA, SBOM and in-toto?
CICD-SEC-3 (Dependency Chain Abuse) and CICD-SEC-9 (Improper Artifact Integrity Validation) describe the same failure modes that SLSA's provenance levels and in-toto's attestation framework are built to close — see our guides to [SLSA](/guides/slsa-supply-chain-levels/) and [in-toto attestation](/guides/in-toto-attestation-framework/). CICD-SEC-2 (identity/access) and CICD-SEC-5 (PBAC) map onto the same CI-runner and service-account scoping concerns covered by [OpenSSF Scorecard](/guides/openssf-scorecard/)'s automated checks. For a firmware or embedded device maker, these risks apply to the build pipeline that compiles and signs firmware images and generates the accompanying SBOM — a poisoned build (CICD-SEC-4) or an unvalidated artifact (CICD-SEC-9) can corrupt the firmware and the SBOM's accuracy at the same time, which is why pipeline hardening and SBOM/provenance controls are typically addressed together rather than as separate workstreams.
In this cluster
