GitHub 于 2026 年 7 月 28 日宣布，GitHub Actions 现在会把部分可能有害的 workflow run 暂停，等待人工批准后才开始执行。这项改动针对的是 supply-chain attacks：攻击者利用被盗的 GitHub credentials，将恶意 Actions workflow 推入 repository，目标可能包括窃取 CI/CD credentials 及进一步发起攻击。
新的流程在 workflow 启动前加入一个风险闸门。当 GitHub 判断某次 run 可能有害，run 不会立即执行，而是等待具有 repository write access 的 collaborator 检查和批准。批准必须通过 authenticated web session 提交；批准后，workflow 才会按正常流程继续。这意味着从 commit 到执行之间，多了一个由平台触发的检查点。
对 repository 维护者来说，这项保护不需要额外设置，GitHub 会自动套用。自动化本身不会因此全部变成手动：只有被识别为可能有害的 workflow run 才会被暂停，已经通过风险判断的 run 仍可照常执行。这种设计把批准行为集中在少数高风险情况，而不是要求团队逐次批准所有 CI/CD 工作。
目前的范围有清楚限制。GitHub 表示，保护只适用于 github.com 上的 public repositories；GitHub Enterprise Server 暂时不提供这项保护。团队不能因此推断企业自建环境已经有相同的 server-side gate，也不能把「有批准流程」理解成 repository 已经完成整套 supply-chain 防护。
这项更新的价值，在于它把 workflow 的信任模型从「有权限推送就可以直接执行」改成「平台先检查，必要时要求另一个具有写入权限的人确认」。但人工批准仍然需要看 workflow 做了什么：例如触碰哪些 secrets、使用哪些 third-party actions、要求哪些 permissions、是否固定 action 版本，以及最近的 commit 和 contributor 是否合理。批准按钮本身不是安全审查的替代品。
对使用 AI agent 或其他自动化工具生成 workflow 的团队，这个检查点尤其值得保留。代理可以协助生成 YAML、修改 permissions 或更新 action，但当结果会接触 CI/CD credentials 时，应让平台或人工在真正执行前有机会拦截。更重要的是把 workflow review、least privilege、secret rotation、action pinning 和 audit log 放在同一条交付流程内。
GitHub 这次没有声称风险判断可以拦截所有恶意 workflow；公告只说明部分可能有害的 run 会被 hold。较稳妥的理解，是平台新增了一道默认开启的启动防线，而不是宣告供应链风险已经解决。团队仍应按自己的 repository、runner、secrets 和部署环境验证实际行为。
