What are the signs that a CI/CD runner has been used as persistence?

What persistence on a CI/CD runner usually looks like

A runner used for persistence behaves less like a one-time intrusion and more like an implanted foothold inside the build system. The tell is repeated control over execution: attacker-added workflows, altered job definitions, or runner changes that keep re-running malicious code whenever the repository events they target occur. In practice, the runner becomes part of the attacker’s access path, not just a staging point.

Watch for a pattern that survives normal developer activity. A legitimate build may fail and retry, but persistence tends to show up as recurring execution tied to unusual branches, tags, pull requests, or dispatch events, especially when those runs are not explained by active development work.

Another useful clue is trust boundary drift. If self-hosted runners start processing repositories they never handled before, or if job logic suddenly begins reaching into secrets, caches, deployment credentials, or internal network endpoints, the runner may be doing more than building code. That is often where persistence starts to look like operational abuse of a CI/CD control plane.

Telemetry and configuration clues that matter most

Focus first on runner registration and workflow provenance. New runner registrations, unfamiliar labels, unexpected runner groups, or repository-level automation that no owner can account for are stronger signals than a generic spike in pipeline activity. The same is true for workflow files or action references that were added outside normal change control.

Job-level logs should be read for context, not just failure. Suspicious signs include execution that starts from an odd repository event, shell steps that fetch remote payloads, environment variables being enumerated, and jobs that interact with secrets or deployment targets without an obvious build need. If the runner is persistent, the log trail often shows repeated attempts to re-establish code execution rather than a single clean compromise.

Configuration drift is equally important. Review whether runner binaries, service wrappers, startup scripts, scheduled tasks, container images, or volume mounts were changed to preserve execution across reboots or redeployments. On self-hosted infrastructure, that kind of persistence can outlive workflow cleanup unless the host itself is rebuilt or reimaged.

How persistence differs from normal CI/CD noise

CI/CD systems are noisy by design, so the key is to separate ordinary automation from unauthorized automation. A busy repository can generate many runs, but persistence usually adds one of three things: a new control point, a new trigger, or a new path back into trusted execution. That may be a malicious workflow file, a tampered action reference, or a runner that now executes attacker-chosen code after every refresh.

It also helps to compare current behavior with a known-good baseline. If the same runner account, registration token, or host repeatedly reappears after deletion, the problem is not just compromised credentials, it is an unresolved persistence mechanism. For background on runner-focused compromise patterns and secret exposure in CI/CD, see CI/CD pipeline exploitation case study and CI/CD Pipeline Identity Security Guide.

Runner persistence can also be a supply-chain problem when the attacker uses the runner to modify build outputs, steal signing material, or inject steps into release automation. In those cases, the runner is not merely compromised, it becomes a standing platform for code or credential abuse across multiple repositories. A useful example of how pipeline abuse can spread through trusted build infrastructure is Guide to the Secret Sprawl Challenge.

Risk and Threat Considerations

Persistent runner abuse is risky because CI/CD systems are trusted by design and often hold broad access to source code, secrets, artifact signing, and deployment paths. Once an attacker can repeatedly execute through a runner, they can turn a temporary foothold into a durable control channel that survives ordinary password resets and account cleanup.

Failure mechanism: The attacker plants or tampers with workflow logic, runner registration, or host-level startup behavior so malicious code keeps executing whenever the pipeline is triggered or the host restarts.

Impact: This can lead to recurring secret theft, poisoned builds, unauthorized deployments, and repeated re-entry into the environment even after the initial compromise is noticed.

Practitioner Guidance

What to verify: Confirm whether runner registrations, workflow file changes, and repository dispatch events align with approved change activity. If a runner or workflow appeared outside normal ownership, treat it as a persistence lead rather than a simple misconfiguration.

What to prioritise: Rebuild or isolate the runner host before trusting token revocation alone. If the attacker may have altered host startup, container images, or workflow definitions, credentials can be reissued while the persistence mechanism remains intact.

Common mistake: Teams often remove the visible malicious workflow but leave the runner, registration token, or modified automation path in place. That leaves the attacker with a ready-made way back in.

Practitioner takeaway: A CI/CD runner is persistent only when it can keep regaining execution, so the decisive question is whether you have removed the attacker’s return path, not just the last observed payload.

Related resources from NHI Mgmt Group

• What are the signs that a CI/CD runner has been abused for secret theft or persistence?
• What should teams do when a CI/CD workflow attempts persistence through runner registration?
• What are the signs that CI/CD runner network monitoring is missing important anomalies?
• What are the signs that a developer workstation or CI runner has been used to steal secrets?