Subscribe to the Non-Human & AI Identity Journal

Pipeline privilege escalation

Pipeline privilege escalation happens when CI/CD or build automation holds access broad enough to move from development into higher-value systems. The issue is not that the pipeline runs automatically, but that its identity is trusted across environments with too little scope control.

Expanded Definition

Pipeline privilege escalation describes a CI/CD or build pipeline whose runtime identity can cross trust boundaries and reach systems that are more sensitive than the pipeline itself should control. The concern is not automation alone. It is overbroad authentication and authorisation on the pipeline service account, runner, or deployment token.

In NHI governance, this term overlaps with secrets sprawl, environment trust, and the lifecycle of machine credentials. A pipeline may need access to source code, artifact registries, package stores, and deployment endpoints, but each permission should be separately scoped and time-bounded. The OWASP Non-Human Identity Top 10 treats excessive privilege and poor secret handling as recurring failure modes, while the Ultimate Guide to NHIs shows why lifecycle control matters when machine identities are trusted too broadly.

Definitions vary across vendors on whether this is a pipeline identity problem, a secrets management problem, or a broader CI/CD trust boundary issue, but the practical meaning is consistent: a compromised pipeline can become a bridge into higher-value systems if its permissions are not tightly segmented. The most common misapplication is treating deployment automation as inherently trusted, which occurs when the same credential can build code, publish artifacts, and deploy into production.

Examples and Use Cases

Implementing pipeline privilege controls rigorously often introduces release friction, requiring organisations to weigh deployment speed against the cost of tighter approval and token scoping.

  • A GitHub Actions runner can read production secrets from a vault, then push them into logs or artifacts after a compromised workflow step.
  • A build service account that can both sign packages and deploy them becomes a lateral-movement path if the build job is tampered with, as illustrated in the CI/CD pipeline exploitation case study.
  • A release pipeline uses a long-lived API key for multiple environments, so one leaked token unlocks staging, pre-production, and production in a single blast radius.
  • A third-party action or plugin inherits excessive permissions and is able to exfiltrate secrets, similar to the pattern discussed in the Reviewdog GitHub Action supply chain attack.
  • A package publishing workflow has write access to the artifact registry but also to infrastructure deployment roles, allowing a poisoned build to reach runtime systems.

The Guide to the Secret Sprawl Challenge is especially relevant where teams embed secrets directly into CI/CD variables, while the OWASP guidance helps separate identity scope from secret storage concerns.

Why It Matters in NHI Security

Pipeline identities are high-value NHIs because they often sit at the intersection of code, secrets, and production access. When they are overprivileged, attackers do not need to break a human account to reach sensitive assets. They only need to compromise a workflow, build step, plugin, or token reuse pattern. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which makes CI/CD trust concentration a realistic risk amplifier rather than a corner case.

This matters because pipeline compromise often leads to secret theft, tampered releases, poisoned artifacts, and hidden persistence across environments. The issue is not just access control, but governance over which identity can do what, where, and for how long. The OWASP Non-Human Identity Top 10 and the Azure Key Vault privilege escalation exposure case both reinforce that exposed secrets and overbroad roles are often the enabling conditions.

Organisations typically encounter this consequence only after a compromised build or deployment has already touched production, at which point pipeline privilege escalation 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-01 Covers excessive privilege and lifecycle risks for non-human identities in pipelines.
NIST CSF 2.0 PR.AA-05 Addresses identity proofing and access control for system and service identities.
NIST Zero Trust (SP 800-207) SC-7 Zero Trust requires explicit, least-privilege access between pipeline identities and target systems.

Restrict pipeline credentials, segment permissions, and review access across environments.