你以为 workflow 里读个漏洞警报都要开 write 权限？今天 GitHub 把这件事用最小权限彻底原生化了

每次接完第三方 PR，CI 跑完你都不知道里面有没有埋漏洞——不是不想查，是想读 Dependabot 警报就得给 workflow 整个 write 权限，这个代价太高了，很多团队干脆就放弃了。

这件事，GitHub 2026 年 9 月初用三行配置彻底原生化了。

漏洞警报终于可以只开读权限了

过去 workflow 想读 Dependabot 安全警报，只有一个办法：把 GITHUB_TOKEN 的 permissions 开到 contents: read + pull-requests: read + statuses: read，再加一个 security-events: read，或者直接开 contents: write——后者等于把整个仓库的写权限交给这个 workflow。

2026 年 9 月 3 日，GitHub 给 GITHUB_TOKEN 新增了 vulnerability-alerts 权限，支持 read 和 none 两个值，专门用来读 Dependabot alerts，不再需要动辄 write 权限。

这个改动直接对应的是 2025 年 3 月 tj-actions supply chain 攻击（CVE-2025-30066）：攻击者通过 over-permissioned token 从 runner 内存里提取了 23,000+ 个仓库的 CI 凭证。当时 security-events: write 被当成最小权限来用，结果变成了攻击面。

最小权限终于变成默认选项，而不是高级操作。

Runner 版本有了正式的「保质期」查法

自托管 runner 的版本管理一直是糊涂账：GitHub 改了平台行为，但 runner 还在用旧版本注册上去，job 莫名其妙不跑了，找原因要靠试。

现在有了一个 REST API：

在仓库、组织、企业三个层级都能调，返回 runner_version、runtime_deprecates_at（任务执行截止日期）和 registration_deprecates_at（注册截止日期）。

Enterprise Cloud 的完整执行日期是 2026 年 9 月 25 日。届时 9 月 7/9/11/14/16/18 都有 brownout 窗口，11:00–15:00 ET 期间旧版 runner 既不能注册也不能执行 job。

建议写个 cron 定期扫一下，提前 30 天告警：

可复用 workflow 终于能认出「自己是谁」了

可复用 workflow 有一个元问题：它运行在调用方的上下文里，github.workflow_ref 和 github.workflow_sha 指向的是调用方，而不是定义这个 reusable workflow 的文件本身。这意味着如果你想在 reusable workflow 里引用自己定义的文件，或者对它的来源做 SLSA 签名校验，过去只能靠第三方 action（canonical/get-workflow-version-action）来 workaround。

现在 GitHub 原生给了四个 job.* 属性：

• job.workflow_ref — workflow 文件的完整 ref
• job.workflow_sha — 对应 commit SHA
• job.workflow_repository — owner/repo
• job.workflow_file_path — 相对于仓库根的路径

三件事，今天就能做

1. 加上 vulnerability-alerts: read：如果你的安全审计 workflow 还在用 contents: write 读 Dependabot alerts，今天换成这个，三行改完，安全性直接提升一个等级。

2. 写一个 runner 版本检查的 cron：对照 GitHub 公布的最低版本（2.329.0），确保所有自托管 runner 在 9 月 25 日前完成升级。

3. 把 reusable workflow 里的 workaround 替换掉：如果你在用 canonical/get-workflow-version-action，现在可以删掉它，换成 job.workflow_sha，配合 SLSA 工具做签名校验链。

三个变化都算不上大版本，但每一个都对应过去真实出过事的场景——over-permissioned token、runner 版本失管、reusable workflow 身份缺失。GitHub 这次把三块短板同时补上了。