A CI/CD pipeline attack usually follows a short path: get a foothold in source or build, run code with the pipeline's privileges, steal its credentials, then change what gets shipped. Each step maps to a documented weakness, and each has a specific control that breaks the chain.
Why is the pipeline a target?
OWASP's Top 10 CI/CD Security Risks project says CI/CD systems deliver code from an engineer's workstation to production, and that attackers have realized these services provide an efficient path to an organization's most valuable assets. The pipeline holds secrets, deploy rights and the authority to publish trusted artifacts, all in one place, and it is often less monitored than production.
The SLSA project's catalog of supply chain threats shows how this has played out. It lists the SolarWinds attack, where an attacker compromised the build platform and injected malicious behavior during each build, and the CodeCov case, where leaked credentials were used to upload a malicious artifact to a storage bucket users downloaded from. The SLSA page frames both as integrity failures: the artifact did not match the intended source and build.
What are the stages?
The OWASP list names ten risks. Here is how several line up as an attack sequence.
Entry. The attacker needs to get code or configuration into the pipeline. Weak identity and access management (CICD-SEC-2), or a missing review rule (CICD-SEC-1, insufficient flow control mechanisms) lets a single compromised account push changes straight toward production. A dependency chain abuse (CICD-SEC-3) is the quieter route: a malicious or confusable package enters the build as a normal dependency.
Execution. Poisoned pipeline execution (CICD-SEC-4) means the attacker influences what the pipeline runs, for example by changing the pipeline definition or a script it calls, through a change that bypasses review. The code then runs with the pipeline's permissions.
Privilege and secrets. If the pipeline's identity can reach more than it needs (CICD-SEC-5, insufficient pipeline-based access controls) or secrets sit in plain variables and logs (CICD-SEC-6, insufficient credential hygiene), the foothold turns into access to cloud accounts and registries.
Spread through tools. Insecure system configuration (CICD-SEC-7) and ungoverned usage of third-party services (CICD-SEC-8) give more places to hide. A plugin or hosted integration with broad access is an extension of your pipeline.
Tampering. Improper artifact integrity validation (CICD-SEC-9) is what allows a changed artifact to be deployed as if it were the real one.
Cover. Insufficient logging and visibility (CICD-SEC-10) means nobody sees any of it.
What breaks the chain?
No single control does. The SLSA project describes two integrity goals: source integrity, where every change reflects the producer's intent and approval by two authorized representatives approximates intent, and build integrity, where the package is built from the correct, unmodified sources and dependencies. Provenance, a signed record of how an artifact was built, lets consumers detect an artifact that did not come from the expected build.
In practice that means required reviews on pipeline files, short-lived credentials scoped per job, pinned dependencies, isolated and ephemeral build runners, provenance and signature checks before deploy, and logs shipped somewhere the pipeline cannot edit.
A constructed example
A contractor's account on a code host is phished. The attacker opens a pull request that changes a test script, and the repository has no required review for files under the scripts directory. The pipeline runs the script on a shared runner, which prints the deploy token into a build log kept for 90 days. The attacker reads the log, uses the token to push an image tagged as the latest release, and the next deployment pulls it. Each step maps to an OWASP risk, and fixing any one would have stopped the chain: required review, a job-scoped token that cannot push to production, masked secrets, or deploying only images with verified provenance.
How to check or apply this
- Require reviews for changes to pipeline definitions and build scripts, and protect the main branch.
- Give each job its own short-lived credentials with the least access it needs.
- Pin dependencies and actions to exact versions or digests, and scan them on every build.
- Run builds on isolated, ephemeral runners, and do not share them between trust levels.
- Generate provenance for each artifact, and verify it before deploy.
- Keep pipeline logs in a separate store, and alert on changes to pipeline configuration.
- Review third-party integrations as you would a vendor with production access.
Safeguard's policies and gates can enforce checks such as dependency rules on pull requests and builds, and its dependency scanning covers the third-party packages a pipeline pulls in.
Quick check
Is a CI/CD attack the same as a supply chain attack?
They overlap. A pipeline compromise is one way to attack the supply chain, since the pipeline produces what customers receive. Supply chain attacks also include compromised dependencies and registries.
What is the single most useful control?
There is no single one, but short-lived, narrowly scoped credentials limit what a foothold can do. Pair them with review requirements and artifact verification.
Sources
Last reviewed: 18 October 2026.
