💡 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