Runner-Held Credential Persistence

What runner-held credential persistence means

Runner-held credential persistence is not just “a secret was present once”, it means the runner can retain usable authentication material after the job boundary has ended. That persistence turns a short-lived build context into a later recovery path, especially when credentials land in files, variables, caches, or logs that survive beyond the intended task.

The security problem is that the runner may outlive the job’s trust boundary. A later pipeline run, another tenant on the same worker, or anyone with filesystem or cache access can potentially recover material that was supposed to disappear when the build completed.

Why it is dangerous in CI and build systems

CI runners are attractive targets because they often sit close to source code, artifact signing, deployment credentials, package registries, and cloud APIs. If a runner keeps tokens or keys, an attacker who reaches the host, workspace, or cache can reuse them to impersonate the pipeline, publish malicious artifacts, access downstream services, or move laterally into connected systems.

The danger increases when the runner is shared, long-lived, or reused across jobs with different trust levels. The same persistence that helps performance or debugging can also preserve high-value secrets well past the point where they should have expired.

For a concise framework view of the underlying risk pattern, OWASP Non-Human Identity Top 10 treats secret leakage, overprivilege, and lifecycle failures as core failure modes in machine-access material.

How organisations check exposure

Exposure review starts with inventorying where the runner writes and reuses state: workspace directories, environment injection, local caches, artifact folders, and any mounted volumes. Teams should confirm whether the runner is ephemeral or persistent, whether jobs share a host, and whether cleanup actually removes credentials between executions.

Vendor docs and platform settings matter because the same CI product can behave very differently depending on runner isolation, cache retention, and filesystem reuse. If a credential can survive a job finish, treat that as exposure even before you find evidence of misuse.

For guidance on the broader secret-handling mechanics that make this exposure possible, Secrets Management Guide explains how centralisation, rotation, dynamic secrets, and secretless patterns reduce persistence risk.

When the issue involves API tokens or deployment keys specifically, API Key Management Guide is useful for understanding lifecycle controls and revocation expectations after exposure.

Remediation and detection after exposure

Remediation is usually two-part: remove the persistence mechanism and assume the material may already be exposed. That means wiping or reimaging the runner where appropriate, reducing job-to-job residue, and replacing any tokens, keys, or certificates that may have been retained.

Detection should look for secret material in places that should have been transient, including caches, temp files, archived workspaces, and logs. Post-patch review should also check whether the retained credential was used from an unexpected source, whether new jobs inherited older state, and whether any downstream service shows suspicious access with the same credential.

Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference when deciding whether the exposed material should have been short-lived in the first place.

For real-world consequence, Open source package compromise covers the common response pattern where CI credentials must be revoked after a supply-chain incident.

Designing runners to avoid persistence

The safest pattern is to make runner state disposable by default. Ephemeral workers, isolated jobs, minimal local caching, and automatic cleanup reduce the chance that one build can hand credentials to the next. Where persistence is unavoidable, scope access tightly and ensure cleanup is verified rather than assumed.

Architecturally, the goal is to stop credentials from becoming durable runner assets. If a token must exist during a job, it should be created with the shortest practical lifetime and removed from every writable location before the runner is reused.

Identity Threat Detection and Response (ITDR) Guide is relevant where retained credentials become an identity compromise problem and the response must include detection, containment, and recovery.

Guide to the Secret Sprawl Challenge is also relevant because CI/CD residue is one of the common ways secret sprawl becomes operationally persistent.

Related resources from NHI Mgmt Group

• Who is accountable when malware uses legitimate tools to hide persistence and credential theft?
• What do security teams get wrong about workflow runner persistence?
• What should teams do when a CI/CD workflow attempts persistence through runner registration?
• What are the signs that a CI/CD runner has been abused for secret theft or persistence?