Why do short-lived OIDC tokens still create meaningful supply chain risk?

Why This Matters for Security Teams

Short-lived OIDC tokens are often treated as low risk because their expiry window is brief, but supply chain attackers do not need long dwell time when the token is present in a runner, build step, or orchestration cache. The real issue is that modern pipelines are densely connected: one exposed token can unlock package registries, cloud APIs, signing workflows, or downstream deployment systems before expiration ever becomes relevant.

This is why NHI governance focuses on runtime containment, not just token lifetime. A brief credential can still be catastrophic if it is minted for the wrong workload, copied into logs, or harvested from process memory. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread beyond their intended boundary once they enter development workflows. The same pattern appears in incidents like the Reviewdog GitHub Action supply chain attack, where the exposure point mattered more than the nominal secret duration.

In practice, many security teams encounter token abuse only after a runner compromise has already turned a short-lived credential into a live supply chain bridge.

How It Works in Practice

OIDC tokens reduce standing credential exposure, but they do not remove the attack surface created at issuance, transport, and execution time. An attacker who gains access to a CI runner, ephemeral container, or developer workstation can still capture the token from environment variables, memory, temp files, debug output, or injected workflow state. If the token is valid for a few minutes, that is still enough time for automated abuse.

Best practice is evolving toward tighter workload identity and runtime policy rather than relying on expiry alone. The OIDC token should represent the workload, not just the pipeline, and downstream systems should verify audience, issuer, subject claims, and context before granting access. NIST’s Cybersecurity Framework 2.0 reinforces that identity, access control, and continuous monitoring have to work together, while the OWASP Non-Human Identity Top 10 highlights how secrets and tokens become a supply chain issue when they are over-privileged or poorly contained.

• Issue tokens only to the exact workload that needs them, with narrow audience and scope.
• Use short TTLs, but pair them with automatic revocation and session invalidation.
• Prevent token rendering in logs, artifacts, crash dumps, and chatty debug output.
• Bind access to runner attestation or trusted workload identity where possible.
• Continuously monitor for token replay from unusual geographies, jobs, or pipeline states.

NHIMG’s Salesloft OAuth token breach illustrates the practical problem: once an attacker has a valid token, the target system often sees only legitimate-looking API activity. These controls tend to break down in highly parallel CI/CD environments because concurrent jobs, shared runners, and noisy observability tooling make containment and attribution difficult.

Common Variations and Edge Cases

Tighter token controls often increase pipeline complexity, requiring organisations to balance security gains against build reliability, developer friction, and operational latency. That tradeoff matters because some environments cannot use the same containment model everywhere.

For example, self-hosted runners may allow stronger isolation than shared SaaS runners, but they also concentrate risk if the host is reused across jobs or left overly permissive. Multi-tenant build systems need more aggressive segmentation than single-purpose internal runners. There is also no universal standard yet for how much context a relying party should demand before accepting an OIDC token, so current guidance suggests starting with minimum viable claims and adding runtime checks where the blast radius is highest.

Another edge case is secret fan-out: a short-lived token can be exchanged for longer-lived access, so the token itself is only the first problem. That is why supply chain defenders should look at downstream privilege, not just issuance policy. NHIMG’s State of Secrets Sprawl 2026 shows how quickly valid credentials remain exploitable once exposed, and the 52 NHI Breaches Analysis repeatedly demonstrates that token compromise often becomes a broader identity failure, not a one-off leak.

In short, short-lived OIDC tokens are safer than static secrets, but they still create meaningful supply chain risk whenever the environment that handles them cannot guarantee runtime containment.

Related resources from NHI Mgmt Group

• Why do short-lived tokens still create security risk?
• When does a short-lived API key still create material risk?
• Why do static credentials create more risk than short-lived access tokens?
• Why do long-lived Kubernetes tokens create more risk than short-lived ones?