The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
Expanded Definition
CI/CD pipeline identity is the machine identity that lets build, test, release, and deployment systems authenticate to source control, artifact registries, cloud control planes, and secrets managers. In NHI security, it is not just a token or service account; it is an operational trust anchor for automation.
Definitions vary across vendors because some teams treat this identity as a single service account, while others model it as a set of ephemeral credentials, workload identities, and delegated roles. For practical governance, the important point is that CI/CD pipeline identity must be scoped to the exact stage, repository, environment, and time window it needs. That aligns with NIST Cybersecurity Framework 2.0 and Zero Trust thinking, where access is continuously limited and verified rather than presumed.
In mature environments, this identity is designed for JIT access, short-lived secrets, and explicit revocation after each run or release. The most common misapplication is granting a single long-lived pipeline credential broad access to every repository and environment, which occurs when release speed is prioritized over identity scoping.
Examples and Use Cases
Implementing CI/CD pipeline identity rigorously often introduces operational overhead, requiring organisations to weigh deployment speed against tighter credential rotation, approval gates, and environment isolation.
- A GitHub Actions or similar runner uses a short-lived identity to pull packages from an internal registry, then drops privileges after the job completes.
- A deployment pipeline assumes a limited cloud role only for production release steps, rather than reusing a shared secret across all branches and environments.
- A security team detects exposed build credentials in logs or configuration and cross-checks the issue against patterns described in the CI/CD pipeline exploitation case study.
- Platform engineers replace static tokens with federated workload identity, following identity guidance that mirrors the least-privilege model in the Ultimate Guide to NHIs.
- Release governance ties pipeline permissions to environment-specific policy so a staging workflow cannot impersonate a production deployer.
These patterns are especially relevant when automation is also touching secrets, registries, and cloud APIs, because each integration point expands the attack surface.
Why It Matters in NHI Security
CI/CD pipeline identities are high-value NHIs because they often hold privileged access, can reach multiple systems, and are trusted to act without human intervention. When they are over-permissioned or poorly monitored, one compromised runner can become a launch point for code injection, secret theft, tampered releases, and cloud compromise.
NHIMG research shows the scale of the problem: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, while The State of Secrets Sprawl 2026 found 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. That combination makes pipeline identity a governance issue, not just an engineering detail.
It also reinforces why NHI controls must extend beyond code scanning into credential lifecycle management, environment separation, and automated revocation. The most useful external reference point is NIST Cybersecurity Framework 2.0, which supports access control, monitoring, and recovery disciplines that apply directly to build systems. Organisations typically encounter pipeline identity as an urgent issue only after a release is abused, at which point the identity itself becomes operationally unavoidable to investigate and contain.
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 and overprivileged machine identities in automated pipelines. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access control for automated build and deploy identities. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of workload and pipeline access. |
Use short-lived credentials and remove broad pipeline secrets from code and configs.
