GitHub Actions 执行保护 GA：默认禁用 pull_request_target
2026-09-17，GitHub 在 changelog 中宣布 Workflow execution protections for GitHub Actions 正式 GA。该功能此前处于 public preview，可用范围覆盖 GitHub Enterprise、organizations 和 repositories。
官方对机制的描述是：执行保护允许你定义一个 allowlist，用来控制谁可以触发 Actions 工作流，以及哪些事件可以启动它。Actor rules 对应“谁”，event rules 对应“什么事件”，两者会在一次运行开始前被评估。
这意味着它不是单纯的触发器开关，而是把“身份”和“事件”拆成两个可分别配置的维度，在运行入口处做准入判断。
GA 新增了什么
在 public preview 已有的 actor 与 event 规则之外，GA 版本增加了四项能力：
工作流文件定向。 执行保护规则可以限定到具体的工作流文件，而不是整个仓库。同一个仓库因此可以对不同工作流应用不同策略。官方给出的例子是：把 deploy.yml 限制给指定团队，同时让 CI 工作流对所有贡献者开放。
Insights。 可以在 enterprise、organization 和 repository 层级查看规则如何被评估和执行，用于审计策略影响，并在强制执行前后调整规则。
REST API。 可以在 enterprise、organization 和 repository 层级以编程方式管理执行保护，创建、读取、更新、删除规则，包括工作流路径条件。官方给出的用途是：把 Actions 策略作为代码管理，在数百个仓库之间保持规则一致，并把强制执行接入既有治理工具，而不是在设置页面里逐一点击。
Evaluate 模式。 该模式从 preview 延续下来，可以先以影子模式运行规则，观察哪些工作流运行会被阻止，再决定是否强制执行。
新的安全默认：限制 pull_request_target
这次 GA 同时引入了一条默认保护规则，针对 pull_request_target 工作流中的漏洞。官方把这类漏洞（例如 Pwn Requests）列为 action 工作流中最常被利用的漏洞之一。原因在于 pull_request_target 会在基础仓库的上下文中运行，并能访问 secrets；如果执行了来自 fork 的代码，不受信任的代码就可能污染流水线并窃取 secrets。
具体规则是：对于尚未有适用 event policy 的公开仓库，GitHub 引入一条默认规则，禁用 pull_request_target。该默认规则不适用于私有仓库或内部仓库。它最初以 evaluate 模式运行，因此可以先看到哪些工作流运行会受影响，再进入强制执行。
2026-11-02，GitHub 会对在 GA 之前使用默认 pull_request_target 策略的受影响仓库自动强制执行该默认规则。
准备方式有两种：用 Insights 查看 evaluate 规则的结果，确认强制执行后哪些工作流运行会失败；然后选择保留规则以阻止 pull_request_target，或者如果工作流仍依赖该触发器，就在适用的 Actions event policy 中显式允许 pull_request_target。特定工作流可以通过新的工作流文件定向能力加入 allowlist。
对 CI/CD 与自动化流水线的意义
大多数团队已经熟悉仓库权限、分支保护和环境审批，但工作流执行路径往往比代码写入路径更复杂。一个仓库里可能同时存在人工推送、PR 合并、定时任务、外部系统调用、机器人提交、可复用工作流和链式工作流。生产部署、密钥读取、云凭据获取、模型发布等动作，一旦被错误身份触发，影响面可能超过一次普通代码合并。
执行保护的工程意义在于：它把“谁可以进入工作流执行路径”和“什么事件可以启动它”变成可配置的 allowlist 问题。对于企业来说，这可以成为现有权限模型之外的一层准入控制。
但要注意，allowlist 不是完整权限系统。它不能替代最小权限 token、环境审批、OIDC 条件限制、secret 范围控制和审计告警。更合理的定位是：在 CI/CD 执行入口增加一道可验证的准入控制，并与既有控制组合使用。
如果团队让自动化机器人或 AI Agent 参与代码提交、PR 创建、模型部署或推理服务发布，这些自动化身份通常需要仓库写权限或 token。一旦 token 被滥用，攻击者可能借助自动提交或 PR 进入工作流执行路径。执行保护的 allowlist 可以作为一个收敛点：限制哪些身份能够进入部署、发布、密钥读取类工作流。
需要说明的是，官方 changelog 没有专门提到 AI Agent、模型部署或自动化提交场景，以上属于工程推演。对开发团队而言，可行的做法是先把高风险工作流挑出来，再验证 allowlist 是否真的覆盖这些自动化触发路径。
落地时的检查项
- 盘点所有能进入生产部署、发布、密钥读取和云凭据获取工作流的身份：人类维护者、GitHub App、bot、PAT、部署密钥、OIDC 主体等。
- 区分人工触发与非人工触发，确认 schedule、repository_dispatch、workflow_run、可复用工作流、fork PR 等路径是否受 allowlist 约束。
- 确认管理面：组织级策略能否覆盖仓库级例外，仓库管理员能否自行修改 allowlist，变更是否进入审计日志。
- 与分支保护、环境审批、secrets 范围、OIDC 条件组合使用，避免只依赖单点控制。
- 对自动化场景，不要让机器人复用人类 PAT；使用独立身份，限制其只能触发指定工作流，生产发布保留人工审批。
- 观察异常触发：如果 allowlist 生效后仍有非预期身份进入执行路径，需要检查链式工作流和可复用工作流的传递关系。
- 对公开仓库，先查看
pull_request_target默认规则的 evaluate 结果，在 2026-11-02 之前决定是保留阻止还是显式允许。
仍需进一步确认的部分
当前官方 changelog 确认了 GA 状态、可用层级、actor 与 event 规则、工作流文件定向、Insights、REST API、evaluate 模式，以及 pull_request_target 默认保护规则和强制执行日期。以下内容在现有资料中尚未明确：allowlist 是否支持团队、GitHub App、bot 或企业主体作为 actor；对 reusable workflow、composite action 是否具有传递性；是否提供 CLI 或 Terraform 管理方式；告警与通知的具体形式；与 environment protection rules 的交互细节。
结论很直接：GA 说明该功能进入了可生产评估阶段，但它不是 CI/CD 权限模型的全部。团队应把它纳入执行层准入控制，同时保留分支保护、最小权限和环境审批。真正需要验证的不是“有没有 allowlist”，而是 allowlist 的边界是否覆盖了你的实际触发路径。