💡 Egress Firewall Audit-Mode Fleet Trial & Allowlist Bootstrap Standard

[github-actions[bot]]

Summary

GitHub's native egress firewall for Actions runners is now available in technical preview via the ubuntu-24.04-firewall runner label (audit mode). This standard defines a structured fleet trial: systematically switching workflows to the firewall runner in audit mode, collecting egress traffic data, building per-workflow allowlists, and preparing the org for enforcement mode when it arrives — turning an upcoming security feature into a proactive data-gathering exercise.

Market Signal

GitHub expanded its Native Egress Firewall technical preview, granting all users access to the ubuntu-24.04-firewall runner label in audit mode. The firewall operates outside the runner VM at Layer 7, remaining immutable even with root access inside the runner. Every outbound request is audited and correlated to the workflow run, job, step, and initiating command. This is part of GitHub's March 2026 security roadmap, which explicitly targets supply chain attacks through network-level controls.

Sources: GitHub 2026 Security Roadmap, GitHub early-access egress firewall, Wiz blog — hardening GitHub Actions

User Signal

Existing idea #393 proposes an egress firewall policy standard but predates the availability of the audit-mode runner label. The org currently has no visibility into what outbound network connections its CI workflows make — a blind spot exploited by the TeamPCP attack (where compromised scanners exfiltrated credentials to attacker-controlled servers). The org's canary rollout infrastructure provides a natural phased-rollout mechanism for transitioning workflows to the firewall runner.

Technical Opportunity

The trial requires only a runner label change (runs-on: ubuntu-24.04-firewall) — no new tooling, no infrastructure changes. Audit mode logs all egress traffic without blocking anything, making it zero-risk. The collected data feeds directly into allowlist construction. The org's existing standards-deploy infrastructure can systematically roll out the label change across the fleet, and the canary ring system can gate promotion on successful audit-mode operation.

Assessment

Dimension	Score	Rationale
Feasibility	high	Single runner label change; zero-risk audit mode; no new infrastructure required
Impact	med	Data collection phase — provides visibility and builds allowlists, but doesn't block threats until enforcement mode
Urgency	high	Audit-mode runner label is available NOW; data collection should start before enforcement mode arrives

Adversarial Review

Strongest objection: Audit mode doesn't block anything — it's just logging. The value is limited until enforcement mode arrives. And when enforcement does arrive, maintaining per-workflow allowlists could become operationally burdensome.

Rebuttal: The logging IS the value at this stage. Without egress traffic data, the org cannot build informed allowlists and would face a painful, reactive migration when enforcement mode arrives. The TeamPCP attack succeeded partly because no one was monitoring outbound connections from CI runners. Audit-mode data provides immediate security visibility (detecting anomalous connections) even before enforcement. Allowlist maintenance scales with the existing standards-deploy automation — not manual per-repo effort.

Suggested Next Step

Select one low-risk workflow (e.g., compliance-audit or feature-ideation) and change its runner label to ubuntu-24.04-firewall. Run for one week in audit mode, analyze the egress traffic logs, and document the observed domains/endpoints. Use this data to draft a baseline allowlist template and expand to additional workflows via canary ring progression.