2026 年 9 月 17 日，GitHub 宣布 Actions 工作流执行防护（Workflow Execution Protections）结束公开预览、正式可用，覆盖 GitHub Enterprise、组织与仓库三级。本文从 DevOps 与平台工程视角解读。
规则模型：管“谁”和“什么”
据官方更新日志，执行防护通过允许名单控制谁能触发工作流、哪些事件可以启动运行：执行者规则（Actor rules）覆盖“谁”，事件规则（Event rules）覆盖“什么”，Actions 在每次运行前同时评估两者。对平台工程团队，这意味着 CI/CD 触发策略从仓库设置里的零散开关，变为可统一描述、可强制执行的运维策略对象。
GA 新增三项能力
正式可用新增三项能力：工作流文件级定向，可把规则限定到特定工作流文件而非整个仓库，例如只允许指定团队触发 deploy.yml，而 CI 工作流对所有贡献者开放；Insights 用于查看规则在企业、组织与仓库中的评估与执行情况，审计策略影响并持续调优；REST API 支持以代码方式在三级批量创建、读取、更新与删除规则（含工作流路径条件），把 Actions 策略纳入策略即代码流程并接入现有治理工具。预览期的评估模式也予以保留，可先以影子模式观察哪些运行会被拦截。
新安全默认值
针对 pull_request_target 工作流漏洞（如 Pwn Requests）——这类触发在基础仓库上下文中运行、可访问密钥，若执行来自分叉的不可信代码，可能污染流水线并窃取密钥——GitHub 为没有相应事件策略的公共仓库引入默认规则，禁用 pull_request_target；该默认规则不适用于私有与内部仓库，初期以评估模式运行。2026 年 11 月 2 日，将对仍在使用默认策略的相关仓库自动强制执行；仍依赖该触发器的工作流，可在事件策略中显式放行，或用文件级定向把个别工作流加入允许名单。
迁移与平台落地建议
建议运维与 DevOps 团队先用 Insights 查看评估结果，确认 11 月强制生效后哪些运行会失败，再决定默认拦截还是显式放行；对多仓库组织，优先用 REST API 把策略写入 Git 仓库统一管理，配合代码审查保证变更可追溯，并与环境的部署保护规则衔接形成发布全链路门禁。
小结
GitHub Actions 工作流执行防护于 2026 年 9 月 17 日正式可用，以文件级定向、Insights 审计、REST API 策略即代码与 pull_request_target 默认禁用为核心，是 DevOps 与平台工程领域供应链安全方向的一次重要更新。