23,000 个仓库的密钥，今天被一个 GitHub Action 偷走了——这件事把 CI/CD 供应链安全的根子彻底扒开了

2026 年 3 月，一个被入侵的 GitHub Action 把 23,000 个仓库的 CI/CD 密钥全抖落在了公开日志里。不是什么高级漏洞利用，就是改了改 action 的标签指向，指向一套读取 Runner 进程内存的脚本。密钥就这么被读走了。

这不是孤例。2025 到 2026 年，GitHub Actions 供应链攻击接连爆发：tj-actions/changed-files、Trivy-action、@bitwarden/cli——攻击者不再正面打你的代码，而是打你依赖的那套自动化管道。CI/CD 已经成为攻击者的首选入口。

GitHub 的回应是一套 2026 安全路线图，Q3-Q4 开始陆续公开预览。其中最被低估的一件，叫 Native Egress Firewall。

它解决什么问题

现在的 GitHub-hosted Runner 跑 CI job 时出去的网络流量基本是自由的。想访问哪个域名就访问哪个，想往哪里发数据就发到哪里。攻击者拿到 runner 的 root 权限之后，可以随意把敏感数据往外传——GitHub Token、云服务密钥、npm Token，全可以直接发到外部服务器。第三方安全工具比如 StepSecurity Harden-Runner 虽然能限制出口流量，但它们跑在 runner 内部，root 权限拿到之后可以直接绕过。

Native Egress Firewall 不一样。它跑在 runner VM 外面，在第 7 层工作。即使攻击者拿到了 runner 的 root 权限，改不了这层防火墙，因为它不在你的 runner 里面。

两层工作模式：Monitor 模式观察所有出口流量，记录每条请求对应的 workflow、job、step 和触发命令，帮你建立真实的流量画像；Enforce 模式则直接在 allowlist 之外把流量掐掉。

GitHub 给的推荐落地路径是：先用 Monitor 跑几周，收集真实流量数据，建立基于真实数据的 allowlist，再切到 Enforce。这样不会因为误拦影响 CI/CD。

为什么是 2026 年才出现

2025-2026 这两年，供应链攻击的频率和规模都在上升。攻击者在进化：从手动改代码，到用 AI 生成攻击 payload。Common primitive 始终是同一个：pull_request_target 误配置，或者 action 标签被人篡改。

2026 年 GitHub 路线图里还有另外几个关键更新：

Dependency Locking（依赖锁定）：workflow YAML 里直接声明所有 action 的完整 commit SHA，构建时校验哈希，不匹配就停掉。这针对的是标签重定向攻击——攻击者把 v45 标签偷偷指向恶意 commit，有了这个机制，标签换没换一眼就能看出来。

Scoped Secrets（范围化密钥）：密钥不再因为 workflow 存在就自动可用，而是绑定到具体的执行上下文——哪个仓库、哪个分支、哪个环境、哪个 workflow 文件。reusable workflow 里的隐式密钥继承被取消，改成显式作用域。

Policy Execution Controls（策略执行控制）：把安全策略从每个 YAML 文件里抽出来，推到组织层面，用 Rulesets 集中管控。谁能手动触发 workflow，哪些 GitHub Actions 事件可以被执行，哪个 workflow 能访问哪个密钥——都可以在组织级别定义，而不是靠每个仓库自己配对。

Actions Data Stream：近乎实时的遥测数据，把 workflow 执行事件推到 S3、Azure Event Hub 这类外部系统。出了安全事件之后，不用再靠猜和翻日志。

你现在能做什么

在这套功能 GA 之前，有几件事可以马上做，成本低、收益高：

第一，所有 action 引用从 @tag 或 @branch 换成完整 commit SHA。GitHub 官方文档里有明确说明，这是目前最高效的防护措施，能防止标签被攻击者偷偷重定向。

第二，审计所有用了 pull_request_target 的 workflow。这个事件是供应链攻击里最常被利用的触发器，用错了你的 CI 环境等于对外部代码开了密钥访问权限。

第三，把 runner 出口流量先管起来。哪怕先用第三方工具监控起来，也有数据可以看。等 GitHub Native Egress Firewall 公开预览出了，切过去就行。

第四，检查你们 CI/CD 用到的 action 最近有没有被篡改的公告。Trivy 那个事件从恶意标签推到公开发现，中间隔了六周。很多团队是在 GitHub 安全团队发邮件通知密钥可能泄露之后才知道中招的。

这件事的实质

CI/CD 管道本质上是你们基础设施里权限最高的系统之一——它能接触源码、云密钥、发布权限，而且默认信任所有运行的代码。但很长时间里，这个系统是安全建设中最低配的部分。

GitHub 2026 安全路线图在做的事，是把“安全靠每个 YAML 文件自己配对”这个模型，换成“组织级别集中管控、可审计、可强制执行”的模型。runner 变成受保护的可观测端点，而不是用完就丢的黑盒子。

23,000 个仓库的密钥泄露是结果，不是原因。原因是从基础设施层面就没有把 CI/CD 当成有最高权限的系统来保护。

下一步：翻出你们 GitHub 组织的 Actions 日志，看一眼过去三个月里跑过的 workflow 都访问了哪些外部域名——这件事，现在就该做。