Security teams should add runtime monitoring and network filtering at the runner image level so controls apply automatically to every workflow that uses that image. The practical goal is to secure persistent and ephemeral runners without rewriting workflow files. Teams should also define authorized destinations and review alerts from past runs so allowlists stay aligned with real build traffic.
Why runner-image controls are the safest way to protect self-hosted VM runners
Self-hosted VM runners are useful because they keep jobs close to internal networks, caches, and build dependencies, but that same proximity makes them risky if controls live only in workflow YAML. The safer pattern is to bake monitoring and network rules into the runner image so every job inherits the same baseline without editing each pipeline. That reduces drift and keeps developer workflows stable.
For teams running long-lived runners, image-level controls also avoid the common trap of treating each repository as a separate security project. A consistent image makes it easier to prove what every runner can see, log, and reach, which matters when jobs reuse the same host over time. For ephemeral runners, the same model helps ensure each instance starts from a known-good state instead of inheriting local exceptions.
How to keep build jobs working while restricting runner egress
The practical challenge is not simply blocking traffic, it is allowing only the destinations that builds truly need. Start by defining authorized package registries, source control endpoints, artifact stores, secrets services, and any internal APIs the runner must reach. Then compare those allowlists against real job traffic so you do not break restores, scans, uploads, or deployment steps.
Network filtering works best when it is paired with review of past runs, because build traffic often expands over time as new tools are added. A runner that was originally used for compilation may later need container registries, vulnerability scanners, or artifact promotion paths. If those changes are not reflected in the host controls, teams either get outages or quietly weaken the filter to make jobs pass.
If you need a supply-chain lens for the integrity side of the problem, SLSA is a useful reference point for build provenance and controlled build environments. For host hardening, the same runner-image approach aligns well with NIST Cybersecurity Framework 2.0 and the operational safeguard model in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where configuration baselines, logging, and access restriction matter.
What usually breaks and how to keep the control low-friction
Most failures come from overfitting controls to one repository or one workflow. If the enforcement point is inside the workflow file, every exception has to be managed by developers, which leads to duplication and inconsistent security posture. If the enforcement point is on the runner image, the control is harder to bypass and easier to update centrally.
What to verify: confirm that the runner image is the place where monitoring, network filtering, and any host-level telemetry are actually enforced, not just documented. Also confirm that the filter allows only the minimum stable set of destinations and that alerting distinguishes normal build chatter from unexpected outbound access.
What to measure: track how often jobs fail because of blocked destinations, how often allowlists change, and whether repeated alerts point to a missing dependency versus suspicious activity. The goal is not zero alerts, it is a small, explainable set of approved destinations that matches real pipeline behavior.
Risk and Threat Considerations
Self-hosted runners are attractive to attackers because they can sit close to source code, credentials, and internal services while still being triggered by ordinary CI activity. If outbound access is broad or if host controls are inconsistent, a compromised workflow or malicious dependency can exfiltrate data, call back to an external server, or pivot into internal systems.
Failure mechanism: the runner inherits too much network reach or too many local privileges, then a build step, third-party action, or injected dependency abuses that reach before defenders notice. When enforcement exists only in workflow logic, an attacker can often sidestep it by using a different job path or by waiting for a less controlled repository.
Impact: secrets leakage, build tampering, repository compromise, and lateral movement from the CI environment into adjacent infrastructure become more likely. In practice, the blast radius is determined less by the job itself and more by how much the runner image can see, reach, and persist.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Runner egress and host reach should be limited to approved build destinations. |
| DE.CM-7 — Monitoring for Unauthorized Connections | Runtime monitoring on runners helps detect unexpected outbound activity. | |
| Recommendation — Constrain runner access to only the services required by the build. Monitor runner network activity for unexpected connections and alert on anomalies. | ||
| CIS Controls v8 | 6.3 — Define and Maintain an Inventory of Authorized Assets | Runner images and authorized destinations need a maintained baseline to avoid drift. |
| 12.4 — Establish and Maintain an Inventory of Network Ports, Protocols, and Services | Allowlisting runner traffic depends on knowing which ports and services jobs truly need. | |
| Recommendation — Maintain an approved inventory of runner hosts, images, and required destinations. Document and restrict the ports, protocols, and services a runner may use. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Compromised workflows or actions can abuse trusted CI runners and build paths. |
| T1105 — Ingress Tool Transfer | Malicious jobs often fetch external payloads or tools from runners with broad egress. | |
| Recommendation — Hunt for compromised build inputs and validate the integrity of actions and dependencies. Detect unexpected runner downloads and restrict outbound transfer paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Self-hosted runners often handle build credentials that must stay tightly controlled. |
| NHI-03 — Overprivileged Non-Human Identities | Runner identities and build access should be minimized to reduce blast radius. | |
| Recommendation — Store runner-used secrets centrally and restrict their exposure to the smallest viable scope. Reduce runner privileges and remove unnecessary access to internal services. | ||
| NIST AI RMF | GV-2 — AI Risk Management Culture | No AI-specific control is central here, but governance-style risk review of automated build runners is material. |
| Recommendation — Establish governance for automated runner exceptions, review, and escalation. | ||
Practitioner Guidance
What to prioritise: put the control at the runner image and host layer first, then tune egress rules from actual build telemetry. That sequence gives you a stable baseline before you start negotiating exceptions with application teams.
Decision rule: if a destination is required by a repeatable build step, add it to the runner baseline and document why; if it appears only occasionally, treat it as an exception worth reviewing before broadening access. This keeps pipeline reliability from becoming a pretext for overly permissive networking.
Common mistake: teams often allowlist by habit rather than by evidence, then discover that the runner can reach far more than the pipeline needs. The better test is whether the control would still make sense if the workflow file were replaced tomorrow.
Practitioner takeaway: secure the runner once, centrally, and make the pipeline inherit that protection, because the least disruptive control is the one developers do not have to remember to apply in every workflow.
Related resources from NHI Mgmt Group
- How should security teams secure self-hosted GitHub Actions runners in Kubernetes without losing delivery speed?
- How should security teams protect GitHub Actions jobs running on AWS CodeBuild-hosted runners?
- How should security teams secure GitHub Actions runners without exposing internal services to the public internet?
- How should security teams secure Hugging Face workflows when model files, repositories, and pipeline jobs are all part of the delivery chain?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
