写过 CI 的人都踩过这个坑——某天早上 workflow 突然全红了，查日志发现 GitHub 悄悄停了对你那个 runner 版本的支持。没有通知，没有预警，只有突然全红的 CI 面板。

这个场景在 2026 年 9 月 3 日之后彻底变了。GitHub Actions 推出一套九月安全更新，三件事加在一起，把 CI 版本管理的整个逻辑翻了一遍。

第一件事：Runner 版本终于有了查询接口

过去想知道某个 runner 版本什么时候停用，只能靠翻 changelog 和看脸。GitHub 9 月 3 日正式上线了 Runner Deprecation API，调用方式直白到难以置信：

curl -H “Authorization: Bearer $GH_TOKEN”
https://api.github.com/repos/ORG/REPO/actions/runners/deprecations/2.329.0

返回三个字段：当前版本、runtime 停用时间（跑任务停止）、registration 停用时间（新注册停止）。可以在 repo / org / enterprise 三个层级调用。

这个 API 解决的核心问题是：提前规划而不是事后补救。具体落地是一段 cron workflow，扫你所有在用版本，提前 30 天报警：

name: Runner Version Health Check
on:
schedule: [{ cron: “0 9 1″ }] # 每周一早上检查
workflow_dispatch: {}

jobs:
check-deprecations:
runs-on: ubuntu-latest
steps:

• uses: actions/github-script@v7
  with:
  script: |
  const runners = await github.rest.actions.listSelfHostedRunnersForRepo({
  owner: context.repo.owner,
  repo: context.repo.repo
  });
  for (const runner of runners.data.runners) {
  const r = await github.rest.actions.getRunnerVersionDeprecation({
  owner: context.repo.owner,
  repo: context.repo.repo,
  version: runner.version
  });
  const depDate = new Date(r.data.runtime_deprecates_at);
  const daysLeft = Math.ceil((depDate – Date.now()) / 86400000);
  if (daysLeft <= 30) {
  core.setFailed(Runner ${runner.name} (${runner.version}) deprecates in ${daysLeft} days);
  }
  }

9 月 25 日 GitHub Enterprise Cloud 对自托管 runner 开始全量强制执行版本要求。Node 20 在 9 月 23 日从 GitHub-hosted runner 下线。节奏很清楚：平台在收紧，不是说说而已。

第二件事：读 Dependabot 漏洞警报不用再存 PAT 了

四年了，community discussion 从 2022 年跟踪到现在的需求终于落地。现在只需要在 workflow 里加一行权限：

permissions:
vulnerability-alerts: read

就能用 GITHUB_TOKEN 原生读取 Dependabot alerts，fail build、通知 Slack、自动创 issue 都可以，不用再折腾 Personal Access Token。

这个 gap 背后有血淋淋的教训：2025 年 3 月 tj-actions 供应链攻击（CVE-2025-30066），通过 runner 内存窃取 secrets，23,000+ 个仓库受影响。over-permissioned token 是帮凶之一。权限粒度越细，泄露时炸的范围越小。

第三件事：可复用 workflow 终于知道自己是谁了

这件事更隐蔽，但影响更深。可复用 workflow 以前有个「身份反转」问题：github.workflow_ref 和 github.workflow_sha 指向的是调用方 workflow，而不是 workflow 本身。对于需要知道「自己是谁」的可复用 workflow，这个设计是反的。

三方 action canonical/get-workflow-version-action 就是为这个问题造的 workaround，现在 GitHub 原生解决了：

jobs:
my-job:
runs-on: ubuntu-latest
steps:

• uses: actions/checkout@v4
  with:
  repository: ${{ job.workflow_repository }}
  ref: ${{ job.workflow_sha }}

  现在可以安全地引用可复用 workflow 自己的代码了

更重要的是安全层面：在每个可复用 workflow 开头记录 job.workflow_sha，GitHub 的 SLSA 工具链可以基于此建立密码学审计链——workflow 自己证明自己身份，而不是依赖调用方传入的数据。这是 2026 Actions 安全路线图的第一步，后面还有 workflow dependency lockfiles、Layer 7 egress firewall、per-job scoped secrets。

下一步：三件事几个小时搞定

九月这三更新没有破坏性变更，但每一件都值得现在做：

1. 跑上面的 cron workflow，把 fleet 里所有 runner 版本扫一遍，看有没有在 9 月 25 日前到期的
2. 把安全 audit workflow 里的 PAT 替换成 vulnerability-alerts: read
3. 检查有没有可复用 workflow 依赖了 canonical/get-workflow-version-action，有就换新属性

三件事加起来几个小时，但换来的是 CI 不再靠「发现」来管理版本，而是靠数据主动规划。这个区别在 9 月 25 日之后会变得非常明显。