Poisoned Pipeline Execution

### The idea in one line Poisoned pipeline execution (PPE) is getting your CI system to run code an attacker wrote, by changing something the build reads — without ever merging that change into the branch you protect. It is one of the named risks in the OWASP catalogue of CI/CD security risks, and it is the most common way a build environment is compromised from the inside. ### Why the build is worth attacking at all A CI job is not a sandbox that turns text into a binary. It usually holds, all at once: - a token that can write to the repository or its releases, - registry or cloud credentials, increasingly a short-lived identity federated to the runner, - the authority used to sign artifacts or to issue provenance attestations, - a filesystem or dependency cache that later builds will reuse. Anything that executes inside the job inherits all of that for the length of the job. That is why somebody who cannot approve a merge is still dangerous: they do not need to change what ships, only to be present on the machine that builds what ships. ### The three variants **Direct PPE.** The attacker can edit the pipeline definition itself. On a repository where any contributor with write access can push a feature branch, and the CI system builds every branch, the definition that runs is the definition on the branch under test. Adding a step that prints the environment, curls a payload, or opens a reverse shell needs no approval, because the run happens before any review. Branch protection on the default branch is irrelevant here — nothing was merged. **Indirect PPE.** The attacker cannot change the pipeline definition, or does not need to. The definition still invokes one verb: run the build, run the quality gate. What that verb resolves to lives in the repository. A build script written in a real programming language, a task-runner file, a linter or test-framework configuration that loads plugins from the tree, a properties file that injects a task into dependency restore — every one of those is executed by the job, and every one of them reads in review as configuration rather than as code. This is the variant that survives a mature review culture, because the diff does not look like a program. **Public PPE.** The same execution, reached by somebody with no repository access at all: an outside contributor whose pull request causes a build. Which trigger events do that, and what they hand the fork's code, is a subject of its own; for the taxonomy, the point is only that the attacker position changes from insider to anonymous while the mechanism stays the same. ### Why review misses it Two asymmetries do the work. First, the diff looks harmless: a build-properties file, a task added to a runner, a plugin name in a lint config. Reviewers who would read a hundred lines of application logic carefully will wave through six lines of what they read as settings. Second, the ordering: review gates the merge, but the run that matters happened when the branch was pushed. By the time anyone reads the diff, the job has already finished with the credential. ### What a successful PPE gets the attacker Exfiltrating whatever secrets are in the job environment is the obvious one, but rarely the worst. With the job's write token the attacker can push to the repository. Executing between the compile step and the publish step lets them tamper with the artifact after it was reviewed as source — signing and provenance make that detectable to a downstream consumer, they do not prevent it from happening. Poisoning a shared cache means a later, entirely trusted build picks the payload up. On a runner that is not destroyed after each job, whatever the poisoned job left behind is waiting for the next one. ### The shape of the fix All of it follows from one principle: a job that untrusted content can reach must not hold anything worth stealing. In practice that means builds of arbitrary refs run with no secrets and a read-only token; credentials live in a separate job that only a protected ref plus an approval can reach; runners are ephemeral; and the files that the build executes are treated as code for the purposes of required review. Note the direction of these controls — they are preventive and they live in the trigger and permission model. Attestation and signature verification are detective, and they protect the consumer, not the build. ### What PPE is not It is not a compromised upstream package pulled in from outside the repository — that is dependency chain abuse, a different input with a different owner. It is not a vulnerability in a build tool. PPE is your own repository's content being the payload, and your own pipeline being the thing that runs it.