Because they often outlive the job that created them and are broader than the task needs. If a token sits in a CI/CD variable or config file, anyone who reaches that environment can inherit access long after the original work is finished. That turns ordinary build automation into durable cloud exposure.
Why This Matters for Security Teams
service account tokens in pipelines are risky because they turn a build step into a standing access path. A token that was meant for one job can be reused by later jobs, copied into logs, inherited by compromised runners, or pulled from a misconfigured CI variable. That is why pipeline exposure is not just a secrets hygiene issue, but a privilege persistence problem across the software supply chain.
This pattern shows up repeatedly in incident reporting. NHIMG research on the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study highlights how pipeline secrets move faster than revocation processes do. NIST also treats identity and access governance as an operational control, not a one-time setup, in the NIST Cybersecurity Framework 2.0.
GitGuardian’s State of Secrets Sprawl 2026 report found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is the core residual-risk problem: detection without revocation leaves attackers with a durable path. In practice, many security teams encounter this only after a runner, log archive, or third-party action has already reused the token outside the original job.
How It Works in Practice
The risk comes from the mismatch between pipeline behavior and static credential design. Build systems are dynamic: jobs spin up and down, runners are reused, branches and pull requests introduce untrusted input, and tooling often needs to call registries, cloud APIs, artifact stores, and deployment targets. A long-lived service account token does not reflect that reality. It stays valid long after the job that needed it has finished.
Current guidance suggests replacing broad static tokens with short-lived, task-scoped credentials and workload identity where possible. That means the pipeline proves what it is at runtime, then receives narrowly scoped access only for the duration of the task. For example, ephemeral OIDC-based federation, workload identity bindings, and just-in-time secrets reduce the blast radius if a runner is compromised. This aligns with the operational lessons in the Salesloft OAuth token breach and the Reviewdog GitHub Action supply chain attack, where token exposure became access exposure.
Operationally, the most effective control pattern is layered:
- Issue tokens just in time, with a narrow TTL and job-specific scope.
- Bind credentials to workload identity rather than human-managed secrets.
- Separate build, test, and deploy identities so one compromised stage cannot reach all others.
- Revoke automatically when the job ends or fails, not at a fixed review cycle.
- Monitor runners, logs, and artifact outputs for secret leakage and reuse.
GitGuardian’s research on secrets sprawl also shows that private repositories are not inherently safe, so pipeline token handling must assume internal exposure paths as well as public ones. These controls tend to break down when legacy CI systems cannot support federation or when self-hosted runners share state across jobs, because the token’s lifetime becomes longer than the environment’s trust boundary.
Common Variations and Edge Cases
Tighter token controls often increase build complexity and operational overhead, so organisations have to balance reduced residual risk against developer friction and release speed. That tradeoff is real, especially in monorepos, multi-cloud pipelines, and teams that depend on third-party actions or shared runners.
There is no universal standard for this yet, but best practice is evolving toward per-job identity, short-lived credentials, and automated revocation. In environments with air-gapped runners or older CI platforms, static tokens may still be unavoidable for a period of time. In those cases, the safer compromise is strict scoping, isolated runners, encrypted secret storage, aggressive rotation, and continuous detection of token misuse. NHI governance research in The State of Secrets Sprawl 2026 and CI/CD pipeline exploitation case study shows that exposure often begins in the pipeline but ends in downstream cloud and SaaS access.
The hardest edge case is when a token is needed by multiple automated systems over time. In that situation, the question is not whether the token is convenient, but whether it can be replaced by delegated workload identity or split into smaller privileges. If neither is possible, the residual risk should be treated as a standing exception with explicit ownership, expiry, and review.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses long-lived NHI secrets in CI/CD pipelines. |
| NIST CSF 2.0 | PR.AC-4 | Covers least-privilege access for service accounts used by pipelines. |
| NIST AI RMF | Supports governance for automated, context-driven access decisions in pipeline workflows. |
Define ownership, monitoring, and lifecycle controls for automated credentials under AI and workload governance.
