Runner Persistence

Runner persistence is the use of CI or build execution infrastructure to retain access after the original malicious artifact is removed. It matters because the attacker no longer depends on the infected package alone and can continue acting through trusted automation assets.

Expanded Definition

Runner persistence describes a post-compromise condition in CI and build execution infrastructure where an attacker maintains access through the runner itself, not just through the original malicious package, commit, or job payload. In NHI security, that distinction matters because runners often hold ephemeral or semi-ephemeral credentials, repository tokens, cloud role assumptions, and artifact signing permissions that can be reused after the initial code is removed.

Definitions vary across vendors and platform teams on whether the term should cover only malicious persistence or also legitimate automation that survives redeployments, but the core security issue is the same: trusted build infrastructure becomes a durable access path. NIST SP 800-53 Rev. 5 Security and Privacy Controls provides a useful control baseline for access control, audit logging, and system integrity expectations, while NIST AI Risk Management Framework helps frame the operational risk of autonomous or delegated execution pathways.

The most common misapplication is treating runner compromise as a transient build failure, which occurs when teams rotate the package but leave the runner image, cache, or token-binding intact.

Examples and Use Cases

Implementing runner hardening rigorously often introduces friction for build velocity, requiring organisations to weigh faster pipelines against tighter isolation, shorter credential lifetimes, and more frequent re-registration of runners.

• A self-hosted ci runner is registered with a long-lived token, and the attacker keeps using it after the malicious dependency is removed from the repository.
• A compromised build job writes a backdoor into a shared cache directory, so later jobs execute attacker-controlled logic even though the original commit is gone.
• A build runner assumes cloud credentials for signing artifacts, and the attacker reuses that trust relationship to access storage and deployment APIs.
• An incident review shows that runner logs, secrets files, and environment variables exposed the path of persistence, prompting a rebuild rather than a simple patch.
• The pattern in the Salt Typhoon US telecoms breach illustrates how stolen credentials and trusted access can outlast the initial intrusion, making persistence the real operational problem.

For implementation guidance, teams often compare CI trust boundaries against NIST SP 800-53 Rev. 5 Security and Privacy Controls and the stricter runner isolation patterns promoted by the SPIFFE project, especially where ephemeral workload identity is expected.

Why It Matters in NHI Security

Runner persistence is an NHI problem because CI and build systems frequently store, mint, forward, or validate non-human credentials on behalf of automation. Once an attacker persists in a runner, they can impersonate pipelines, sign artifacts, call deployment APIs, and stage downstream access that looks operationally legitimate. That is why build infrastructure should be treated as identity-bearing infrastructure, not just compute.

NHI Mgmt Group has found that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes runner compromise especially dangerous because the runner itself can become a secret transport and reuse layer. The same exposure pattern appears in broader NHI risk data: if 97% of NHIs carry excessive privileges, a compromised runner often inherits more authority than the workflow truly needs.

Organisations typically encounter runner persistence only after a package is cleaned up but the attacker returns through a build agent, at which point containment, credential revocation, and runner reimaging become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What do security teams get wrong about workflow runner persistence?
• Workflow Runner Persistence
• When does malware persistence become an NHI governance issue?
• CI runner