Unrestricted egress creates an exfiltration path during the build phase and makes compromise harder to detect. A malicious dependency or injected script can phone out during execution, move data off the runner, or trigger unapproved interactions that never appear in source control. The control failure is not just network openness, but loss of enforceable build-time trust.
Why open egress breaks build-time trust
When a runner can reach any external domain, the build environment stops being a controlled execution space and becomes a potential exfiltration point. That matters because CI/CD systems often process source, secrets, artifacts, and dependency code together, so outbound traffic can become the easiest way to leak data or contact attacker infrastructure without changing the repository itself.
The main failure is not just “the internet is reachable.” It is that the pipeline can no longer prove which external interactions were legitimate, which dependency behavior was expected, or whether a build step silently crossed a trust boundary during execution.
In practice, unrestricted egress weakens the trust model for dependency installation, script execution, artifact generation, and test-time instrumentation. If a malicious package or injected script runs, it can make outbound calls, stage stolen material, or pull in secondary payloads that never appear in source control but still alter the build outcome.
What attackers can do with runner internet access
Open outbound access gives an attacker several low-friction options once code executes on the runner. A dependency can phone home, a workflow step can fetch additional instructions, and a compromised action can beacon out secrets, logs, environment variables, or short-lived tokens before the job completes.
That same access also supports stealth. A build may succeed while quietly leaking data in parallel, because the sensitive action happens during execution rather than in a committed file diff. For that reason, build-time compromise is often harder to spot than repository tampering, especially when the runner is allowed to talk to arbitrary hosts.
See how this pattern appears in real supply-chain incidents such as reviewdog Action compromise 2025, where poisoned CI steps exposed secrets, and the tj-actions/changed-files compromise 2025, where malicious workflow behavior turned secret access into broad leakage.
Open egress also increases the blast radius of dependency abuse. A package with a postinstall hook, a compromised action, or a malicious test fixture does not need local persistence if it can immediately transmit data out of the runner or retrieve follow-on code from an external location.
What controls matter when outbound traffic is the problem
The effective control is not simply “block the internet,” but make outbound access explicit, observable, and narrowly justified. That means separating dependency fetches from arbitrary egress, restricting which domains the runner can reach, and treating any unexpected destination as a control failure rather than normal build noise.
Build pipelines are strongest when outbound destinations are pre-approved for the exact job type, because then any deviation becomes a detectable event. That is especially important for hosted runners and ephemeral environments, where the window for abuse is short and the best defense is to prevent uncontrolled network paths from existing in the first place.
Projects that rely on signed artifacts, pinned dependencies, and trusted publishing should align those protections with network restrictions so the runner cannot freely contact unvetted infrastructure. The operational goal is to reduce both silent exfiltration and unauthorized follow-on execution, not merely to shrink the list of allowed URLs.
For a broader control pattern, SLSA is useful because build provenance and controlled build inputs only work well when the runner itself is not free to reach arbitrary external services during execution.
Risk and Threat Considerations
Unrestricted egress turns the runner into a convenient bridge between trusted internal build context and untrusted external infrastructure. That creates exposure for secrets, source, artifacts, and internal metadata, while also giving adversaries a low-noise path to move data out during the narrow build window.
Failure mechanism: A compromised dependency, injected script, or malicious workflow step uses outbound network access to exfiltrate data, fetch secondary payloads, or communicate with attacker-controlled infrastructure without altering the repository history.
Impact: Secrets can be stolen, build integrity can be undermined, and compromise becomes harder to detect because the malicious action occurs inside a normal-looking pipeline execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and controlled inputs are central when runner egress can be abused during builds. |
| Recommendation — Constrain build steps and provenance so the runner cannot contact arbitrary external services during execution. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Outbound filtering and segmentation directly address arbitrary runner egress to unapproved domains. |
| AU-12 — Audit Record Generation | Unexpected outbound calls need logging to detect exfiltration from build jobs. | |
| Recommendation — Restrict runner egress to approved destinations and log unexpected connections. Generate and retain logs for build-time outbound connections and policy violations. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Network control and allowlisting are the core operational response to uncontrolled runner egress. |
| Recommendation — Apply network restrictions so CI/CD runners can reach only approved external destinations. | ||
Practitioner Guidance
What to verify: Confirm which jobs truly need external access, then test whether the runner can reach only those destinations and protocols. If a build can complete without arbitrary outbound connectivity, treat open egress as avoidable risk, not an operational convenience.
Decision rule: If the runner handles credentials, private source, or signed release material, prioritize egress allowlisting and destination logging before you rely on source review alone. If a step must contact the internet, isolate that step so it cannot see more data than necessary.
What good looks like: Approved build paths are explicit, unexpected destinations are visible, and a job that tries to phone out beyond policy is observable as an exception rather than invisible background traffic.
Practitioner takeaway: The real control question is whether the runner can contact only the external systems the build explicitly needs. If it can reach anything, then compromise, dependency abuse, and secret theft all gain a clean exit route.