What breaks when build pipelines are treated as trusted identities?

When build pipelines are treated as trusted identities, attackers can use them to mint, reuse and distribute credentials faster than normal review processes can react. The result is recursive compromise: the pipeline becomes both the victim and the propagation mechanism. Governance has to cover token scope, token lifetime and revocation across the entire release path.

Why This Matters for Security Teams

Build pipelines are often granted broad automation privileges so software can move quickly, but that convenience becomes dangerous when the pipeline itself is treated as a trusted identity. Once an attacker reaches the CI/CD layer, they can mint tokens, pull secrets, sign artifacts, and fan out access into downstream systems faster than manual review can react. This is not just credential theft. It is identity propagation through the release process.

NHI Management Group research shows how frequently this risk is amplified by poor secret hygiene: 96% of organisations store secrets outside of secrets managers in vulnerable locations, including code and CI/CD tools, and only 20% have formal offboarding and revocation processes for API keys. That pattern matches real-world incidents such as the CI/CD pipeline exploitation case study, where the pipeline’s own trust was used as an attack path. The broader secret-sprawl problem is detailed in the Guide to the Secret Sprawl Challenge. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity and access controls must be continuously managed, not assumed from the system’s role. In practice, many security teams discover pipeline trust abuse only after secrets have already been distributed into multiple environments.

How It Works in Practice

The practical failure is usually a mismatch between static trust assumptions and dynamic execution. A pipeline service account or OIDC-backed workload identity may be legitimate, but legitimacy is not the same as unlimited trust. If the pipeline can request credentials, invoke deployment APIs, or access signing services without tight policy checks, an attacker who compromises any build step can inherit that authority.

Safer designs treat the pipeline as a workload identity with bounded, time-limited authority rather than as a standing trusted principal. That means tying access to the specific build, repository, branch, artifact, or environment state that triggered the action. It also means favoring just-in-time secrets with short TTLs, narrow scopes, and automated revocation at job completion. Where possible, use external workload identity and attestation rather than long-lived static credentials. The operational goal is to make the pipeline prove what it is doing at request time, not simply who it claims to be.

• Issue ephemeral credentials per job, not shared across runners or projects.
• Bind release permissions to context such as commit provenance, environment, and approval state.
• Store secrets in managed systems and revoke them automatically after each task.
• Separate build, test, signing, and deploy identities so compromise does not cascade.

The Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign both illustrate how quickly a trusted automation path can become a credential-exfiltration channel once a single dependency or workflow step is compromised. These controls tend to break down when pipelines reuse static secrets across many repositories because revocation and blast-radius containment become operationally too slow.

Common Variations and Edge Cases

Tighter pipeline identity controls often increase release overhead, requiring organisations to balance delivery speed against blast-radius reduction. That tradeoff is real, especially in monorepos, multi-stage release trains, and legacy CI systems that were never designed for per-job identity.

Current guidance suggests three common edge cases deserve special handling. First, self-hosted runners can retain state between jobs, so ephemeral identity is weakened if filesystem residue or cached tokens survive the build. Second, signed artifacts and release automation create privileged downstream paths, so a compromised build identity may not need direct production access to cause damage. Third, third-party actions and plugins can silently expand trust boundaries, turning a pipeline into an identity broker for tools that were never reviewed as part of the release chain.

Where industry consensus is still evolving, the safest position is to treat pipeline trust as conditional and continuously evaluated rather than binary. That approach aligns with the broader NHI governance lessons documented in NHI Management Group research, especially where token exposure in developer tooling and malicious plugin ecosystems show how automation layers can become credential distribution points. Best practice is evolving, but the operational principle is stable: if a pipeline can mint or move credentials, it must be governed like a high-value identity, not just infrastructure.

Related resources from NHI Mgmt Group

• What breaks when vector stores are writable by compromised identities?
• What breaks when CI/CD workflow actions or build credentials are tampered with?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?