你以为 workflow 权限只能靠 write-all？今天 GitHub Actions 用三个更新把最小权限原则彻底原生化了

写过前端的都知道 CI pipeline 配着配着就变成了 permissions: write-all：反正不知道要什么权限，开最大总没错。2026 年 9 月，GitHub Actions 甩出三个更新，把这件事从根上翻了个遍。

Runner 版本生命周期，终于能查了

以前自托管 runner 什么时候停服，只能靠 GitHub 邮件通知或者自己记。现在调用 GET /actions/runners/deprecations/{version}，在仓库/组织/企业三个级别都能查到。返回三个关键时间点：runner_version、runtime_deprecates_at、registration_deprecates_at——一个告诉你什么时候不能用，一个告诉你什么时候不能注册。对维护大量自托管 runner 的团队来说，这个 API 把被动等邮件变成了主动做升级计划。

vulnerability-alerts：最小权限终于能读 Dependabot 了

这是本次最实用的改动。workflow 现在可以直接申请 vulnerability-alerts: read 权限，只读访问 Dependabot alerts，不再需要挂载整个安全事件或 contents 写权限。

permissions:
  vulnerability-alerts: read

这个 permission 只支持 read 和 none 两个值，不存在 write——因为读 Dependabot alerts 本质上就是只读操作。新手 team 不用再靠试错判断”我到底需不需要写权限”，安全团队也不用来回 review write-all 到底写了什么。

job.workflow_ref：可复用 workflow 终于知道自己是谁

这块对用 reusable workflow 的团队最有感。以前 github.workflow_ref 永远指向最外层调用方，可复用 workflow 自己是谁、在哪个 commit、被哪个 repo 调用，运行时拿不到。

现在四个新 job context 属性补上了这个空白：job.workflow_ref 定义当前 job 的 workflow 文件完整 ref；job.workflow_sha 定义当前 job 的 workflow 文件 commit SHA；job.workflow_repository 定义当前 job 的 workflow 文件所在 repo；job.workflow_file_path 相对仓库根目录的 workflow 文件路径。

直接写在 workflow 文件里的 job，job.workflow_ref 等于 github.workflow_ref；调用 reusable workflow 时两者才分开。这意味着可复用 workflow 可以在日志和审计记录里精确写出”我是哪个文件、哪个版本被谁调用的”，而不是只能写调用方的信息。

怎么落地

三个更新对应三个不同场景，不需要一口气全加上。最小权限改造最紧迫——只要 workflow 里要读 Dependabot alerts，vulnerability-alerts: read 就可以先加上，不需要动其他权限。runner 生命周期 API 适合有自托管 runner 资产池的团队，配合现有的 runner inventory 脚本做主动预警。可复用 workflow 身份追溯是锦上添花，新项目可以先默认加上，老项目看场景慢慢补。

三个更新拆开做，失败时容易定位：报错是 token 权限不足就加 vulnerability-alerts；是 context undefined 就查 GHES 版本；是 runner 注册失败就查 deprecation API——各修各的，互不影响。