配了三年CI，今天才发现GitHub Actions每次等runner挂了才知道版本过期——这件事被三个API彻底原生化了

阿监·前端工程化 内容创作者 2026-09-09 10 阅读

你有没有过这种经历：某天早上来，workflow全红了，查了半天日志才发现是GitHub把runner版本悄悄停了。然后就是一顿紧急升级，手忙脚乱。

这种事在2026年9月之前，只能靠「踩坑发现」。现在不用了。

2026年9月3日，GitHub Actions一口气发了三个更新，专门修三类痛点：runner生命周期可视、权限最小化、可复用workflow身份溯源。

一、runner版本什么时候停？一个API提前告诉你

以前想提前知道某个runner版本什么时候停用，只能靠翻changelog+靠运气。GitHub社区讨论区里有人从2022年就开始提这个需求（Discussion #60612），直到这次才真正解决。

现在直接调这个API就行：

GET /actions/runners/deprecations/{version}

返回三个关键时间戳：

  • runner_version：版本号
  • registration_deprecates_at：新runner无法注册的时间
  • runtime_deprecates_at：已有runner停止执行任务的时间

两个时间分开的好处是：runner可以先停止注册，但还在跑已有任务。这让团队有窗口期从容升级，不用第一天就炸。

Node 20从GitHub-hosted runners下线是2026年9月23日，自托管runner强制执行是9月25日。如果你在用旧版本，现在查还来得及。

下一步： 给你的runner管理加一个cron job，提前30天告警：

jobs:
  check-runner-deprecation:
    runs-on: ubuntu-latest
    steps:
      - name: Check runner deprecation
        run: |
          RESP=$(curl -s -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" 
            "https://api.github.com/repos/${{ github.repository }}/actions/runners/deprecations/2.329.0")
          RUNTIME=$(echo "$RESP" | jq -r .runtime_deprecates_at)
          echo "Runtime deprecation: $RUNTIME"

二、读Dependabot漏洞终于不用存PAT了

这是安全层面最实在的改动。

以前在workflow里读Dependabot漏洞告警，必须用一个带security-events: write权限的Personal Access Token，或者装一个GitHub App。一个读告警的操作需要这么重的凭证，全是过度授权。

现在workflow的permissions块里直接加一行就行：

permissions:
  vulnerability-alerts: read

然后用原生GITHUB_TOKEN就能调Dependabot API了：

permissions:
  vulnerability-alerts: read

jobs:
  audit-deps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const alerts = await github.rest.dependabot.listAlertsForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: open,
              severity: critical
            });
            if (alerts.data.length > 0) {
              core.setFailed(`${alerts.data.length} critical Dependabot alerts open`);
            }

这个改动背后有真实的教训。2025年3月的tj-actions供应链攻击（CVE-2025-30066）利用runner内存中的secrets，破坏了23,000+个仓库。过度授权的token是帮凶之一。权限范围越小，泄露后的爆炸半径越小。

下一步： 搜一下你仓库里所有读Dependabot告警的workflow，把PAT换成vulnerability-alerts: read，这是本周最值得花10分钟做的事。

三、可复用workflow现在知道自己是谁了

可复用workflow（on: workflow_call）有个结构性缺陷：你调uses: org/repo/.github/workflows/audit.yml@main，这个被调用的workflow拿到的github.workflow_ref和github.workflow_sha指向的是调用方，不是它自己。

这在安全上是个问题：攻击者如果能往org/repo写代码，把@main指向恶意commit，你的仓库就会在完全不知情的情况下执行任意代码。

现在GitHub在job context里加了四个新属性：

  • job.workflow_ref：被调用workflow的完整ref
  • job.workflow_sha：被调用workflow的commit SHA
  • job.workflow_repository：被调用workflow所在仓库
  • job.workflow_file_path：被调用workflow的文件路径

这意味着可复用workflow现在可以自我溯源了。实用场景：

场景一：可复用workflow检出自己的代码

# 被调用的workflow（audit.yml）
jobs:
  self-checkout:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          repository: ${{ job.workflow_repository }}
          ref: ${{ job.workflow_sha }}

场景二：日志里记录真实来源，配合SLSA审计链

- name: Log workflow origin
  run: echo "Running workflow SHA: ${{ job.workflow_sha }} from ${{ job.workflow_repository }}"

以前要靠社区的canonical/get-workflow-version-action绕一圈才能实现，现在GitHub原生支持了。

注意： 这四个属性在GitHub Enterprise Server上不可用。如果你的团队用GHES，先确认版本再上线。

这三个改动是什么关系

表面上是三个独立功能，背后指向同一个方向：GitHub Actions的安全基线在系统性提升。

从2025年tj-actions供应链攻击到2026年的runner版本强制执行，GitHub一直在堵三个方向的洞：凭证过宽、可复用workflow身份不透明、基础设施生命周期不透明。这次三项更新各自对应一个缺口。

2026年roadmap上还有：workflow依赖锁定、原生Layer 7出站防火墙、per-job scoped secrets。这些结构性改动落地之后，GitHub Actions的安全模型会和今天完全不同。

三步下一步：

  1. 今天： 把读Dependabot告警的workflow权限从security-events: write换成vulnerability-alerts: read，10分钟，不重启
  2. 本周： 给所有自托管runner跑一遍deprecation API检查，提前规划升级时间
  3. 本月： 把你维护的可复用workflow加上job.workflow_sha日志，配合SLSA工具做供应链审计

这三件事加起来，一个下午能搞定，安全收益立竿见影。

评论区

0 条评论

登录后可评论。

阿监·前端工程化 10 阅读