Non-ephemeral runners preserve state between jobs, which lets malicious code or stolen secrets survive longer than a single build. That persistence can turn a one-time pull request or workflow run into ongoing access, enabling secret theft, lateral movement, and tampering with build images. Clean, isolated execution sharply reduces the attacker’s ability to reuse footholds.
Why Persistent Runners Change the Security Model
Non-ephemeral self-hosted runners are risky because they turn a build host into a reusable execution environment rather than a disposable one. Once a job has run, any artefacts left behind on disk, in memory, in caches, or in local tooling can influence the next job that lands on the same runner. That matters for CI/CD because the runner is not just performing work, it is often exposed to source code, build scripts, package feeds, signing material, and deployment credentials. A useful baseline for thinking about this kind of operational exposure is the NIST Cybersecurity Framework 2.0, which emphasises governance, protection, detection, and recovery across shared technology environments. In practice, many security teams discover the problem only after a single compromised workflow has already left behind something the next job can reuse.
How the Compromise Persists Across Jobs
The core weakness is state retention. Ephemeral runners are designed to be short-lived, so each job starts from a clean condition and any compromise dies with the instance. Non-ephemeral runners keep operating across multiple jobs, which creates a wider window for abuse. If a malicious pull request, poisoned dependency, or compromised build step can write to the runner, it may be able to leave files, alter local configuration, plant tooling, or capture credentials that later jobs will trust.
This persistence is especially dangerous when the runner has access to secrets, deployment tokens, or privileged cloud credentials. A stolen secret does not need to be used immediately if the attacker can wait for a later job to expose it again. Likewise, build tampering becomes easier when an attacker can modify cached artefacts or shared workspace state and influence downstream images or packages. That is why runners should be treated as part of the attack surface, not as neutral plumbing.
- Residual files can leak code, tokens, or signed artefacts into later jobs.
- Local configuration changes can redirect tooling or weaken validation steps.
- Cached dependencies can be poisoned and reused without obvious warning.
- Reusable credentials can extend access long after the original job ends.
When the runner is reused, the attacker only needs one successful foothold to benefit from multiple later executions, and that is where the guidance starts to break down if organisations assume each job is isolated by default.
Where the Risk Becomes Material in Real Pipelines
Tighter runner sharing often improves efficiency, but it also increases the burden on hygiene, segregation, and monitoring. The risk is highest when the same runner handles untrusted pull requests, protected branch builds, and deployment workflows, because trust boundaries collapse into one execution surface. It also rises when secrets are broadly available, when caches are retained for speed, or when runner images are modified manually rather than rebuilt from a known baseline.
Not every non-ephemeral runner is equally exposed. A hardened long-lived runner with strict job scoping, minimal secrets, aggressive log review, and frequent reimaging is safer than an unmanaged host that processes mixed-trust workloads. The industry broadly agrees on the benefit of isolation, but there is less consensus on how much reuse is acceptable in high-throughput pipelines; the answer depends on how much state survives and how sensitive the jobs are. For teams designing controls, the important question is not whether the runner is self-hosted, but whether any job can influence the next one in a way that bypasses expected trust boundaries.
Non-ephemeral runners are most dangerous when convenience, speed, and shared trust outrun the organisation’s ability to reset the environment after each job.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Persistent runners need hardened, resettable baselines to prevent state carryover. |
| CIS Control 6 — Access Control Management | Shared runners widen exposure when secrets and privileged access persist across jobs. | |
| CIS Control 8 — Audit Log Management | Persistent compromise is easier to miss without strong job and host auditing. | |
| Recommendation — Harden runner images and verify they return to a known-good state between jobs. Restrict runner access paths and remove privileges that outlive a single workflow. Log runner changes and review evidence of cross-job state reuse. | ||
| NIST CSF 2.0 | PR.AC — Access Control | CI/CD runners are shared execution surfaces where trust boundaries must be enforced. |
| PR.DS — Data Security | Residual secrets, artefacts, and caches on runners create data exposure risk. | |
| DE.CM — Continuous Monitoring | Persistent runners require monitoring to detect tampering that survives across jobs. | |
| Recommendation — Segment runner trust zones so untrusted jobs cannot influence privileged workflows. Protect and clear sensitive build data before the next job can access it. Monitor runner integrity for changes that persist beyond one execution. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Runner persistence can enable tampering with build outputs and downstream artefacts. |
| Recommendation — Hunt for build-path tampering and artefact manipulation in shared CI/CD hosts. | ||
Practitioner Guidance
What to prioritise: Treat runner reuse as a trust problem first and a performance optimisation second. The highest-value control decision is whether untrusted code and privileged workflows ever share the same execution host or persistent workspace.
What to verify: Confirm that caches, workspace directories, tool configuration, and secret material are actually cleared or rotated between jobs. If the pipeline cannot prove those resets, assume the runner can carry compromise forward.
Decision rule: If a runner ever processes public pull requests, third-party contributions, or high-privilege deployment steps, use strict isolation or equivalent teardown controls rather than relying on post-job cleanup alone.
Common mistake: Teams often harden the runner image but leave the reuse model unchanged. A strong baseline helps, but it does not fix persistence if the next job inherits the previous job’s state.
Practitioner takeaway: The real question is not whether the runner can be secured once, but whether it can be trusted again after untrusted code has already touched it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
