Security teams detect Poisoned Pipeline Execution by looking for unexpected changes to build logic, scripts or workflow files that run before or during CI jobs. Review source control history, pipeline definitions and runner behaviour for unapproved edits, strange network activity, new credentials use, or builds that suddenly execute attacker-controlled code.
What Poisoned Pipeline Execution usually looks like in telemetry
Detection starts by comparing the expected pipeline path with what actually ran. Security teams should treat unexpected edits to workflow definitions, build scripts, templates, or shared pipeline components as the first signal, then check whether a job began executing code that was not present in the normal review path. The highest-value question is whether the pipeline changed its own behaviour without a matching, approved change record.
Runner telemetry matters as much as source control history. A poisoned pipeline often leaves behind unusual outbound connections, new package pulls, altered environment variables, or credentials being used in a job that should not need them. In practice, the detector is looking for a mismatch between the pipeline’s declared inputs and the runtime actions it performed.
How to separate legitimate pipeline change from poisoning
Not every pipeline modification is malicious, so teams need a baseline for normal release engineering behaviour. The practical test is whether the change was authorised, reviewed, and traceable to an expected delivery event. If a workflow file changed outside the normal approval flow, or if a build suddenly starts fetching code from a new location, the burden shifts to proving it is safe rather than assuming it is routine.
Source control history, pull request reviews, and protected branch logs should tell a consistent story. If the repository shows one version of the pipeline but the runner executes a different one, or if a seemingly harmless edit introduces a new step that downloads and runs remote content, that is a strong indicator that the execution path has been poisoned rather than simply updated.
What evidence to collect and review first
Security teams should preserve the exact workflow file, commit history, runner logs, job outputs, and any artifact produced by the suspicious run. Those records help determine whether the issue was a one-off tampering event, a compromised maintainer or bot account, or a broader repository access problem. Review whether the pipeline touched secrets, published artifacts, or signed outputs during the suspicious execution.
It is also worth checking whether the compromised job altered downstream systems, because poisoned pipelines are often used to plant persistence or steal trust material. If the build had access to deploy keys, package signing material, cloud tokens, or CI credentials, the investigation should assume those assets may need to be rotated even if the original source change looks small.
Risk and Threat Considerations
Poisoned Pipeline Execution is dangerous because the pipeline is trusted to transform source into software, so a compromise at that layer can silently turn a normal release process into an attack path. The main risk is not only malicious code in the build, but also credential exposure, artifact tampering, and persistence through trusted automation.
Failure mechanism: An attacker alters pipeline logic, injected scripts, or runner behaviour so the CI system executes attacker-controlled steps while appearing to run an ordinary build or test job.
Impact: The result can include stolen secrets, modified artifacts, unsigned or misleading releases, and further compromise of deployment or source-control access paths.
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, SLSA, NIST CSF 2.0 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 software supply-chain compromise path. |
| Recommendation — Map suspicious pipeline tampering to T1195 and hunt for build-time compromise paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Pipeline abuse often depends on compromised CI accounts or tokens. |
| Recommendation — Review CI account and token access to remove unauthorized pipeline control paths. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are central to detecting poisoned pipelines. |
| Recommendation — Require verifiable build provenance for pipeline outputs and reject untrusted build paths. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight of Cybersecurity Risk | Pipeline poisoning detection depends on oversight of CI/CD risk and trusted build paths. |
| Recommendation — Track CI/CD trust boundaries as part of cybersecurity oversight and monitoring. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Workflow logic and build-script hardening support safe execution paths in software delivery. |
| Recommendation — Harden build and workflow logic so untrusted inputs cannot alter execution paths. | ||
Practitioner Guidance
What to verify: Confirm that every high-risk workflow step is tied to a reviewed commit, an approved branch or tag, and a known-good runner configuration. If a pipeline can run code from untrusted inputs, treat that as a detection gap as well as a prevention gap.
Decision rule: If a suspicious job touched secrets, publishing steps, or signing material, prioritise containment and credential review before debating whether the code change was intentional. In this threat pattern, the execution environment is often the compromise point, not just the repository content.
Practitioner takeaway: The most reliable detection signal is inconsistency between approved pipeline definition, observed runner behaviour, and the trust level of the code being executed.