Attackers use poisoned pipeline execution by altering build or release pipeline steps so malicious code runs during CI or delivery. This can happen through compromised repositories, writable pipeline definitions, or trusted build scripts that pull attacker-controlled input. Defenders should restrict who can change pipelines, review build logic, and separate untrusted contributions from release workflows.
How poisoned pipeline execution works as an attack path
Poisoned pipeline execution is not just “malicious code in CI,” it is abuse of the trust boundary between source control, build steps, and release automation. Attackers aim to get their changes executed by legitimate pipeline machinery, which makes the activity look like normal automation unless the pipeline owner tightly controls what can run, who can edit it, and what inputs it trusts.
The practical attack surface is usually the pipeline definition itself, build scripts, or upstream content the pipeline consumes. If an attacker can modify a workflow, alter a build hook, or influence a trusted script path, they can turn the pipeline into an execution channel for payloads, credential theft, or tampering with artifacts before they are published.
That is why pipeline security has to be treated as a code integrity problem, not only an operations problem. A useful reference point is CI/CD Security Guide, which covers the controls that keep pipeline logic, runners, and branch protections aligned with the trust model the build system assumes.
Where attackers usually gain the leverage
Attackers rarely need to “break” the build server directly if they can reach the logic that the server already trusts. Compromised repositories, writable pipeline files, unsafe pull request handling, and build steps that fetch attacker-controlled input all create opportunities to inject code into an otherwise legitimate release path.
In mature environments, the most dangerous condition is not a single vulnerable step, but a chain of permissive choices: broad write access, reusable secrets in the pipeline, and build jobs that can reach production systems or signing material. When those conditions line up, a poisoned pipeline can become both an execution foothold and a secrets-exposure event. For a concrete breach pattern, see CI/CD pipeline exploitation case study.
Build trust is especially fragile when the pipeline can publish artifacts, sign releases, or access deployment credentials. The chain of impact is often bigger than the initial malicious step because the pipeline inherits authority that a normal contributor should not have. That is why CI/CD Pipeline Identity Security Guide is directly relevant to understanding how tokens, OIDC federation, and publishing permissions change the blast radius of pipeline compromise.
What a poisoned pipeline can do after execution starts
Once attacker-controlled code runs in the pipeline, the objective is usually to steal something the pipeline can reach or to alter something the pipeline can ship. That may include source code, signing keys, cloud credentials, deployment tokens, package publish rights, or build outputs that downstream systems trust.
The danger is not limited to one repository. A poisoned workflow can propagate through shared runners, cached credentials, artifact reuse, or signed artifacts that later get consumed by other systems. That is why supply-chain compromise through CI often turns into a broader environment compromise rather than a single bad build.
Incident reporting on CI abuse has repeatedly shown how malicious workflow changes can harvest secrets and create follow-on compromise paths. One useful example is reviewdog Action compromise 2025, which illustrates how a poisoned action can expose secrets that later enable wider supply-chain abuse.
Risk and Threat Considerations
Poisoned pipeline execution is dangerous because it exploits trusted automation, not just vulnerable code. The attacker is trying to turn your delivery system into a privileged execution layer, which can expose secrets, tamper with artifacts, and create a persistent foothold inside release processes.
Failure mechanism: The pipeline accepts attacker-influenced logic or input, then executes it with the privileges, network reach, and secret access that were intended for trusted build and release work.
Impact: The result can be source tampering, secret theft, malicious artifact publication, unauthorized deployment, or a chain reaction into other environments that trust the pipeline output.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, SLSA and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Poisoned pipeline execution is a supply-chain compromise path through build and release tooling. |
| Recommendation — Map pipeline abuse to supply-chain compromise and hunt for malicious build-step changes. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | CI/CD pipeline steps and build logic are software that must be hardened and reviewed. |
| Recommendation — Review pipeline code, runners, and build inputs with the same rigor as production software. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Build and release pipelines require controlled verification before untrusted changes can execute. |
| Recommendation — Verify pipeline changes before promotion and require review for build logic updates. | ||
| SLSA | Supply Chain Levels for Software Artifacts | Pipeline poisoning directly threatens build provenance and artifact integrity. |
| Recommendation — Enforce provenance and tamper resistance for builds and release artifacts. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Pipeline scripts and workflow logic are code paths whose trust assumptions must be explicit and bounded. |
| Recommendation — Design pipeline logic to separate trusted release paths from untrusted inputs. | ||
Practitioner Guidance
What to verify: Confirm that only tightly scoped identities can change pipeline definitions, runner settings, and build scripts, and that untrusted contributions cannot reach release jobs without an explicit trust boundary. If a pipeline step can read secrets or sign artifacts, treat that step as production-grade access.
Common mistake: Teams often harden the application code but leave pipeline logic, reusable actions, and build-time inputs under weaker review. That is the gap attackers exploit, because the pipeline is where code becomes authority.
Practitioner takeaway: The right control point is not just the repository, it is the path from commit to execution to release, and every step that can influence that path should be treated as a privileged change surface.