GitHub Actions 工作流执行保护功能正式发布

一句话看懂：GitHub Actions 的工作流执行保护功能从公开预览转为正式可用，新增工作流文件级定向、Insights 审计和 REST API，并针对高风险的 pull_request_target 事件推出默认拦截规则。

事件核心：发生了什么

GitHub 于 2026 年 9 月 17 日宣布，Actions 工作流执行保护（Workflow execution protections）在 GitHub Enterprise、组织和仓库三个层级正式 GA。该功能通过“执行者规则”控制谁能触发工作流、“事件规则”控制哪些事件能启动工作流，两者在一次运行前共同评估。

相比预览阶段，正式版新增三项能力：可将规则精确绑定到具体工作流文件（例如只允许指定团队触发 deploy.yml，而 CI 工作流对全体贡献者开放）；新增 Insights 用于查看规则在各级别的评估与执行情况；提供 REST API，支持以代码方式创建、读取、更新、删除规则，包括工作流路径条件。此前的 Evaluate 模式也保留，可先以影子模式观察哪些运行会被拦截。

安全默认值同步落地：针对 pull_request_target 这类常被利用的漏洞（如 Pwn Requests），GitHub 对尚未配置相关事件策略的公开仓库推出默认规则，直接禁用 pull_request_target。该默认规则先以评估模式运行，2026 年 11 月 2 日起对在 GA 前使用默认策略的受影响仓库自动强制执行。

为什么重要

CI/CD 流水线已成为软件供应链攻击的高价值入口，pull_request_target 因在基础仓库上下文中运行并可访问密钥，一旦执行 fork 中的不可信代码，就可能污染流水线并外泄密钥。把执行保护从预览推向正式可用，意味着 GitHub 把 Actions 的权限治理从零散配置提升为可审计、可编程的策略层。对使用 Actions 承载 AI 训练、推理或模型部署流水线的团队而言，这是把安全策略纳入工程治理的现实工具。

对用户/开发者/创作者的影响

企业管理员和平台团队可借助 REST API 将 Actions 策略作为代码统一管理，在数百个仓库间保持规则一致，并接入现有治理工具，减少手工点击设置。普通贡献者可能发现部分工作流触发条件收紧，尤其是面向公开仓库的 pull_request_target 事件。以 AI 项目为例，模型训练、微调或图像生成流水线若依赖该触发器，需要在新默认规则强制执行前明确放行。开发者应利用 Insights 和 Evaluate 模式先评估影响，再用工作流文件定向做细粒度白名单。