Short-lived OIDC tokens reduce persistence, but they do not eliminate abuse if the workflow context is already compromised. Static secrets are easier to steal and reuse later, while federated tokens are harder to persist but can still authorize immediate malicious action. Governance should evaluate both the lifetime and the authority of the credential.
How short-lived OIDC tokens differ from static CI/CD secrets
Short-lived OIDC tokens are federated credentials with a narrow time window and a specific trust context, so they are usually less reusable if stolen. Static CI/CD secrets, by contrast, are long-lived values stored for later reuse, which makes them far easier to exfiltrate and persist with. The key difference is not just lifetime, but how much authority the credential retains after exposure.
That distinction matters in supply chain risk because a short-lived token can still be dangerous if an attacker already controls the workflow or runner at issuance time. A static secret increases exposure over time, while an OIDC token reduces persistence but may still authorize immediate malicious actions during its valid window.
For federation basics, the token model used by OIDC is defined by OpenID Connect Core 1.0, while machine-to-machine OAuth flows such as client credentials are covered in RFC 6749: The OAuth 2.0 Authorization Framework.
Why supply chain exposure changes the risk profile
In CI/CD and build pipelines, the practical question is whether the credential can be reused after compromise, whether it can be scoped tightly, and whether it is bound to the right workflow or repository context. Static secrets are attractive to attackers because they often survive across runs, environments, and time, which makes them useful for replay, lateral movement, and secret harvesting.
Short-lived OIDC tokens reduce that persistence, but they do not remove the blast radius if the pipeline context is already trusted too broadly. If the workflow can mint a token with production-level authority, compromise of the runner, job definition, or approval path can still lead to immediate misuse even when no secret is stored at rest.
That is why supply chain risk is really a combination of credential lifetime, issuer trust, and authorization scope. A short-lived token with excessive authority can be more dangerous than a static secret with tight scoping, and a static secret with weak storage and broad reuse is often the easiest path to durable compromise.
For the supply-chain side of the problem, SLSA is the clearest external control model for build provenance and integrity, while NIST SSDF (SP 800-218) supports secure development and pipeline hardening decisions that reduce exposure to both token abuse and secret theft.
What practitioners should evaluate before choosing one model over the other
The right comparison is not “federated token versus secret” in the abstract, but “what can this credential do if the workflow is compromised, and how long can that authority be abused?” If the answer includes production deployment, package publishing, cloud access, or artifact signing, then the authority boundary matters as much as token expiration.
Teams should also separate storage risk from issuance risk. Static secrets create a standing theft target, while OIDC pushes trust into the federation and authorization policy, which means you must validate audience, subject, branch, environment, and repo constraints with care. A short lifetime is only helpful when the token cannot be minted outside the intended context.
For implementation guidance, the OWASP Cheat Sheet Series is useful for credential handling patterns, and OpenID Connect Core 1.0 remains the reference point for understanding what the federated token is actually asserting and what the relying party is trusting.
Risk and Threat Considerations
Static CI/CD secrets are high-value persistence assets: once stolen, they can often be replayed later, outside the original workflow, and across multiple attack attempts. Short-lived OIDC tokens are harder to persist with, but they still support immediate abuse if an attacker has already compromised the workflow runtime, approval path, or federation trust.
Failure mechanism: Attackers either steal a reusable static secret, or hijack a live workflow and exploit the authority of a freshly issued OIDC token before it expires. In both cases, the danger comes from excessive privilege, weak scoping, or overbroad trust in the CI/CD path.
Impact: The result can be package tampering, malicious deployments, artifact poisoning, cloud access, or secret exfiltration from downstream systems. In supply chains, even brief credential abuse can have outsized consequences because build and release systems often sit close to production trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Directly addresses build provenance and artifact integrity in CI/CD supply chains. |
| Recommendation — Adopt provenance controls that prevent untrusted build and release artifacts from reaching production. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle handling of secrets and tokens used by CI/CD systems. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Applies to federated machine or workload authentication via OIDC in pipeline trust chains. | |
| Recommendation — Rotate, revoke, and scope CI/CD authenticators so stolen values lose usefulness quickly. Use federated authentication for pipeline actors and constrain accepted assertions to approved trust contexts. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Static CI/CD secrets create leakage exposure that directly drives supply chain abuse risk. |
| NHI-07 — Long-Lived Secrets | Static CI/CD secrets are long-lived and therefore easier to steal and reuse later. | |
| Recommendation — Eliminate exposed pipeline secrets and treat any leaked token as immediately reusable until revoked. Replace long-lived pipeline secrets with short-lived credentials wherever the workflow allows it. | ||
Practitioner Guidance
What to prioritise: Evaluate the credential by both lifetime and authority. If a token or secret can reach production systems, signing keys, or release automation, treat scoping and trust boundaries as the primary control, not expiration alone.
What to verify: Confirm that OIDC tokens are bound to the intended repository, branch, environment, and audience, and verify that static secrets are removed from places where they can be copied or replayed. A credential model is only as safe as the narrowest trust check in the issuance path.
Practitioner takeaway: Short-lived federation reduces persistence, but supply chain safety depends on preventing both secret reuse and excessive live authority, because either one can be enough for immediate compromise.
Related resources from NHI Mgmt Group
- Why do short-lived OIDC tokens still create meaningful supply chain risk?
- Why do long-lived CI/CD or workstation secrets increase supply-chain risk?
- What is the difference between short-lived tokens and static API keys for agents?
- What is the difference between short-lived access tokens and refresh tokens in identity risk?