配了三年 GitHub Actions，今天才发现运行时的出口一直是敞开的——出口防火墙把这件事彻底变了

npm install 能在 CI 里访问任何服务器，curl 一个命令就能把 Runner 里的密钥传到外面去——这件事我一直以为是 OIDC 和 Secret 作用域在管，但它们只管「谁可以进来」，从来不管「代码可以出去」。GitHub Actions Native Egress Firewall 把这道口子彻底堵上了，而且它跑在 Runner 外面，拿到 root 权限也绕不开它。

为什么这件事一直是盲区

GitHub Actions 安全模型里，OIDC 去掉了长期凭证，Secret 作用域收紧了权限范围，SHA pinning 锁住了依赖版本——但它们全是「里」的控制。没有任何一个机制说 npm install 只能访问 registry.npmjs.org，curl 可以访问任意地址这件事从来没被管过。

2025 年初 tj-actions/changed-files 那次攻击就是例子：攻击者重定向了一个流行 Action 的版本标签，恶意代码在几千个仓库的 CI 里跑起来，把 Runner 内存里的 Secrets 直接写进了 Actions 日志。日志没出 GitHub，但试想如果那个 Runner 能访问外网——一个 curl 就能把密钥送到攻击者服务器上。

这就是 Egress（出口）盲区：代码在 CI 里执行，拥有 Secrets 访问权限，还拥有完整的网络出口，而这三件事从来没有被放在一起管过。

它和以前的方案有什么不同

社区里早就有方案，比如 StepSecurity 的 Harden-Runner 和 Bullfrog。它们以 GitHub Action 的形式跑在 Runner 内部，在进程层面拦截网络调用。拿到 root 之后，理论上可以禁用或绕过那个进程。

GitHub 的 Native Egress Firewall 不一样。它跑在 Runner 虚拟机外面，走 Layer 7，在网络基础设施层面拦截流量。Runner 里跑的任何代码——包括拿到 root 的代码——都在它的下游，根本碰不到防火墙本身。

这个区别就是整个方案的核心：它防的不是「坏人进不来」，而是「坏人在里面也出不去」。

怎么启用

技术预览阶段只要改一行 YAML：

jobs:
  build:
    runs-on: ubuntu-24.04-firewall
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

不需要装 Action，不需要配 Secret，不需要改工作流结构。在 workflow 文件里把 runner 标签从 ubuntu-latest 换成 ubuntu-24.04-firewall，审计就开始了。

当前是审计模式（Audit Mode）：所有出口流量都会被记录并关联到对应的 workflow、job、step 和触发命令，但什么都不阻止。性能损耗大约 15–20%，主要来自虚拟机的流量监控。

未来是执行模式（Enforce Mode）：定义允许列表（Allowed Domains、IP 范围、HTTP 方法、TLS 版本要求），列表外的所有流量直接被拦截。GitHub 的建议是先跑审计模式，收集真实流量数据，建立允许列表，再切执行模式——这个顺序不能乱。

HTTPS 检查怎么做的

URL 级别的过滤需要看到明文 HTTPS 目标地址，但流量本身必须保持私密。GitHub 的方案是：在出口边界终止 TLS，用每个 workflow run 的唯一临时证书重新加密。Run 结束时证书销毁。

如果你的 workflow 信任操作系统证书存储（curl、git、npm、pip、docker 默认都信任），看到的就只是正常的 HTTPS 连接，不需要改任何代码。如果做了证书固定或 mTLS，需要把临时证书加进信任链。

它在整个安全体系里扮演什么角色

GitHub 2026 安全路线图分三层：

第一层： Ecosystem（依赖确定性）

依赖锁定（Workflow Dependency Locking）在 YAML 里加 dependencies: 区块，把每个 Action 及其传递依赖用 SHA 固定，类似 go.mod + go.sum。改了依赖会在 PR 里出现 diff，SHA 对不上直接不跑。这层防止恶意代码进来。

第二层： Attack Surface（攻击面收窄）

Scoped Secrets 把凭证绑定到具体执行上下文：特定仓库、特定分支、特定环境或特定 reusable workflow。可信边界从「谁都能用」变成「只有显式授权的才能用」。Policy-Driven Execution 把「谁能触发 workflow」这件事从散落在各处的 YAML 配置里提到组织层面，一个 ruleset 全管。

第三层： Infrastructure（基础设施可见性与边界）

Actions Data Stream 把 CI 执行遥测实时推到 S3 或 Azure Event Hub，让 SIEM 团队把 CI/CD 当生产系统一样监控。Egress Firewall 在网络层卡死出口，即使恶意代码跑起来、找到了 Secrets，也无法传输出去。

三层各管一段，Egress Firewall 是最后一环：即使前面两层都被绕过，这层把数据外传的通道堵死。

现在要不要上车

技术预览已经开放，审计模式对所有用户可用，不需要申请。

建议现在就把至少一个关键 workflow 切到 ubuntu-24.04-firewall，先跑两周审计模式，收集真实流量日志，建立允许列表。等 Enforcement Mode 正式发布（预计 2026 年底或 2027 年初），直接切执行模式，不需要再临阵审计。

如果你的 CI 跑着第三方 Actions、处理外部 npm 包访问、或者有任何形式的外部网络请求，这道出口防火墙迟早要配。早配早安心，晚配的代价是 Enforcement 模式下的一次性全量排障。

GitHub 的路线图说得很清楚：从分布式 YAML 配置走向集中策略治理，从「默认开放」走向「默认受限」。Egress Firewall 是这个方向上最关键的一块拼图——它把 CI Runner 从一个网络黑盒变成了一个可审计、可管控的受保护端点。