三年 CI，今天才发现 GitHub Actions 的供应链从来不是你自己管的——2026 安全路线图把这件事彻底变了

大多数团队的 CI 流水线，跑的都是一堆 uses: actions/checkout@v4、uses: actions/setup-node@v4——这些标签随时可以被仓库所有者重定向到任意 commit。三年前你写的那行 uses: some-action@latest，今天跑的可能已经完全不是同一个代码。

这件事在 2025 年被玩出了花。tj-actions/changed-files、Nx、trivy-action，连续三个热门 action 被供应链攻击，攻击路径一模一样：先搞定一个维护者的账号，然后不动声色地把 latest tag 指向一个带恶意代码的 commit。所有用了这些 action 的 workflow，在下一次触发时全部中招——凭证被偷、代码被拉走、构建产物被篡改，全都在后台静默发生，团队可能几天之后才发现。

GitHub 2026 安全路线图就是冲着这个来的，三层结构，一层比一层深。

第一层：Dependency Locking，workflow 也要 lockfile

现在的 workflow 引用 action 靠 tag，你写 uses: actions/checkout@v4，跑的时候 GitHub 去拿 v4 这个 tag 指向的最新 commit。但 tag 是可写的——维护者随时可以把它删掉重指向，GitHub 对此没有任何约束。

Dependency Locking 的思路就是给整个 Actions 依赖图生成 lockfile。每个直接依赖和传递依赖都锁定到一个不可变的 commit SHA，附密码学哈希。每次 push PR，lockfile 里的依赖以 diff 形式展示——你看得到谁从哪个版本升级到了哪个版本，而不是两眼一抹黑直接被升级。如果 lockfile 里的 SHA 对不上（说明有人改过 tag 但没更新 lockfile），job 在运行前就失败，根本不会等到被攻击。

Timeline：公开预览 3-6 个月，正式发布 6 个月后。还没来，但方向已经定了。

第二层：Policy-Driven Execution，org 级别一刀切

现在的安全问题不只是某个 action 被篡改，还有 workflow 本身的权限边界模糊——多少人知道 pull_request_target 这个事件名的危险性？多少人知道 workflow 可以从它不应该访问的 secrets 里读数据？

GitHub 正在把 Rulesets 框架扩展到 workflow 执行策略层面。你可以在 org 或 repo 级别定义：谁可以触发 workflow、哪些事件类型允许、哪些 action 可以被调用。不再是每个 workflow 各自为政，而是中心化策略，统一管控。Rulesets 支持 evaluate 模式——先记录违规，不拦截，让团队先看清楚影响再开强制模式。

Scope Secrets 是另一个相关更新：secrets 以后可以绑定到特定分支、环境或 workflow 路径，而不是默认流到所有地方。这意味着你不用再担心「这个 secrets 是不是开太大了」——它只流到它该去的地方。

Timeline：Evaluate 模式 3-6 个月，GA 6 个月。

第三层：Egress Firewall，跑在 runner 里面的攻击者也无路可逃

即使攻击者成功进了 runner（比如通过一个被污染的 action），他也很难把数据传出去。GitHub 在 runner 外层加了一层 Layer 7 防火墙，完全独立于 VM 内部——攻击者拿到 root 也改不动这层防火墙。

你可以配置允许流出的域名、IP 范围、HTTP 方法和 TLS 要求。防火墙支持两种模式：monitor 模式记录所有出站请求但不拦截，enforce 模式只放行明确允许的流量。落地路径是：先 monitor 两个星期，看清楚团队的真实出站流量长什么样，再切 enforce。

Timeline：公开预览 6-9 个月，GA 9 个月后。

能做什么

Dependency Locking 和 Egress Firewall 还在路上，但 Policy-Driven Execution 的 evaluate 模式是近期的重点。如果你现在跑的是公开仓库，或者 workflow 里用了第三方 action，第一件事是去 Rulesets 里把 pull_request_target 的触发条件限死——这件事不需要等新功能，现在就能做。

第二件事是盘一遍你所有 workflow 里的 permissions:，最小权限原则喊了这么多年，真正做到位的团队不多。读漏洞警报已经不需要开 contents: write 了，vulnerability-alerts: read 足矣——这是 GitHub 九月三已经落地的更新。

第三件事是关注 Dependency Locking 的公开预览动向。这东西一旦 GA，所有用 latest/master tag 跑第三方 action 的 workflow 都会面临一次要么升级要么锁死的选择。现在提前想好迁移路径，到时候不会手忙脚乱。

CI/CD 安全这件事，以前靠流程靠约定，以后靠产品原生能力——GitHub 终于把这件事当成了自己的责任，而不是丢给社区自己去操心。