Because CI/CD increasingly depends on machine identities to create, sign, and publish evidence. When those identities are over-scoped, reusable, or poorly separated from the work they certify, a compromise can turn trusted infrastructure into a release path for malicious content. Identity governance has to cover evidence authority, not just access rights.
Why supply-chain incidents surface CI/CD identity governance failures
CI/CD is not just a build system, it is a trust pipeline. The incident pattern changes when the pipeline itself can mint, reuse, or publish evidence on behalf of the organisation. When machine identities are over-privileged, shared across steps, or left in place after their job ends, a compromise can turn a trusted release path into an attacker-controlled delivery mechanism.
The governance gap is usually not “missing access” but “unclear authority.” Teams often know which system can push code, yet cannot explain which identity is allowed to sign, publish, attest, or promote artifacts under which conditions. That is why supply-chain incidents often reveal weak separation between execution rights and evidence authority.
A useful way to think about this is that CI/CD identities carry different kinds of power at different stages. One identity may fetch dependencies, another may sign builds, and another may publish to a registry or release channel. If those roles are collapsed, evidence becomes easy to forge, and a compromise in one stage can inherit trust in the next. The same problem appears when credentials are long-lived, broadly scoped, or shared across repositories and environments.
Where the governance gap actually sits
The gap sits in the boundary between operational access and trust issuance. Pipeline credentials are often treated as technical plumbing, but they also determine who can create trustworthy evidence, who can move artifacts forward, and who can make a build look legitimate. Good governance therefore has to define ownership, lifecycle, and separation of duties for machine identities in the same way it does for human-admin privileges.
That means the key questions are: which identity is allowed to sign, which identity is allowed to publish, which identity is allowed to approve promotion, and whether any one compromise can satisfy all of those conditions. When the answer is “yes,” supply-chain exposure is no longer just a build-security issue, it is an identity-governance failure with release-channel consequences.
In practice, the most fragile patterns are reused tokens, environment-spanning credentials, and “do-everything” automation accounts. These shortcuts are convenient, but they blur the audit trail and make it impossible to tell whether the identity that created the evidence is the same one that is now moving code into production. The stronger model is short-lived, narrowly scoped, and environment-bound identity per workflow stage.
How evidence authority becomes the attack path
Attackers do not need to own the whole pipeline if they can compromise the identity that confers trust. Once they obtain a signing key, publishing token, or privileged automation credential, they can use legitimate infrastructure to distribute malicious output while preserving the appearance of a normal release. This is why supply-chain attacks are so effective: they exploit the trust organisations already extend to their own delivery systems.
When evidence authority is weakly governed, the attacker’s job gets easier at each step. A compromised build identity can poison artifacts, a reused secret can extend access into another environment, and a poorly separated publishing identity can turn a single foothold into a trusted release. The result is not just unauthorized access, but unauthorized legitimacy.
That risk is amplified when identity records do not clearly map to owners, purposes, and expiration conditions. If no one is responsible for rotating, retiring, or recertifying the identity used in CI/CD, then the control breaks silently. The system may still “work,” but it works in a way that can no longer distinguish normal automation from malicious use.
Risk and Threat Considerations
Supply-chain compromise is especially damaging in CI/CD because the attacker is not only stealing access, but also exploiting the organisation’s trust in its own release machinery. A compromised machine identity can sign, publish, or promote malicious output while appearing legitimate, which makes detection harder and downstream impact broader.
Failure mechanism: Over-scoped or reused pipeline identities collapse build, sign, and publish authority into one credential path, so a single compromise can impersonate trusted release activity and bypass normal review points.
Impact: Malicious artifacts can be distributed through trusted channels, secrets can be exposed across environments, and incident response becomes slower because the release evidence itself may be untrustworthy.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, SLSA and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | CI/CD machine identities often fail through excessive scope and shared authority. |
| NHI-07 — Long-Lived Secrets | Reusable CI/CD credentials and signing tokens increase compromise persistence. | |
| NHI-01 — Improper Offboarding | Unrevoked automation identities keep release paths open after their job ends. | |
| Recommendation — Limit pipeline identities to the minimum release permissions each step needs. Replace durable pipeline secrets with short-lived, scoped credentials. Revoke CI/CD identities and tokens when workflows, projects, or owners change. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI/CD secrets, tokens, and signing material need lifecycle control and rotation. |
| AC-6 — Least Privilege | Pipeline identities should not hold combined build, sign, and publish power. | |
| AU-9 — Protection of Audit Information | Release evidence must remain trustworthy if CI/CD identities are compromised. | |
| Recommendation — Rotate and retire pipeline authenticators on a defined lifecycle schedule. Restrict each CI/CD identity to the smallest feasible release scope. Protect build logs, attestations, and release records from alteration. | ||
| SLSA | Supply-chain Levels for Software Artifacts | The subject is about build provenance and trustworthy release paths. |
| Recommendation — Require provenance and signing controls that separate build from publish authority. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The question concerns architecture choices that preserve trust boundaries in delivery systems. |
| Recommendation — Design pipeline architecture so privilege cannot flow unchecked between stages. | ||
Practitioner Guidance
What to prioritise: Treat the identities that create evidence as production-grade assets, not implementation details. The first control objective is to separate build, sign, attest, and publish authority so that compromise of one step does not confer release power across the chain.
What to verify: Confirm that every CI/CD identity has an owner, a purpose, an expiration or review cycle, and a clearly bounded scope. If a credential can cross repositories, environments, or release stages without a documented reason, it is already too broad.
Common mistake: Teams often secure the code path but ignore the trust path. A pipeline that is technically locked down can still be governance-poor if the same automation identity can create, certify, and ship the artifact it just built.
Practitioner takeaway: In CI/CD, identity governance succeeds only when trust authority is fragmented enough that no single machine identity can both compromise and legitimize a release.