Yes, when the workflow involves external packages, extensions, or untrusted code execution. Short-lived tokens limit the value of a successful scrape and reduce the chance that one compromised runner can seed additional compromise. The key is to pair that move with tighter scope and separate publisher privileges.
Why short-lived tokens beat standing credentials in CI/CD
CI/CD is a high-churn, high-trust environment: runners spin up, fetch code, reach out to registries and cloud services, and then disappear. Standing credentials give an attacker something durable to steal and reuse. Short-lived tokens shrink that window, but they only work well when scope is tight and each pipeline path gets the minimum access it needs.
That matters most when workflows consume external packages, extensions, or untrusted code. In those cases, a leaked credential is not just an account problem, it can become a supply-chain problem. The practical goal is to make each token useful only for one job, one audience, or one narrowly defined action, so compromise does not automatically become persistence.
Think of the design choice as blast-radius control, not convenience. A standing secret can be scraped from logs, environment variables, build artifacts, or a compromised runner and then reused later. A short-lived token reduces reuse value, especially when token audience, expiry, and privileges are all constrained. That is why this pattern pairs naturally with secret scanning, rotation discipline, and separate publisher privileges for release paths.
Risk and Threat Considerations
CI/CD systems are attractive to attackers because they sit close to source code, deployment credentials, and supply-chain trust. If a runner, build step, or injected dependency can access a long-lived secret, compromise can spread beyond a single pipeline run and into publishing, signing, or downstream deployment activity.
Failure mechanism: standing credentials are reusable after theft, so one successful scrape or runner compromise can be replayed across jobs, repositories, or environments until someone rotates the secret and closes every place it was exposed.
Impact: attackers can plant malicious changes, exfiltrate additional secrets, impersonate release automation, or move from build compromise into broader environment compromise, especially where publisher privileges are not separated from routine build access.
How to design the token model without creating new weak points
The main design decision is not “token versus secret” in the abstract, it is which actions truly need reusable access. Build-time access to fetch packages or call internal APIs should usually be narrower and shorter-lived than release-time access to sign artifacts or publish packages. If every workflow gets the same broad token, you have modernised the credential format without reducing the privilege problem.
Token scope should match the job boundary. Short lifetime helps only when the token cannot be used outside the intended audience, repository, environment, or service. For example, a token that can read artifacts but also mint new deployment credentials defeats the purpose. The safer pattern is to separate read, build, and publish paths so compromise in one path does not automatically unlock the others.
For pipeline trust, also distinguish between credentials that authenticate the runner and credentials that authorize the job. A runner may need to reach a package registry, but that does not mean it should hold standing rights to production systems. Where the process supports it, use ephemeral credentials for the runner and keep durable publisher authority off the normal build path.
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, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD secret exposure is central to the question. |
| NHI-05 — Overprivileged NHI | The answer hinges on limiting pipeline privilege and publisher access. | |
| NHI-07 — Long-Lived Secrets | The question directly compares standing credentials with short-lived tokens. | |
| Recommendation — Use short-lived credentials and reduce secret exposure paths in pipelines. Scope CI/CD credentials to the minimum permissions each job requires. Replace standing CI/CD credentials with expiring tokens wherever possible. | ||
| SLSA | Build Provenance and Integrity | CI/CD credential choices affect artifact provenance and supply-chain trust. |
| Recommendation — Protect build and publish paths so compromised pipelines cannot corrupt artifact integrity. | ||
| CIS Controls v8 | CIS-5 — Account Management | The topic is about credential lifecycle and restricting standing access in pipelines. |
| Recommendation — Use separate accounts and remove standing credentials from automated build paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived tokens and rotation are authenticator lifecycle controls. |
| AC-6 — Least Privilege | The answer stresses tighter scope and separate publisher privileges. | |
| Recommendation — Issue expiring authenticators and rotate them before reuse becomes a risk. Limit each CI/CD credential to the minimum access needed for its job. | ||
Practitioner Guidance
What to verify: confirm that no CI/CD job needs a standing credential simply because a short-lived exchange is harder to implement. If a workflow can authenticate with an ephemeral token, it usually should; if it cannot, document the exception and limit the secret to the smallest possible audience and lifetime.
Decision rule: if the workflow touches untrusted code, external packages, or third-party actions, treat long-lived credentials as a high-risk default and require a narrower token design before approval. If the workflow is fully internal and cannot yet use ephemeral auth, compensate with tighter scoping, isolated runners, and aggressive rotation.
What good looks like: build jobs can authenticate for only the time and scope they need, publish privileges are separated from ordinary build privileges, and a runner compromise does not expose credentials that remain valid long enough to be reused elsewhere.
Practitioner takeaway: short-lived tokens are not the whole control, they are the first half of a safer CI/CD trust model; the second half is making sure the token cannot do more than the specific pipeline step it was issued for.
Related resources from NHI Mgmt Group
- Why do long-lived authentication tokens create more risk in CI/CD systems than short-lived credentials?
- Why do short-lived tokens still create major risk in CI/CD environments
- What do security teams get wrong about short-lived OIDC tokens in CI/CD?
- How should organisations respond when an IDE extension attack targets cloud tokens, CI/CD secrets, and AI coding assistant credentials at the same time?