💡 Native Egress Firewall Policy Standard for CI Runners

[github-actions[bot]]

Summary

Create an org-wide standard for GitHub Actions' upcoming native egress firewall, defining default network allowlists per workflow tier (Tier 1 stubs, Tier 2 per-repo, Tier 3 free), monitor-first rollout procedures, and compliance checks. This prevents compromised actions or agents from exfiltrating secrets to arbitrary endpoints — the core mechanism in the Clinejection and Trivy attacks.

Market Signal

GitHub's 2026 security roadmap announced a native Layer 7 egress firewall for GitHub-hosted runners, operating outside the runner VM (immutable even with root access). Public preview expected in 6-9 months. The Clinejection attack exfiltrated npm/VSCE tokens to attacker-controlled endpoints — an egress firewall would have blocked this exfiltration step entirely. IBM X-Force 2026 reports a nearly 4x increase in supply chain compromises since 2020, with CI/CD credential theft as a primary vector.

The firewall supports dual-mode operation:

• Monitor mode: Audits all outbound traffic, correlated to specific workflow runs, jobs, and steps
• Enforce mode: Blocks traffic not matching explicit allowlists

Organizations can restrict allowed domains, IP ranges, HTTP methods, and TLS requirements.

User Signal

• The org runs multiple agent workflows (dev-lead, feature-ideation, compliance-audit, pr-review) that make external API calls to Anthropic (api.anthropic.com), GitHub API (api.github.com), and npm registries
• Open Scorecard issues (Scorecard: Token-Permissions (7/10) #318 Token-Permissions, Scorecard: Pinned-Dependencies (7/10) #316 Pinned-Dependencies, Scorecard: Branch-Protection (8/10) #313 Branch-Protection) show ongoing security hardening efforts
• Multiple compliance audit cycles demonstrate the org's commitment to security posture improvement
• No existing Ideas discussion covers network-level CI security — this is a genuinely new dimension

Technical Opportunity

The org's centralized reusable workflow architecture means egress policies can be defined once in the reusable workflows and inherited by all downstream repos. The existing ci-standards.md already defines three workflow tiers — egress allowlists map naturally to these tiers:

Tier	Typical outbound targets
Tier 1 (stubs)	api.github.com, api.anthropic.com, registry.npmjs.org
Tier 2 (per-repo CI)	Tier 1 + build-specific registries (Docker Hub, Go proxy, PyPI)
Tier 3 (free)	Defined per-workflow with documented justification

Monitor-mode data collection can start before enforce-mode, using the same compliance-audit framework for reporting.

Assessment

Dimension	Score	Rationale
Feasibility	med	Feature is 6-9 months from preview; standard can be drafted, endpoint inventory can start now
Impact	high	Network-level controls are the most effective layer against credential exfiltration — catches attacks that code-level scanning misses
Urgency	med	Longer timeline to preview, but endpoint inventory work is immediately valuable for threat modeling

Adversarial Review

Strongest objection: The egress firewall is 6-9 months from preview — too distant for a standard now. Also, defining allowlists for agent workflows that call LLM APIs (which may change endpoints) is complex.

Rebuttal: The standard's immediate value is documenting WHICH endpoints each workflow tier should contact — this inventory is useful today for threat modeling even before the firewall exists. Agent workflows already have well-defined API endpoints (api.anthropic.com, api.github.com). Starting the allowlist inventory now means the org is ready to flip to enforce-mode when the feature lands. The monitor-first approach (observe → allowlist → enforce) is explicitly supported by the feature design.

Suggested Next Step

Create a standards/egress-policy.md defining: (1) per-tier default allowlists, (2) monitor-mode data collection procedure, (3) enforce-mode activation criteria, (4) exception request process for new endpoints. Start by auditing all outbound calls in existing reusable workflows.

---

Proposed by BMAD Analyst (Mary) — 2026-06-05T10:43:42Z

[github-actions[bot]]

Weekly Update

What Changed

The Native Egress Firewall preview has been expanded — all users now have access to the firewall runner label in audit mode (GitHub 2026 Security Roadmap).

Key technical details that have emerged:

• Layer 7 firewall operating outside the runner VM — immutable even if an attacker gains root access inside the runner, which is a key advantage over third-party solutions (e.g., Harden-Runner) that operate within the runner itself
• Two operational modes: Monitor (audits all outbound traffic correlated to workflow run, job, step, and initiating command) and Enforce (blocks traffic not explicitly permitted)
• Granular policy controls: Allowed domains, IP ranges, permitted HTTP methods, and TLS requirements
• Correlation: Every outbound request is automatically correlated to the specific workflow run, job, step, and command that initiated it

Additionally, the Actions Data Stream feature (near real-time execution telemetry to Amazon S3 or Azure Event Hub) is on the same roadmap at 6–9 months to GA — this would provide the observability backend for egress policy tuning.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	med	high	↑ Preview expanded to all users; audit mode available for zero-risk adoption
Impact	high	high	→ Unchanged — addresses critical CI network security gap
Urgency	med	high	↑ Audit mode available NOW; enforce mode on roadmap at 6–9 months

Recommendation

Advance. Enable audit mode on one or two non-critical workflows to start collecting baseline egress data. This reveals what external endpoints org workflows actually connect to, which is necessary for writing enforcement policies. The org should define a draft allowlist for its most critical workflows (claude-code-reusable, agent-shield, dev-lead) in preparation for enforce mode.

[github-actions[bot]]

Weekly Update

What Changed

GitHub's native egress firewall technical preview has expanded — all users now have access to the ubuntu-24.04-firewall runner label in audit mode. Key developments:

• Expanded access: The firewall runner label is available to all users, not just enterprise. Any workflow can switch runs-on to ubuntu-24.04-firewall to begin monitoring egress traffic.
• Infrastructure-level protection: The firewall operates at Layer 7 outside the runner VM — root access inside the VM cannot bypass it. This is fundamentally stronger than in-VM solutions like Bullfrog.
• Monitor mode available now: Every outbound request is automatically audited and correlated to the workflow run, job, step, and initiating command. No enforcement needed to start gathering data.
• Policy definition path: Organizations will define policies controlling allowed domains, IP ranges, HTTP methods, and TLS requirements. The recommended rollout is: Monitor → Analyze → Build allowlist → Enforce.
• Part of the 2026 security roadmap: The egress firewall is one of five pillars (alongside workflow dependency locking, scoped secrets, execution protections, and OIDC custom claims) in GitHub's 2026 Actions security roadmap.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	low	med	↑ Technical preview expanded to all users; monitor mode is zero-risk
Impact	high	high	→ Unchanged — network-level CI security is critical
Urgency	low	med	↑ Monitor mode available now; data gathering should start ASAP

Recommendation

Advance — begin monitor-mode pilot on a non-critical workflow. Recommended approach:

1. Switch feature-ideation workflow to ubuntu-24.04-firewall (low risk, runs weekly)
2. Analyze egress logs after 1 week to identify all legitimate outbound destinations (GitHub API, SonarCloud, npm, etc.)
3. Document the discovered allowlist pattern — this becomes the baseline for org-wide enforcement
4. If monitor mode is stable, expand to compliance-audit and canary-rollout for broader traffic profiling
5. Build the enforcement allowlist from real data, not guesswork

The org's canary rollout engine could progressively roll out the firewall label across the fleet, treating it as a runner-level canary promotion.

[github-actions[bot]]

Weekly Update

What Changed

Significant new signal since last update (Jul 17):

1. Audit mode now available to all users (confirmed August 2026): The ubuntu-24.04-firewall runner label is available to all GitHub users in audit mode. Any workflow can switch to this label today to begin logging egress traffic with zero enforcement risk.

2. Layer 7 architecture confirmed: GitHub's documentation confirms the native egress firewall operates at Layer 7 outside the runner VM — making it immutable even if an attacker gains root access inside the runner. This is a fundamental architectural advantage over in-runner solutions (e.g., StepSecurity Harden-Runner) that can be disabled by compromised workflow code.

3. Performance impact quantified: Expect roughly a 15-20% increase in workflow runtime for typical workloads with the firewall enabled. This is a key planning factor for adoption.

4. Configuration model clarified: Organizations define precise egress policies including allowed domains, IP ranges, permitted HTTP methods, and TLS requirements. A monitoring mode lets teams observe traffic patterns and build allowlists before activating enforcement.

5. Supply chain attack escalation continues: The Megalodon campaign (5,561 repos in 6 hours) and TanStack worm (170+ self-propagating packages) demonstrate that CI/CD network-level isolation is no longer theoretical — attackers actively exfiltrate through runners. Network egress controls address this attack class directly.

6. Timeline: Most features in the 2026 security roadmap enter public preview within 3-6 months and GA within 6-9 months from announcement.

Sources: GitHub Actions 2026 Security Roadmap, Native Egress Firewall EA repo

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	med	high	↑ Audit mode now available to all; zero-risk evaluation path confirmed
Impact	high	high	→ Supply chain attacks continue escalating; L7 out-of-VM architecture is best-in-class
Urgency	med	med	→ Enforcement not yet available, but audit-mode data collection should begin now

Recommendation

Advance — Begin audit-mode evaluation on a non-critical workflow (e.g., daily-org-status). The canary rollout system provides a natural phased adoption path: enable ubuntu-24.04-firewall on ring0, collect 7 days of egress logs, document the baseline allowlist, then expand through rings. Building the allowlist now means the org is ready when enforcement mode ships rather than scrambling under deadline pressure.