Why do CI runners create such a high risk of secret exposure?

Why This Matters for Security Teams

CI runners sit at a dangerous intersection: they are trusted to fetch code, build artefacts, and reach deployment targets, yet they also handle the very credentials that protect those systems. That means a runner compromise can turn a routine build into a secret-collection event, especially when tokens are injected broadly or reused across jobs. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

The risk is not just leakage from logs. A self-hosted runner can leave credentials on disk, in environment variables, build caches, or workspace artefacts after a job ends. That creates multiple recovery paths for an attacker who gains local access, compromises a dependency, or hijacks a job step. The OWASP Non-Human Identity Top 10 treats secret handling and privilege exposure as core NHI failure modes, because the control plane is only as safe as the runtime that executes it. In practice, many security teams discover runner exposure only after a build server or pipeline token has already been used to pivot into production.

How It Works in Practice

CI runners become high-risk secret holders because they need temporary access to many systems in a very short time. A typical pipeline may authenticate to source control, package registries, cloud APIs, and deployment targets within one job. If those credentials are long-lived, broadly scoped, or injected before the job knows what it actually needs, the runner becomes a reusable theft target rather than a narrow-purpose execution environment.

The safer pattern is to treat the runner as a short-lived workload identity and issue secrets just in time. That means the runner proves what it is, receives only the minimum runtime access needed for the task, and then has that access revoked or expired immediately after completion. This is the operational logic behind workload identity approaches such as SPIFFE and OIDC-based federation, where the job gets a cryptographic identity first and retrieves secrets only when policy allows it.

• Use ephemeral credentials with tight TTLs instead of static API keys.
• Scope secrets per job, not per runner image or shared host.
• Keep secrets out of logs, artefacts, and cached layers.
• Rotate and revoke immediately after use, not on a calendar cycle alone.
• Separate hosted runners from self-hosted runners where trust boundaries differ.

This lines up with the broader lessons in the Guide to the Secret Sprawl Challenge, which shows how secrets leak into places teams do not consistently monitor, and with the NIST Cybersecurity Framework 2.0, which emphasizes asset governance, continuous monitoring, and least privilege. These controls tend to break down when self-hosted runners share persistent disks or caches across projects because secrets can survive beyond the job boundary.

Common Variations and Edge Cases

Tighter runner controls often increase pipeline friction, so organisations must balance build speed against leakage risk. That tradeoff is most visible when teams rely on long-lived service accounts for convenience, or when multiple repositories share the same self-hosted runner pool. Current guidance suggests that reusable credentials and shared execution hosts should be treated as exceptions, not defaults, but there is no universal standard for exactly how much isolation is enough.

Hosted runners generally reduce disk persistence risk, but they do not eliminate exposure if secrets are overbroad or printed into logs. Self-hosted runners are more flexible for private networks, yet they also expand the attack surface through host compromise, leftover workspace data, and imperfect teardown. The most common failure mode is assuming that a clean job end means clean secret removal. It does not if caches, temp files, container layers, or shell history remain accessible. NHI Management Group’s research on the 52 NHI Breaches Analysis shows how quickly identity exposure becomes breach material once a secret is reused or retained longer than intended. The practical takeaway is to design for temporary trust, not persistent access, because CI infrastructure fails most often at the handoff between job completion and host reuse.

Related resources from NHI Mgmt Group

• Why do Windows admin gateways create such high-risk identity exposure when AD CS is nearby?
• 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?
• Why can a single SaaS app create such a large blast radius?