Why do CI/CD pipelines create non-human identity risk?

Why This Matters for Security Teams

CI/CD pipelines are identity-bearing systems because they authenticate to source control, package registries, cloud APIs, and deployment targets on behalf of the organisation. That makes them high-value NHI control points, not just build infrastructure. A single exposed runner token, compromised workflow, or over-permissioned service account can turn a routine release path into a lateral-movement path. NHI governance guidance in the Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and 96% of organisations store secrets outside proper secrets managers, including in CI/CD tools.

The common mistake is to treat pipeline access as operational convenience rather than privileged identity. That view misses the fact that pipelines often hold long-lived secrets, can impersonate deployers, and are trusted to promote code automatically across environments. The result is that a compromise of the automation layer can become a compromise of the release chain, the cloud estate, and sometimes the software supply chain itself. This is why identity controls must follow the workflow, not stop at the login boundary. Current guidance suggests mapping pipelines into the same governance model used for sensitive service accounts, including review, rotation, and offboarding discipline, as described in CI/CD pipeline exploitation case study. In practice, many security teams encounter pipeline abuse only after a secret leak or deployment anomaly has already widened access.

How It Works in Practice

Secure pipelines need to be designed around the authority they exercise at runtime. That means separating build-time, test-time, and deploy-time identities; using short-lived credentials instead of static tokens; and limiting each job to the smallest set of permissions required for its exact task. The most effective pattern is JIT access: issue an ephemeral token for a single workflow step, bind it to the runner or workload identity, and revoke it when the job finishes. This aligns with NIST Cybersecurity Framework 2.0 expectations around access control, asset management, and continuous monitoring.

In practical terms, teams should ask four questions for every pipeline:

• What NHI does the runner use, and is it a workload identity with a defined trust boundary?
• What secrets are available to the job, and are they scoped per environment or per action?
• Can the workflow write, publish, or deploy without human review, and if so, is that authority time-bound?
• Is access decided by role alone, or by intent, context, branch, provenance, and deployment target?

This is where provenance and policy enforcement matter. Pipelines should not receive blanket RBAC permissions when the real need is to approve one artifact, sign one package, or push one release. Policy-as-code can evaluate context at request time, but current guidance suggests that no single standard yet defines how every organisation should express intent-based authorisation for CI/CD. The operational goal is to make authority temporary, observable, and revocable. See also the Guide to the Secret Sprawl Challenge for why static secrets persist in pipeline tooling. These controls tend to break down when shared runners, monorepos, and third-party build actions all reuse the same identity boundary because attribution and revocation become ambiguous.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery overhead, requiring organisations to balance release speed against credential churn, policy maintenance, and developer friction. That tradeoff is real, especially where teams depend on legacy build systems, self-hosted runners, or vendor-managed actions that were never designed for fine-grained identity scoping. In those environments, the right answer is usually not to remove automation, but to reduce the standing authority that automation carries.

There are also edge cases where RBAC alone is too blunt. A deployment bot that can only promote release artifacts to production during a change window should not hold the same permissions all day. Likewise, a signing workflow may need access to a certificate for milliseconds, not hours. That is why best practice is evolving toward workload identity, short TTL secrets, and runtime policy checks rather than permanent entitlements. The risks are amplified when pipelines interact with AI tooling, package ecosystems, or multi-step release chains; the 52 NHI Breaches Analysis and Reviewdog GitHub Action supply chain attack show how quickly trust can be abused once automation inherits broad authority. That is also why the NIST Cybersecurity Framework 2.0 remains useful as a baseline, even though it does not by itself solve pipeline-specific identity design. In highly federated engineering environments, these controls tend to break down when multiple teams share a common runner pool and no one owns the effective blast radius.

Related resources from NHI Mgmt Group

• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• When do non-human identities pose the greatest risk to organizations?
• Why do AI agents create new risk in non-human identity management?