Any unplanned change in the execution environment of a CI/CD runner, such as added software, modified images, or altered process behaviour. Runner drift matters because workflows inherit the changed state automatically, even when the repository and pipeline definition have not changed.
What runner drift means in CI/CD
Runner drift is not a change in source code or pipeline logic, it is a change in the machine that executes the pipeline. That distinction matters because the runner becomes part of the trusted build and delivery path, so its state directly affects what the workflow actually does.
In practice, drift can come from added packages, altered images, changed environment variables, modified startup scripts, or state left behind by a previous job. Once that environment changes, every later workflow that lands on the same runner can inherit the modified behaviour without any repository commit to explain it.
Why runner drift is security-relevant
Runner drift weakens the assumption that a CI/CD job executes in a known, repeatable environment. It can create hidden differences between build outputs, test results, and deployment behaviour, which makes failures harder to reproduce and trust harder to sustain.
It also expands the attack surface of the delivery system itself. A compromised or tampered runner can alter artifacts, expose secrets, redirect network calls, or change the meaning of otherwise safe pipeline steps. Controls that monitor only repository changes will miss this class of environment-based exposure.
Common ways runner drift appears
Runner drift often starts as convenience. Teams install tools manually, patch images ad hoc, cache state between jobs, or reuse long-lived runners for speed, then treat the resulting environment as if it were disposable and identical across executions.
It can also be introduced indirectly through automation dependencies. Base images, host configuration, injected sidecars, and self-hosted runner maintenance all create opportunities for the runtime environment to diverge from the intended baseline. The problem is not just the change itself, but the fact that the pipeline usually has no built-in awareness that the change occurred.
How to reason about runner drift
The key question is whether the pipeline’s security and correctness depend on the runner remaining immutable between jobs. If they do, then drift is a state-integrity problem, not merely an operations nuisance, because the execution context has become part of the control plane.
That means the practical unit of trust is the full runner image and its runtime state, not only the YAML definition or the repository contents. When those layers are not tightly controlled, the delivery system can appear unchanged while the environment underneath it steadily departs from the baseline.
Risk and Threat Considerations
Runner drift can turn a CI/CD platform into a persistence point. If an attacker gains execution on a runner, they may leave behind tools, modified binaries, altered PATH or shell behaviour, or other state that influences later jobs and survives beyond the original compromise.
Failure mechanism: A workflow inherits the altered runner state automatically, so the attacker does not need to keep modifying the repository or pipeline definition to keep the effect alive. This creates a hidden control failure in environments that rely on shared, long-lived, or self-hosted runners.
Impact: Build integrity, secret handling, and deployment trust can all be undermined. The result may be poisoned artifacts, silent test manipulation, unauthorized access to tokens or credentials, and difficult-to-trace compromise of downstream systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Runner drift is a configuration integrity problem in the execution environment. |
| SI-7 — Software, Firmware, and Information Integrity | Drift can alter runner binaries, images, or startup behaviour and undermine integrity. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting runner drift depends on reviewing and correlating environment changes and job activity. | |
| Recommendation — Enforce approved runner baselines and reset unauthorized configuration changes. Verify runner image and runtime integrity before allowing jobs to execute. Centralize runner telemetry and review configuration changes that affect pipeline execution. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Runner drift is prevented by maintaining and restoring secure configuration baselines. |
| Recommendation — Standardize runner images and remediate unauthorized configuration drift quickly. | ||
| SLSA | Build provenance and integrity | Runner drift threatens the integrity and reproducibility of build and release environments. |
| Recommendation — Isolate build execution and verify artifact provenance across trusted build environments. | ||
Practitioner Guidance
What to watch for: Treat runner drift as a baseline-management issue. The main judgement is whether your runner fleet is genuinely ephemeral and reproducible, or whether it accumulates state that needs explicit detection and reset between jobs.
Practitioner takeaway: The safest pattern is to make runner environments disposable, tightly versioned, and observable, so a job executes in the state you intended rather than the state the previous job left behind.