The trust boundary breaks. Once untrusted code runs with repository secrets or a write-capable token, attackers can steal credentials, alter branches, poison packages, or persist through workflow changes. At that point, the pipeline becomes a supply chain entry point rather than a control point.
Why This Matters for Security Teams
CI/CD systems are designed to automate trust, but that trust becomes dangerous when untrusted code can run with privileged tokens or repository secrets. At that point, a build job is no longer just a delivery mechanism. It becomes an execution environment that can exfiltrate credentials, rewrite history, tamper with artifacts, and establish persistence through future workflow changes. The control failure is not theoretical: NHI Management Group has highlighted real-world pipeline abuse patterns in its CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge.
Security teams often assume that branch protection, signed commits, or code review are enough to contain risk, but those safeguards do not help once the runner itself is trusted to reach deployment targets, package registries, or cloud APIs. OWASP’s OWASP Non-Human Identity Top 10 is explicit that machine credentials are high-value assets that need lifecycle controls, not just perimeter controls. In practice, many security teams encounter pipeline abuse only after a secret has already been copied out of a runner and reused elsewhere.
How It Works in Practice
The practical failure mode is usually a mismatch between code provenance and token privilege. A workflow may accept untrusted pull request code, then execute it in the same job context that can read secrets, push to protected branches, publish packages, or assume a cloud role. Once that happens, the runner becomes a short-lived but highly privileged identity. The right response is to reduce standing privilege and bind access to the specific task, not to the repository alone.
Current guidance suggests three controls working together:
- Use workload identity for runners so the job proves what it is, rather than inheriting broad ambient access.
- Issue just-in-time, short-lived credentials per job or per step, and revoke them automatically when the task ends.
- Separate untrusted build steps from privileged release steps so code review and deployment authority are not collapsed into one execution context.
For identity-backed workload authentication, teams increasingly rely on standards such as SPIFFE and policy engines that evaluate access at request time instead of pre-approving a whole pipeline. That aligns with the State of Secrets Sprawl 2026, which found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. The lesson is straightforward: the runner is the asset, and its credentials should be treated as ephemeral secrets, not durable entitlements.
These controls tend to break down when monolithic workflows mix forked-code execution, artifact signing, package publishing, and cloud deployment in one job because the privilege boundary becomes impossible to enforce cleanly.
Common Variations and Edge Cases
Tighter pipeline isolation often increases build complexity and developer friction, requiring organisations to balance delivery speed against blast-radius reduction. That tradeoff is real, especially where release engineering depends on shared runners, legacy scripts, or third-party actions that were never designed for zero standing privilege.
There is no universal standard for this yet, but current guidance suggests treating the following cases with extra caution:
- Fork-based pull request builds, where untrusted code is expected and secret exposure must be prevented by default.
- Reusable workflows and shared actions, where a single compromise can cascade across many repositories.
- Long-lived tokens in self-hosted runners, which often outlive the job and survive cleanup gaps.
- Artifact signing and publishing steps, where write access to package registries is equivalent to supply chain control.
Edge cases also arise when teams rely on branch-based RBAC alone. RBAC can help with human access, but it does not describe the runtime intent of code executing inside a job. That is why the better pattern is context-aware authorisation at the moment of use, coupled with revocation on completion. NHI Management Group’s coverage of the Reviewdog GitHub Action supply chain attack shows how quickly a trusted automation path can become an exposure path once workflow trust is assumed rather than continuously verified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Untrusted workflow code with privileged tokens is a runtime trust failure. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Pipeline tokens need short-lived lifecycle controls and revocation. |
| NIST AI RMF | Runtime policy and accountability are central to autonomous pipeline trust. |
Replace standing CI/CD secrets with ephemeral credentials and automated revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
