A supply chain attack in which an adversary injects malicious commands directly into pipeline definition files so the next build runs attacker-controlled code. The compromise works because the CI system trusts workflow configuration as execution authority, turning repository change control into runtime access control.
Expanded Definition
Direct Poisoned Pipeline Execution describes a CI/CD compromise where an attacker edits pipeline definition files so the platform treats malicious steps as legitimate workflow instructions. In practice, the attack turns repository write access into build-time execution authority, which is why it sits at the intersection of software supply chain security, NHI governance, and agentic execution control. The risk is not limited to code that ships to production; it also includes build runners, deployment jobs, signing steps, and any automated task that inherits secrets or cloud access.
Industry usage is still evolving, but the core distinction is clear: this is not generic malware in a build environment, and it is not merely a bad commit. The poisoned pipeline itself becomes the attack vector, especially when approvals, protected branches, or code review do not adequately separate configuration change from privileged execution. NIST’s Cybersecurity Framework 2.0 is useful here because it frames this as a governance and control problem, not just a tooling problem. The most common misapplication is treating pipeline files as ordinary source code, which occurs when organisations fail to enforce separate review and execution controls for workflow definitions.
Examples and Use Cases
Implementing pipeline security rigorously often introduces friction, requiring teams to weigh deployment speed against tighter review, branch protection, and runner isolation.
- A malicious pull request alters a GitHub Actions workflow to exfiltrate secrets during the next build, similar to patterns documented in the Reviewdog GitHub Action supply chain attack.
- An attacker changes a deployment job so the runner executes a hidden shell step before artifact publishing, matching the broader failure mode described in the CI/CD pipeline exploitation case study.
- A dependency update or automation file rewrite inserts commands that export cloud tokens, echoing the secret theft patterns covered in the Guide to the Secret Sprawl Challenge.
- A release workflow is modified to sign attacker-controlled binaries, then the compromised artifact is promoted through the normal release channel.
- A self-hosted runner executes poisoned workflow logic because repository trust was extended to runtime without separate controls on secrets and execution privileges.
These scenarios align with NIST’s guidance on protecting systems and maintaining secure change control, and they show why pipeline files must be treated as privileged infrastructure rather than routine project metadata.
Why It Matters in NHI Security
Direct Poisoned Pipeline Execution matters because CI/CD systems frequently hold the very credentials attackers want: service account tokens, API keys, signing certificates, and cloud permissions. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes poisoned workflows especially dangerous. The attack is amplified when pipeline identities have excessive privilege or when secrets are available to every job by default. The same operational weakness appears in other supply chain compromises documented by NHI Management Group, including the Shai Hulud npm malware campaign, where automation and secret exposure created broad downstream impact.
For NHI defenders, the lesson is that workflow files can function as an identity boundary. If a pipeline can mint, retrieve, or forward secrets, then controlling the pipeline definition is equivalent to controlling an execution identity. That is why least privilege, secret segmentation, runner hardening, and immutable approvals all matter together, not separately. Organisations typically encounter the real cost only after secrets are abused or unsigned changes are traced back to a build, at which point direct poisoned pipeline execution becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling failures that enable poisoned pipelines to steal credentials. |
| OWASP Agentic AI Top 10 | A-03 | Workflow abuse mirrors agentic execution paths where untrusted instructions gain tool access. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access and controlled system authorisation for automated execution. |
| NIST Zero Trust (SP 800-207) | SA-5 | Zero Trust requires continuous verification before workflow code can execute with privilege. |
| NIST AI RMF | Supports risk-based governance for automated systems that can be manipulated through poisoned instructions. |
Limit pipeline identities, review entitlements regularly, and isolate build permissions from source control roles.
Related resources from NHI Mgmt Group
- Who is accountable when a poisoned build pipeline or exposed edge device causes compromise?
- How do I implement secrets scanning in a CI/CD pipeline?
- What is the difference between direct access and effective access in Active Directory?
- What is the difference between IAM roles and direct API keys for AI workloads?
