Why do short-lived tokens still create major risk in CI/CD environments

Why This Matters for Security Teams

Short-lived tokens are often treated as a clean fix for CI/CD risk, but the real exposure is happening inside the execution window. Build agents, runners, and automation jobs can mint additional credentials, call cloud metadata services, or reuse a token to reach publishing and deployment systems long before the TTL expires. NIST Cybersecurity Framework 2.0 makes clear that identity, access, and continuous monitoring have to work together, not as separate assumptions.

This is why token lifetime alone is a weak control signal. If a workflow can reach artifact registries, signing services, or developer tooling, an attacker who steals that session token can still move laterally with legitimate permissions. NHIMG research on the CI/CD pipeline exploitation case study shows how runner compromise turns one credential into broad operational access, and the Guide to the Secret Sprawl Challenge shows how quickly secrets spread once they are available to automation. In practice, many security teams discover the blast radius only after a pipeline has already published malicious artifacts or exfiltrated cloud access.

How It Works in Practice

The practical problem is not whether a token expires in five minutes or five hours. It is whether the token is bound to narrow, runtime-specific authority. A CI/CD job may legitimately need to pull source, fetch a package, sign an artifact, and push to a registry. If all of those actions ride on one broad token, the session becomes a high-value target even when it is short-lived.

Better practice is to separate authentication from authorization and constrain both at runtime. That usually means ephemeral workload identity, request-scoped tokens, and policy checks that evaluate the actual action, target system, and environment before access is granted. In modern pipelines, that can include OIDC-based workload federation, JIT issuance for deployment steps, and policy-as-code gates that deny access to cloud metadata, production registries, or secret stores unless the job context explicitly allows it. This is consistent with current guidance from the NIST Cybersecurity Framework 2.0, which emphasizes governance, protective controls, and continuous verification.

• Bind tokens to a single job, environment, or artifact path where possible.
• Use short TTLs, but also reduce scope to the minimum runtime action.
• Deny access to metadata services and secret stores unless required for that step.
• Rotate or revoke immediately on job completion, failure, or anomaly.
• Prefer workload identity over shared static credentials in runners and orchestration systems.

NHIMG’s research on the Guide to the Secret Sprawl Challenge and external guidance such as the NIST Zero Trust Architecture publication both point to the same operational lesson: trust should be evaluated per request, not granted for the whole pipeline session. These controls tend to break down when self-hosted runners, shared build nodes, or legacy deployment scripts require broad ambient permissions because the job context is too weak to enforce fine-grained policy.

Common Variations and Edge Cases

Tighter token scoping often increases pipeline complexity, requiring organisations to balance developer velocity against control precision. That tradeoff is real, especially in monorepos, cross-account deployments, and release automation that spans many tools. There is no universal standard for this yet, so current guidance suggests combining short-lived tokens with contextual authorization rather than assuming duration alone solves the problem.

Some environments need exceptions. Break-glass release jobs may require broader access for a narrow maintenance window, and air-gapped or highly controlled build systems may rely on different trust anchors than cloud-native runners. In those cases, the key question is whether the token can be reused outside the intended step or chained into other privileges. That is why incident patterns such as the Salesloft OAuth token breach matter: once an execution token can unlock connected systems, short lifespan becomes less relevant than the permissions attached to it.

Security teams should treat short-lived tokens as a hygiene control, not a containment strategy. The better test is whether the token can only do one specific thing, in one specific context, for one specific moment. If the answer is no, the pipeline still has major risk even when every credential expires quickly.

Related resources from NHI Mgmt Group

• Why do short-lived tokens still create security risk?
• Why do short-lived OIDC tokens still create meaningful supply chain risk?
• When does a short-lived API key still create material risk?
• Why do static credentials create more risk than short-lived access tokens?