A machine credential used by build or deployment automation to authenticate, publish, or modify software artefacts. Because it can change code, infrastructure, or releases at scale, it should be managed as a privileged non-human identity with tight scope and frequent review.
Expanded Definition
A CI/CD token is a machine credential used by build and deployment automation to authenticate to source control, artifact registries, cloud APIs, or release systems. In NHI security, it should be treated as a privileged non-human identity because it can move code, alter infrastructure, and promote releases at machine speed.
Definitions vary across vendors on whether these credentials should be called tokens, service account credentials, or pipeline secrets, but the security meaning is consistent: the credential is trusted by automation, not a human operator. The operational risk is not just theft, but over-scoping, long-lived validity, and reuse across runners, repositories, or environments. That makes lifecycle control more important than the label attached to the credential. The NIST Cybersecurity Framework 2.0 reinforces the need to govern identity, access, and recovery paths in ways that match business-critical automation rather than generic application access.
The most common misapplication is treating a CI/CD token as a low-risk developer convenience, which occurs when pipeline owners store it broadly, leave it long-lived, or reuse it across unrelated build jobs.
Examples and Use Cases
Implementing CI/CD token controls rigorously often introduces release friction, requiring organisations to weigh automation speed against tighter scope, shorter validity, and more frequent rotation.
- A GitHub Actions workflow uses a token to publish signed packages to an internal registry, with permissions limited to one repository and one artifact path.
- A deployment pipeline uses a separate token for staging and production, so a compromise in lower environments cannot directly promote code to live systems.
- An infrastructure-as-code job uses a token to update cloud resources, but the token is brokered through short-lived issuance rather than stored as a static secret.
- A release engineering team reviews token usage after a leak appears in a pull request, following patterns highlighted in the CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge.
- A security team maps pipeline authentication to the NIST guidance in NIST Cybersecurity Framework 2.0 while enforcing separate credentials for build, sign, and deploy steps.
CI/CD tokens also appear in incident patterns where attackers move from source-code exposure into release systems, which is why NHI governance treats them as operational credentials rather than mere configuration values.
Why It Matters in NHI Security
CI/CD tokens are high-value because they often sit at the intersection of code, infrastructure, and release authority. If one token is overused or exposed, an attacker can inject malicious code, tamper with artifacts, or pivot into cloud and identity systems that trust the pipeline. NHIMG research shows how quickly this can become systemic: in a major 2025 supply chain attack, 59% of compromised machines were CI/CD runners rather than personal workstations, which underscores how pipeline identities are now frontline targets.
Token exposure is also persistent. The 2025 State of NHIs and Secrets in Cybersecurity reports that 44% of NHI tokens are exposed in the wild through Teams, Jira tickets, Confluence pages, and code commits, and 91% of former employee tokens remain active after offboarding. That combination creates a long tail of usable access even after the original operational need is gone. A practical control model must therefore include scoping, rotation, revocation, and auditability, not just storage in a vault. The same risk pattern appears in real-world incidents such as the Reviewdog GitHub Action supply chain attack and the Salesloft OAuth token breach.
Organisations typically encounter the blast radius of a CI/CD token only after a malicious release, unexpected infrastructure change, or leaked secret triggers incident response, at which point the token becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret sprawl, token exposure, and lifecycle weaknesses for machine identities. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access management requirements apply to non-human credentials used in automation. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification and minimal trust for every automation credential. |
Treat pipeline tokens as identities and apply least privilege, review, and revocation controls.
Related resources from NHI Mgmt Group
- What is workload identity federation and why is it important for CI/CD security?
- How do I implement secrets scanning in a CI/CD pipeline?
- When should teams prioritise CI/CD hardening over broader secret scanning?
- How should security teams govern machine credentials across cloud and CI/CD environments?
