TL;DR
When using the native egress path, GitHub Actions runners have no destination policy, and no logging.
Two real attacks (March 2025 and March 2026) exfiltrated secrets through trusted pipelines that no scanner flagged in time.
Static IP addresses on runners control where traffic comes from, not where it goes. They do not solve this problem.
Phase 1 of the Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines enforces default-deny egress at the network layer for self-hosted runners in VPC/VNET, available now.
Phase 2 extends coverage to Actions Runner Controller (ARC) on Kubernetes and introduces a VPN overlay for GitHub-hosted agents with per-repository network identity.
On self-hosted and Kubernetes deployments, enforcement is outside the runner’s trust boundary - a compromised action cannot disable it.
In March 2025, attackers compromised tj-actions/changed-files, a GitHub Action used by more than 23,000 repositories. The payload dumped runner memory and exfiltrated secrets, personal access tokens (PATs), and cloud credentials to an attacker-controlled server. CISA issued an emergency advisory.
One year later, in March 2026, the TeamPCP group compromised Aqua Security’s Trivy vulnerability scanner. The payload harvested SSH keys, AWS, Google Cloud Platform (GCP), and Azure tokens, Kubernetes secrets, and Docker configs, then cascaded into Checkmarx, LiteLLM, and more than 60 npm packages. Over 10,000 CI/CD workflows were affected.
In both attacks, the exfiltration destination was a server that no legitimate CI pipeline would ever need to reach. If those runners had been configured with network egress control, the stolen credentials would have had nowhere to go.
This is the problem: when using the native egress path, GitHub Actions runners operate without egress governance. Every runner, including Larger Runners with static IPs, can send traffic to any destination on the internet. There is no destination policy and no per-connection logging. A compromised dependency, a malicious Action, or a supply chain attack can phone home and there is nothing to stop it.
Static IPs make this worse because they give organizations a false sense of control. Static IPs govern where traffic comes from. They do nothing to govern where it goes. A runner with a static IP can exfiltrate to a malicious domain just as easily as one without.
Introducing Validated Containment Architecture for Enterprise GitHub Pipelines
Aviatrix Validated Containment Architectures are lab-tested, ready-to-deploy blueprints that provide containment architectures for specific enterprise platforms. They offer default-deny, network-level enforcement of security policies that prevents the data exfiltration enabled by supply-chain attacks. In a time when threats are moving too fast to detect in time, containment can prevent a catastrophic breach.
The Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines puts network-layer egress control on GitHub Actions runners across two phases, built on Aviatrix Distributed Cloud Firewall (DCF).
Phase 1: Self-Hosted Runners (Available Now)
For self-hosted runners on VMs, the runner sits in a private subnet with no public IP. When the Aviatrix Spoke Gateway is deployed, it automatically updates the subnet route table to direct all default egress traffic to its network interface - runners immediately have no path to the internet except through the gateway. There is no software process on the runner that a compromised action could kill to bypass enforcement. Network-level enforcement, zero bypass risk.
DCF WebGroups provide FQDN-based default-deny egress policy per runner group using L7 filtering, allowing pypi.org and github.com while blocking everything else. URL-level filtering can scope policy further to specific URLs rather than entire domains. For environments requiring deeper assurance, Aviatrix can terminate TLS at the Spoke Gateway to inspect payload content on permitted connections, enabling detection and blocking of data exfiltration even when the destination domain is allowed.
Phase 2: ARC on Kubernetes and VPN Overlay for GitHub-Hosted Agents (In Development)
Phase 2a extends the same enforcement model to Actions Runner Controller (ARC) pods on Kubernetes (EKS or AKS). The cluster VPC or VNet attaches to an Aviatrix Spoke Gateway and pod egress routes through it at the node subnet level. DCF SmartGroups match runner pods by namespace and label selectors; WebGroups enforce FQDN-based default-deny policy per runner group using L7 filtering. Enforcement is at the VPC boundary, entirely outside the Kubernetes trust boundary.
Phase 2b introduces a VPN overlay specifically for GitHub-hosted agents, paired with the Egress Identity Service - a GitHub App that provisions a dedicated VPN identity per repository. When a workflow runs on a GitHub-hosted agent, a lightweight VPN overlay agent establishes a tunnel through the Aviatrix Spoke Gateway scoped to that repository’s identity. The gateway enforces only the permit rules defined for that specific repository, tightly scoped to its actual egress needs. A payments pipeline cannot reach domains permitted only for a documentation builder, even when both run on the same infrastructure. All tunnel traffic is subject to full DCF inspection, and repository identity is preserved in every connection log.
The key difference between the VPN overlay on GitHub-hosted agents (Phase 2b) and the self-hosted/ARC architecture (Phase 1 and Phase 2a) is where enforcement happens. On GitHub-hosted agents, the VPN overlay runs inside the agent’s trust boundary; a compromised action with root access could theoretically terminate it. On self-hosted runners and ARC pods, enforcement is at the VPC boundary, outside the runner entirely. A compromised package cannot reach the internet except through the gateway, and the gateway enforces what it can reach.
Notes from the Lab: A Detailed Look
For security architects, platform engineers, and other security practitioners, here’s the technical overview of how this Validated Containment Architecture works:
Default-deny egress at the Spoke Gateway
The Spoke Gateway sits in-path for all runner egress. DCF evaluates every outbound connection before it leaves the VPC. Approved destinations, such as package registries and version control hosts are explicitly permitted by WebGroup. Everything else is denied and logged. This matters because it removes the attacker’s exit path regardless of how the runner was compromised.
FQDN-based filtering with L7 enforcement closes the gap SNI allowlisting misses
A critical detail from some attacks: they might use destinations that looked legitimate at the domain level. Raw domain allowlisting would not have stopped them. Aviatrix DCF adds URL-level enforcement with selective TLS decryption scoped to specific supply-chain hosts. A compromised path on raw.githubusercontent.com can be blocked while legitimate paths on the same domain return normally. This is the control that pure SNI filtering cannot provide.
Per-connection logging resolved to domain names
CoPilot logs every allowed and denied connection with source identity, destination FQDN, and timestamp. This is qualitatively different from IP-level logs. When a pipeline makes an unexpected connection, you see the domain name in the log, not an IP address you have to reverse-look up. For incident response, this compresses triage time significantly.
Zero bypass risk on self-hosted and ARC deployments
The self-hosted and ARC architectures enforce at the VPC boundary. The runner has no public IP and no alternate path to the internet. There is no VPN process to kill, no iptables rule to modify inside the runner VM. A compromised action that tries to exfiltrate data will route through the gateway, hit the DCF default-deny rule, be blocked, and be logged. This architectural property is what separates network-infrastructure enforcement from in-runner enforcement tools.
Progressive rollout without breaking pipelines
The Phase 1 rollout uses GitHub’s own enforcement mechanisms. Start by deploying the Spoke Gateway in a non-production runner VPC - the gateway automatically handles routing and runners gain immediate egress visibility in CoPilot without policy enforcement. Add DCF WebGroups in monitor mode to baseline normal traffic patterns before switching to enforce mode. Required workflow rulesets can be deployed in “Evaluate” mode first, giving visibility into which pipelines would be affected before any enforcement is activated. Runner groups let organizations segment controlled pipelines from migrating ones. A typical rollout from opt-in to full enforcement for an organization with fewer than 500 self-hosted runner nodes takes two to four weeks.
Conclusion
The attacks on CI/CD pipelines are not going to stop. Supply chain compromise through trusted build tools, trusted Actions, and trusted registries is the attack pattern that the detection era cannot reliably stop, because trusted code does not look suspicious. Containment architecture applies a different answer: default-deny egress at the network layer means that even if a pipeline is compromised, the stolen credentials have nowhere to go.
Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines brings that enforcement to your runner fleet in two phases. Phase 1 — self-hosted runners in VPC/VNET — is available now, with zero bypass risk and no changes required to pipeline code. Phase 2 extends coverage to ARC on Kubernetes and introduces per-repository VPN identity for GitHub-hosted agents — the same Distributed Cloud Firewall fabric that governs your production workloads, AI agents, and MCP servers. One policy model. One audit log. One control plane.
Ready to see it in your environment? Request a 30-minute architecture review and we will map your current runner fleet, identify uncontrolled egress paths, and show you exactly where enforcement goes.
Explore other Validated Containment Architectures for AI platforms.
Frequently Asked Questions
Static IPs control the source address of runner traffic. They let you add an IP allowlist on internal firewalls so only your CI system can reach internal services. They do nothing to restrict or log what the runner sends outbound. When using the native egress path, a runner with a static IP can exfiltrate credentials to any attacker-controlled domain just as easily as one without. Source IP and destination policy are completely separate controls. Aviatrix governs the destination: what the runner can reach, enforced and logged at the network layer.
It depends on the deployment model. On GitHub-hosted agents using the Phase 2b VPN overlay, a compromised action with root access could theoretically terminate the VPN process. Hardening options include restricting the gateway’s security group to accept connections only from known runner IPs and monitoring VPN disconnect events in CoPilot. For zero bypass risk, Phase 1 self-hosted runners on VMs or Phase 2a Actions Runner Controller (ARC) pods on Kubernetes with VPC-level routing provide network-layer enforcement that a compromised action cannot circumvent — the runner physically cannot reach the internet except through the gateway.
StepSecurity, Bullfrog, and similar tools enforce egress filtering inside the runner’s trust boundary using DNS hooks or kernel-level techniques. A compromised action with root access can potentially kill or bypass these agents. Aviatrix’s Phase 1 self-hosted and Phase 2a ARC architecture enforces at the VPC boundary, outside the runner entirely. Additionally, Aviatrix integrates CI/CD egress policy with the same Distributed Cloud Firewall fabric governing production workloads, AI agents, and MCP servers, giving a single policy model and unified CoPilot visibility across all automated workloads.
For Phase 1 self-hosted runners on VMs, enforcement is at the VPC routing level and requires no workflow changes at all — the Spoke Gateway automatically updates the route table on deployment. For Phase 2a ARC on Kubernetes, the Aviatrix Kubernetes Firewall Helm chart handles policy enforcement without application changes. For Phase 2b GitHub-hosted agents, adding egress control requires one line in the workflow file to invoke the VPN overlay agent. All three deployment paths are designed to be transparent to developers.
Aviatrix Validated Containment Architecture for Enterprise GitHub Pipelines directly supports SOC 2 (least-privilege access and audit logging for CI/CD systems), HIPAA (network segmentation for pipelines handling protected health information), PCI-DSS (restricting outbound traffic from in-scope environments), FedRAMP (continuous monitoring and least-functionality requirements), and the NIST Secure Software Development Framework (SSDF), which explicitly calls for protecting CI/CD infrastructure from unauthorized access and data exfiltration. DCF WebGroup and SmartGroup configurations are Terraform-managed infrastructure-as-code — policy ships in the same repository as deployment manifests, reviewed in the same PR, providing an auditable approval trail.
