When the runner changes underneath the workflow, pre-run review no longer matches what actually executes. That breaks trust in image provenance, makes outbound traffic harder to explain, and can hide unwanted software or configuration drift until it affects build behaviour or security monitoring.
What changes when the runner is no longer the one you reviewed?
The core failure is a trust gap between review and execution. A GitHub Actions workflow can look acceptable at code review time, yet run on a different runner image, host configuration, or software stack by the time the job starts. That means the security properties you approved are not the ones actually present during execution.
For build and release pipelines, that is not a cosmetic issue. Runner drift can change preinstalled tools, network reachability, persistence behaviour, logging, and the way credentials are exposed or consumed. When those conditions move underneath the workflow, you no longer have a stable basis for provenance, reproducibility, or operational assurance.
That is why runtime changes in CI environments are often treated as a supply-chain integrity problem rather than a convenience problem. GitHub Actions is only one example of the broader CI/CD class, and a CI/CD Pipeline Identity Security Guide is useful because it frames runner trust as part of the overall control plane for builds, secrets, and signing.
Which parts of the workflow become unreliable?
Several assumptions weaken at once. First, image provenance becomes harder to trust because you can no longer assume the executed environment matches the reviewed environment. Second, outbound traffic is harder to explain because a changed runner may have different egress routes, preloaded agents, package caches, or network tools. Third, hidden software or configuration drift can appear only after it affects build behaviour, artifact contents, or security monitoring.
This is especially important when the workflow relies on implicit environment state, such as preinstalled CLIs, shell defaults, runtime tokens, or cached dependencies. If the runner mutates without notice, the workflow may still “pass” while silently using a different trust boundary than the one the team intended.
For hosted runners and ephemeral build environments, the practical question is not whether the code still compiles. It is whether the execution context remains observable and bounded enough that review, logging, and artifact checks still mean something. A NIST SP 800-190 Container Security reference is helpful here because it treats image, runtime, and deployment integrity as separate but connected assurance concerns.
Why does this matter for provenance and tamper detection?
When the runner changes underneath the workflow, provenance breaks before the build visibly fails. The pipeline can still emit an artifact, but the chain of custody is weaker because the reviewed job no longer maps cleanly to the executed environment. That makes it harder to trust whether the artifact came from the expected runner image, toolchain, or execution policy.
It also raises the cost of incident investigation. If a build output looks wrong, teams must now ask whether the cause was malicious modification, benign image rotation, package drift, a new runner baseline, or a transient platform change. The more frequently the runtime changes without notice, the less meaningful “same workflow” really is as an assurance statement.
For that reason, teams that care about provenance should treat runner identity and runner image version as auditable inputs to the build record. Where token delegation is involved, RFC 8693: OAuth 2.0 Token Exchange is a relevant model for thinking about how authority is delegated into ephemeral execution contexts without assuming the context itself is stable.
Risk and Threat Considerations
Unannounced runner changes create an attractive attack condition because they blur the boundary between trusted review and trusted execution. An attacker does not always need to alter the workflow file if they can influence the runtime image, preinstalled tooling, or network-visible behaviour of the runner.
Failure mechanism: the workflow is approved against one environment, then executes in another, so hidden changes in the runner can alter credential exposure, command behaviour, artifact content, or outbound connections without a corresponding review event.
Impact: teams can lose build integrity, miss malicious or unwanted software drift, and misread security telemetry because the execution context itself has become an untracked variable.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Runner drift is a change-control problem that affects trusted execution state. |
| CM-6 — Configuration Settings | Unnoticed runner changes are configuration drift that breaks execution assurance. | |
| AU-12 — Audit Record Generation | The question depends on being able to explain what actually ran during the workflow. | |
| Recommendation — Restrict and approve runner image changes before they alter trusted build execution. Baseline and monitor runner configuration so runtime drift is detected quickly. Generate audit records that identify the runner image and runtime used for each job. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Unexpected runner mutation is a secure-configuration failure in the build environment. |
| Recommendation — Lock down and continuously validate runner baselines and software state. | ||
Practitioner Guidance
What to verify: Confirm that the runner image, version, and baseline configuration are either pinned or explicitly recorded for every build that matters. If you cannot later prove which runtime executed the job, treat the build as lower trust even if it succeeded.
Common mistake: assuming workflow review is enough when the real control failure is runtime variance. Review protects the YAML, but it does not protect against a moving execution substrate unless the runner identity and image are controlled with the same discipline.
What good looks like: builds run on known runner baselines, unexpected drift is detectable from logs or attestation, and outbound behaviour can be explained from the approved execution environment rather than guessed after the fact.
Practitioner takeaway: In CI, the security question is not only whether the job definition was reviewed, but whether the thing that actually ran can still be trusted to represent that review.
Related resources from NHI Mgmt Group
- Why do third-party GitHub Actions runners increase the need for runtime security?
- What breaks when GitHub Actions runners do not have egress monitoring?
- What breaks when GitHub Actions workflows are allowed to access secrets without approval?
- What breaks when GitHub Actions are allowed to authenticate without tight repository and branch controls?