What breaks when outbound network access is not controlled in CI/CD runners?

When outbound access is uncontrolled, malicious workflow steps can reach attacker infrastructure to download payloads or send stolen data out of the environment. That turns a single injection flaw into a broader compromise, because secret theft, cache tampering, and artifact manipulation can proceed without friction. Egress control limits both initial payload retrieval and later exfiltration paths.

Why This Matters for Security Teams

Uncontrolled outbound network access in CI/CD runners changes a build system from a controlled execution environment into a reliable path for command-and-control, data theft, and supply chain tampering. The immediate risk is not just malware download. It is the loss of assurance that a runner can only reach approved services, which weakens secrets handling, artifact integrity, and incident containment in one step. Guidance from NIST SP 800-207 Zero Trust Architecture supports treating every connection as untrusted until explicitly authorized.

Security teams often miss this because CI/CD infrastructure is framed as ephemeral and low-trust by design, yet it still has privileged access to source code, signing keys, package repositories, and deployment targets. If egress is wide open, a compromised job can retrieve payloads, beacon to attacker infrastructure, and move data out with ordinary HTTPS traffic that looks legitimate in logs. In practice, many security teams encounter egress abuse only after secrets have already been exposed or release artifacts have already been altered, rather than through intentional control testing.

How It Works in Practice

Effective egress control starts by defining what a runner is allowed to reach, then enforcing that policy at the network, proxy, or host layer. The goal is to make outbound traffic explicit, observable, and narrowly scoped to the services the pipeline actually needs. That usually includes source control, package registries, artifact storage, time services, and internal APIs, with everything else denied by default. Where runners need broader access, current guidance suggests allowing only documented destinations and logging every exception for review.

In operational terms, teams usually combine several controls:

• Default-deny outbound rules on runner subnets or security groups.
• Proxy enforcement for HTTP and HTTPS traffic, with DNS controls where practical.
• Allowlisting for package mirrors, object storage, signing services, and SCM endpoints.
• Secret retrieval from short-lived identity paths rather than static environment variables.
• Telemetry that correlates runner identity, job context, and destination IP or hostname.

This matters because a compromised workflow step only needs one permitted path to cause damage. If the runner can reach public package sources, an attacker can pull tooling at runtime. If it can reach arbitrary endpoints, exfiltration becomes trivial. If it can contact internal services directly, lateral movement becomes much easier. NIST control guidance on boundary protection and system communications is relevant here, and the broader NHI angle is important because runners behave like non-human identities with standing access that should be governed as carefully as any privileged account. The OWASP Non-Human Identity Top 10 is useful for thinking about how machine identities and their permissions are exposed through automation.

These controls tend to break down when teams share generic runners across many repositories because the network policy becomes too broad to support real workloads.

Common Variations and Edge Cases

Tighter egress control often increases build friction, requiring organisations to balance supply chain protection against developer velocity and brittle dependency patterns. That tradeoff is real, especially in pipelines that fetch many third-party components at build time or depend on dynamic SaaS integrations. Best practice is evolving, but the direction is clear: approve specific dependencies and endpoints rather than assuming open internet access is harmless.

Some environments need special handling. Self-hosted runners in hybrid clouds may require separate policies for private package registries and internal artifact stores. Air-gapped or highly regulated builds may need offline dependency mirrors and pre-approved update windows. In containerized runners, network policy alone is not enough if the job can still pivot through sidecars or shared services. In agentic automation, the risk expands further because tool-using agents may attempt outbound calls that were never part of the original job design, so identity, egress, and tool authorization need to be aligned.

There is no universal standard for every CI/CD topology, but the practical rule is consistent: if a runner does not need the internet, it should not have it, and if it does need access, that access should be narrow, logged, and reviewable.

Related resources from NHI Mgmt Group

• What breaks when privileged access is controlled only at the network layer?
• What breaks when Kubernetes access is controlled only by network location?
• What breaks when internal web access is controlled only through network profiles?
• What breaks when a CI/CD workflow can access secrets from untrusted pull requests?