What do organisations get wrong about machine secrets in CI/CD pipelines?

The most common mistake is treating secrets as deployment convenience rather than identity risk. When keys, tokens, and service accounts are embedded in pipelines, ownership becomes blurred and revocation becomes slower than development. That creates hidden trust paths that are hard to audit and easy to reuse across systems.

Why This Matters for Security Teams

Machine secrets in CI/CD are not just a hygiene problem. They become standing identity in places built for speed, not durable trust. When a pipeline can pull production tokens, sign artifacts, or deploy infrastructure with broad permissions, a single leaked secret can turn build automation into an attacker-controlled execution path. Guidance from the OWASP Non-Human Identity Top 10 frames this as an identity exposure issue, not a storage issue, because the secret itself is what grants authority.

NHIMG research consistently shows how quickly this becomes operationally real. The Guide to the Secret Sprawl Challenge illustrates that secrets are often duplicated across repos, runners, logs, and chat tools, which makes revocation and ownership unclear. In practice, many security teams discover the blast radius only after a pipeline compromise, not through intentional secret governance.

How It Works in Practice

A better model starts by treating each machine secret as an identity bound to a specific workload, environment, and time window. That means reducing long-lived static credentials, issuing short-lived credentials where possible, and making every pipeline stage prove what it is before it receives access. The core question is not “where is the secret stored?” but “what is this automation allowed to do right now?”

Operationally, that usually means combining several controls:

• Replace shared secrets with workload identity where possible, using cryptographic proof instead of copied credentials.
• Issue just-in-time credentials with tight TTLs so access expires automatically after the task completes.
• Scope permissions to the narrowest build, test, or deploy function rather than reusing broad service accounts.
• Evaluate access at request time, not only at provisioning time, so policy reflects current context.
• Log secret issuance, use, and revocation as identity events, not just configuration changes.

That approach aligns with CISA Zero Trust guidance and the operational emphasis in CI/CD pipeline exploitation case study, where attacker movement often depends on inherited build credentials. It also fits the Ultimate Guide to NHIs — Static vs Dynamic Secrets, which stresses that dynamic secrets reduce reuse risk only when revocation is actually automated.

These controls tend to break down when legacy runners, long-lived deploy keys, or third-party build steps require shared credentials that cannot be cleanly scoped or revoked.

Common Variations and Edge Cases

Tighter secret control often increases pipeline friction, so organisations have to balance speed against containment. That tradeoff is real in release engineering, where teams may accept slightly more setup work to eliminate broad credential reuse.

Not every pipeline can move to fully ephemeral identity at once. Some environments still depend on self-hosted runners, air-gapped build networks, or vendor integrations that only support static tokens. Current guidance suggests prioritising the highest-value paths first: production deploys, signing keys, registry publish credentials, and any secret that can open lateral movement into cloud control planes. For lower-risk jobs, the same discipline still applies, but with narrower scope and faster rotation.

One common mistake is assuming detection solves the problem. NHIMG cites research from The State of Secrets Sprawl 2026 showing that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means discovery without revocation leaves risk intact. Another edge case is pipeline secrets embedded in build logs, issue trackers, or chat tools, where the leak is outside source control entirely. Best practice is evolving toward treating every machine secret as an operationally managed identity with ownership, TTL, and revocation tied to the workflow that uses it.

Related resources from NHI Mgmt Group

• What do organisations get wrong about CI/CD token governance?
• What do teams get wrong about software visibility in CI/CD pipelines?
• What do security teams get wrong about workload identity in cloud and CI/CD environments?
• What do organisations get wrong about secrets management for non-human identities?