Cybersecurity glossary
What is Pipeline Poisoning?
Learn what pipeline poisoning is, how attackers compromise CI/CD workflows, and how it differs from the broader category of software supply chain attacks.
Definition
Pipeline poisoning is the compromise or manipulation of CI/CD workflows, build scripts, runners, secrets, or release automation so malicious changes are built, signed, tested, or deployed through trusted delivery paths.
Why pipeline poisoning matters
CI/CD systems sit between source code and production. They fetch dependencies, run tests, build artifacts, inject secrets, sign releases, and deploy to real environments. That concentration of trust makes pipelines attractive targets.
Pipeline poisoning is narrower than a software supply chain attack overall. It specifically describes attacks that manipulate the delivery machinery so a malicious build can appear legitimate because it passed through trusted automation.
Common poisoning targets
Workflow definitions
A small YAML or script change can add exfiltration, bypass tests, or alter release logic.
Runners
Compromised shared or self-hosted runners can steal tokens and tamper with build outputs.
Secrets
Deployment keys, registry tokens, and signing credentials turn pipeline access into production impact.
Build inputs
Dependencies, caches, base images, and plugins can be swapped to change the final artifact.
How pipeline poisoning unfolds
Gain a pipeline foothold
The attacker uses a pull request, stolen token, compromised plugin, or runner access.
Modify execution
A workflow, build script, environment variable, cache, or dependency source is changed.
Access trust material
The poisoned job reaches secrets, signing authority, registry credentials, or deployment permissions.
Produce altered output
Malicious code, configuration, or metadata is added during build or packaging.
Ride trusted release paths
The artifact is tested, signed, published, or deployed by automation that consumers already trust.
Hide or persist
Logs, caches, workflow history, or runner state are manipulated to slow investigation.
Pipeline poisoning versus supply chain attack
| Concept | Primary focus | Example |
|---|---|---|
| Pipeline poisoning | CI/CD, build, signing, and deployment automation | A pull request changes a workflow to exfiltrate registry credentials |
| Dependency confusion | Package resolution and namespace trust | A public package with a higher version is installed instead of the internal one |
| Maintainer compromise | Trusted project account or release authority | An attacker publishes a malicious package using a maintainer token |
| Software supply chain attack | Any upstream path that compromises software before it reaches users | Pipeline poisoning, malicious packages, signing key theft, or update server abuse |
Pipeline poisoning checklist
- Treat workflow files and build scripts as security-sensitive code.
- Restrict secrets from untrusted pull request jobs and forked contributions.
- Use least-privilege tokens for CI jobs, registries, and deployment targets.
- Pin third-party actions, plugins, containers, and dependencies to immutable versions or digests.
- Isolate self-hosted runners and reset them between untrusted jobs.
- Require review for changes to release, signing, and deployment workflows.
- Generate signed provenance and verify trusted builder identity before deployment.
- Monitor pipeline logs, token use, and artifact digests for unexpected changes.
The practical takeaway
Pipeline Poisoning turns trusted automation against its owners. It is a specific CI/CD compromise pattern inside the larger software supply chain attack landscape.
Protect pipeline configuration like production code, keep secrets away from untrusted execution, and verify artifacts based on provenance rather than assuming every successful build is trustworthy.
Related security terms
CI/CD Pipeline
The automation path that attackers try to manipulate.
Build Pipeline
The build-focused workflow where poisoned steps can alter artifacts.
Supply-chain Levels for Software Artifacts (SLSA)
A framework for hardening build integrity against pipeline threats.
Build Provenance
Evidence that helps verify which pipeline produced an artifact.
Secret Scanning
A control that can catch leaked credentials used to poison pipelines.
Frequently asked questions
What is pipeline poisoning in simple terms?
It is an attack where someone manipulates the build or deployment pipeline so trusted automation produces or ships untrusted output.
How is pipeline poisoning different from a software supply chain attack?
Pipeline poisoning is one specific path: compromising CI/CD and release automation. Software supply chain attack is broader and also includes dependency confusion, maintainer compromise, malicious packages, and distribution abuse.
What parts of a pipeline can be poisoned?
Workflow files, build scripts, plugins, runners, base images, dependency caches, secrets, test steps, signing jobs, and deployment approvals can all be targets.
Why are pull requests risky for pipelines?
Pull requests may trigger automation using attacker-controlled code. Risk increases when untrusted code can access secrets, write tokens, caches, or privileged runners.
Can signed artifacts still be affected?
Yes. If the pipeline is poisoned before signing, the malicious artifact may be signed by trusted automation unless provenance and policy controls catch it.
What is a poisoned pipeline execution?
It is a pipeline run in which attacker-controlled changes alter build or release behavior, often without directly changing application source code.
How do teams detect pipeline poisoning?
Useful signals include unexpected workflow edits, unusual runner behavior, new outbound network paths, changed build inputs, secret access anomalies, and provenance mismatches.
References
Explore authoritative guidance and frameworks related to pipeline poisoning.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.