CI/CD tokens and build identities matter because they turn infrastructure trust into distribution trust. If an attacker steals those credentials, they can produce signed or otherwise trusted artifacts from compromised runners, which makes the malicious output look legitimate even when the source repository has not obviously changed.
Why CI/CD tokens changed the supply chain attack surface
CI/CD systems sit at the point where source code, build automation, signing, publishing, and deployment converge. That makes their credentials far more valuable than ordinary repository access. A stolen build token can let an attacker influence what gets produced, not just what gets committed, which is why the attack now often lands in the build and release pipeline rather than only in the source tree.
When that trust boundary is crossed, defenders can miss the compromise because the repository may look normal while the pipeline quietly emits trusted artifacts. That is the core shift: supply chain compromise is no longer only about changing code, but about hijacking the machinery that transforms code into something downstream systems accept.
Build identities also tend to have reach beyond a single repo. They may access artifact stores, package registries, signing services, cloud secrets, or deployment targets. If an attacker captures one of those identities, they can often move from a narrow build foothold to broader release tampering, secret theft, or persistence across multiple projects.
What attackers gain from compromised build trust
The practical value of a compromised CI/CD token is that it can produce output that inherits legitimacy from the build process itself. Signed artifacts, trusted publishing flows, and automated release jobs all assume the runner and its credentials are acting on behalf of the organisation. If those credentials are stolen, the malicious artifact can look operationally correct even when its content is not.
This is why build compromise is so effective for dependency attacks, package poisoning, and malicious update campaigns. The attacker does not need to win every control in the environment. They only need enough access to make the pipeline generate a release, tag, or package that downstream consumers trust. SLSA is relevant here because its core concern is provenance and integrity of build outputs.
The trust problem is amplified when pipelines reuse long-lived secrets, pass credentials between jobs, or allow untrusted code to reach privileged stages. In that model, one compromised token can expose other secrets, alter release behavior, or turn a transient workflow into a repeatable supply chain compromise. NHIMG’s CI/CD Pipeline Identity Security Guide is useful because it ties token permissions, OIDC federation, pinned actions, and trusted publishing to the actual build trust boundary.
How to think about CI/CD tokens as a security control, not just an implementation detail
CI/CD tokens should be treated as production-grade credentials with explicit scope, short lifetime, and limited audience. The main design question is not whether a pipeline can authenticate, but what a stolen token can do if the runner, job, or third-party action is compromised. That is the difference between automation convenience and supply chain exposure.
In practice, the highest-risk tokens are the ones that can publish, sign, deploy, or read secrets across environments. The next tier is any credential that can trigger workflows, modify release metadata, or interact with trusted third-party actions. NHIMG’s Guide to the Secret Sprawl Challenge helps frame why hardcoded or long-lived CI/CD secrets turn routine automation into a durable compromise path.
Build identity design should also separate untrusted jobs from trusted release stages. If a pull request, external contribution, or third-party package can reach the same credentials used for publishing, the pipeline has already merged development and production trust. The right response is to reduce the privileges of each stage, require explicit approval for signing or publication, and make token theft less useful even when the build environment is touched.
Risk and Threat Considerations
CI/CD compromise is attractive because it scales. One stolen runner secret or publishing token can affect many repositories, many releases, or many downstream users, and the resulting artifact often carries the same trust signals as a legitimate build. That makes the blast radius much larger than a single source-code edit.
Failure mechanism: Attackers steal or abuse build credentials, then use the pipeline to publish, sign, or deploy malicious output that appears legitimate to consumers and internal controls.
Impact: Downstream systems may ingest tainted artifacts, secrets may be exfiltrated from build jobs, and the compromise can persist through normal release cycles until tokens are rotated and provenance is re-established.
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 API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD tokens are identity-bearing secrets that can be stolen and reused to mint trusted builds. |
| NHI-05 — Overprivileged NHI | Build identities often have release and secret access beyond the minimum needed. | |
| NHI-07 — Long-Lived Secrets | Long-lived CI/CD tokens create durable compromise paths in release automation. | |
| Recommendation — Reduce token exposure and rotate any CI/CD secret that can publish or sign artifacts. Constrain pipeline identities to the minimum permissions needed for each build stage. Replace persistent build tokens with short-lived credentials and automated rotation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen pipeline tokens enable unauthorized access to build and publish workflows. |
| Recommendation — Harden authentication to publishing and workflow endpoints with short-lived, bound credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI/CD tokens and signing secrets require lifecycle control, rotation, and revocation. |
| IA-9 — Service Identification and Authentication | Pipeline runners and automation identities authenticate as services, not humans. | |
| Recommendation — Manage build token issuance, rotation, and revocation as production credential lifecycle. Authenticate build services with scoped machine identities instead of shared secrets. | ||
| SLSA | Supply-chain Levels for Software Artifacts | The question is about build trust, artifact provenance, and compromise of release pipelines. |
| Recommendation — Adopt stronger provenance controls so artifacts can be traced to trusted build inputs. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI/CD tokens are accounts and secrets that need inventory, least privilege, and rotation. |
| Recommendation — Inventory pipeline accounts and remove any release credential that is not actively required. | ||
Practitioner Guidance
What to prioritise: Put the strongest controls around anything that can publish, sign, or deploy. If a credential can move an artifact from build to release, treat it as materially more sensitive than routine automation access.
What to verify: Confirm that build jobs use narrowly scoped, short-lived credentials and that untrusted code cannot reach trusted publishing steps. Verify that artifact provenance, token audience, and runner isolation are enforced rather than assumed.
What practitioners underestimate: The most dangerous failure is not always code injection, it is trust reuse. Once build identity is allowed to inherit broad release authority, compromise of the pipeline becomes compromise of the supply chain.
Practitioner takeaway: The goal is to make stolen build credentials insufficient to produce a trusted release, because supply chain defense now depends on separating build execution from release authority.
Related resources from NHI Mgmt Group
- Why do CI/CD tokens and maintainer credentials matter so much in supply chain security?
- Why do standing CI/CD tokens create so much risk in supply chain attacks?
- How do attackers turn a supply-chain incident into wider NHI compromise?
- How should security teams reduce the impact of CI/CD supply chain compromise?