They often assume short-lived tokens are safe by default. In reality, a malicious workflow can mint fresh tokens during runtime if the trust policy is too broad. The protection comes from narrow claims binding, careful role scoping, and strong control over which workflow files can execute at all.
Why This Matters for Security Teams
Short-lived OIDC tokens are often treated as if expiration alone makes them safe, but CI/CD is a runtime trust problem, not a static credential problem. A workflow that can execute code can usually request a fresh token again unless the trust policy tightly binds the token to a specific repository, branch, job, environment, and audience. That is why token lifetime matters less than who can mint, where it can be used, and what it can reach.
This is especially visible in the kinds of pipeline abuses documented in the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack, where the issue was not simply token age but excessive trust in the workflow path. NIST CSF 2.0 also frames identity and access as an operational control problem, not just a secrets problem, which is why claims validation and least privilege have to be enforced at request time, not only at issuance time, as reflected in the NIST Cybersecurity Framework 2.0. In practice, many security teams discover the gap only after a trusted workflow has already been used to mint more trust.
How It Works in Practice
In CI/CD, OIDC is meant to replace long-lived secrets with ephemeral federation. The security model only works when the identity provider issues a token after checking tightly scoped claims such as repository, workflow file, ref, environment, and audience. The relying cloud role should then verify those claims before granting access to storage, registries, deployment APIs, or secret managers.
For practitioners, the key mistake is assuming the workflow identity itself is trustworthy just because the token is short-lived. A malicious pull request workflow, a compromised action, or an abused reusable workflow can still request a fresh token at runtime if the trust policy allows it. That is why current guidance favors narrow claim binding and explicit deny paths. The strongest patterns also combine:
- branch and tag restrictions for token issuance
- job-level audience binding, not repository-wide access
- separate roles for build, test, and deploy stages
- protected workflow files with review on change
- short TTL plus automatic revocation where supported
- logging that ties every token mint to a specific workflow run
NHIMG’s Guide to the Secret Sprawl Challenge shows why lifecycle discipline matters: short-lived credentials reduce blast radius only if revocation, visibility, and scoping are equally strong. Entro Security’s research on the 2025 State of NHIs and Secrets in Cybersecurity is also a useful reminder that exposed and overused machine identities persist far beyond their intended use. Current guidance suggests treating OIDC tokens as one control in a broader workload-identity strategy, not as a standalone safeguard. These controls tend to break down when reusable workflows, third-party actions, or broad cloud trust policies let unreviewed code mint tokens from otherwise legitimate pipeline context.
Common Variations and Edge Cases
Tighter token binding often increases pipeline maintenance overhead, requiring organisations to balance deployment speed against assurance. That tradeoff becomes more visible in multi-repo estates, monorepos, and platform teams that rely on reusable workflow templates. Best practice is evolving here, and there is no universal standard for every CI/CD platform.
One common edge case is the use of self-hosted runners. If the runner is compromised, short-lived OIDC does not stop token minting unless the runtime environment is also isolated and the cloud trust policy recognizes runner provenance. Another problem appears with federation to multiple clouds or multiple accounts, where a token may be valid for one audience but accidentally accepted by another if claims are too broad.
Security teams should also watch for deployments that use OIDC for convenience but still leave fallback static secrets in place. That creates dual pathways and weakens the intended control. The more mature pattern is to pair OIDC with workload-specific identity, strict workload authorization, and policy checks that execute at request time. NIST guidance on identity risk management and the NIST CSF both support this runtime control model, while the supply-chain lessons from Salesloft OAuth token breach show how token misuse often starts with trust assumptions, not token duration. The control set is weakest when teams assume short TTL alone can compensate for broad workflow permissions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | CI/CD OIDC tokens fail when autonomous workflows can mint fresh trust at runtime. |
| CSA MAESTRO | IAM-02 | MAESTRO addresses machine identity and runtime authorization for cloud automation. |
| NIST AI RMF | GOVERN | AI RMF governance fits runtime identity risk and accountable automation control. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management are central to OIDC trust scoping. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires verification at every token request, not one-time trust. |
Bind token issuance to exact workflow claims and block unreviewed execution paths.
