Why do CI/CD runners and build tools increase NHI risk?

Why This Matters for Security Teams

CI/CD runners and build tools are not just automation plumbing. They routinely touch source code, release artifacts, cloud APIs, package registries, and deployment targets, which means they often hold the same secrets and tokens that an attacker wants. NHI Management Group research in the Ultimate Guide to NHIs shows that 96% of organisations store secrets outside of dedicated secrets managers, including code, config files, and CI/CD tools.

That matters because build identities are usually designed for speed, not containment. When a runner can publish, deploy, assume roles, or reach internal services, a single compromised job can become a broad identity event rather than a narrow pipeline issue. The attacker does not need to break production directly if the build system can already sign artifacts, retrieve tokens, or chain into downstream environments. Current guidance from NIST Cybersecurity Framework 2.0 supports strong identity governance, but in practice build platforms are still treated as low-risk infrastructure. In practice, many security teams encounter runner abuse only after secrets have already been exfiltrated from a compromised job or poisoned dependency.

How It Works in Practice

Build infrastructure increases NHI risk because it concentrates credentials at the exact point where untrusted code is executed. A package install, test step, container build, or release job can expose environment variables, mounted files, cloud role tokens, and SSH material to code that was never meant to have standing access. That is why build runners should be treated as privileged workload identities, not generic servers.

The practical control model is to reduce standing privilege and move to task-scoped access. Instead of long-lived cloud keys in pipeline variables, use short-lived credentials issued just in time, with tight TTLs and automatic revocation after the job completes. For cloud access, prefer workload identity patterns that prove what the runner is through cryptographic identity, rather than relying on reusable secrets alone. For authorisation, the better pattern is policy evaluated at request time, using context such as repository, branch, signer, environment, and job purpose. This is closer to how the Secret Sprawl Challenge and CI/CD pipeline exploitation case study describe real-world compromise paths.

• Issue ephemeral credentials per job, not reusable pipeline-wide secrets.
• Limit runners to the minimum repository, environment, and registry scope.
• Separate build, test, and release identities so one compromise does not unlock all stages.
• Rotate and revoke tokens immediately when a pipeline fails, is retried, or is tampered with.
• Log secret access and artifact signing as identity events, not just build events.

These controls tend to break down in self-hosted runners with persistent disks, shared agents, or multi-tenant build fleets because secrets survive beyond the job boundary.

Common Variations and Edge Cases

Tighter build controls often increase friction for developers and platform teams, so organisations have to balance release velocity against containment. That tradeoff becomes sharper in environments where builds are distributed across ephemeral containers, hosted runners, on-prem agents, or air-gapped systems.

Best practice is evolving for these edge cases. In highly regulated environments, some teams keep signing keys completely outside the runner and delegate only a signing request to a separate service. In containerised pipelines, the main risk is often not the container image itself but the credentials injected at runtime into steps that can be inspected, copied, or reused. In monorepos and multi-service pipelines, one job frequently needs different entitlements per component, which makes static RBAC brittle because access patterns change by branch, dependency, and deployment target.

For that reason, current guidance suggests treating every runner as potentially exposed and every secret as disposable. The strongest programs pair short-lived credentials with network segmentation, artifact attestation, and strict offboarding of runner identities. The NHI Management Group Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same operational reality: once CI/CD credentials are over-scoped, the blast radius extends far beyond the build system itself.

Related resources from NHI Mgmt Group

• Why do private container images increase NHI risk in CI/CD environments?
• Why do developer endpoints increase the risk of cloud and NHI compromise?
• Why do AI coding tools increase governance risk for IAM and NHI teams?
• Why do CI/CD pipelines increase lateral movement risk?