GitHub Actions 工作流执行保护功能正式上线

此前处于公开预览阶段的 GitHub Actions 工作流执行保护功能现已正式可用，适用于 GitHub Enterprise、组织和仓库。

执行保护允许你定义一个允许列表，用于控制哪些人可以触发 Actions 工作流，以及哪些事件能够启动工作流。执行者规则定义“谁可以触发”，事件规则定义“什么可以触发”，Actions 会在运行前同时评估这两类规则。

除公开预览期间已有的执行者规则和事件规则外，正式可用版本还新增了：

• 工作流文件定向： 将执行保护规则限定到特定工作流文件，而非整个仓库，使单个仓库能够为不同工作流应用不同策略。例如，可将 deploy.yml 限制为仅由指定团队使用，同时向所有贡献者开放 CI 工作流。
• Insights： 查看 Actions 如何在整个企业、组织和仓库范围内评估及执行规则。这使你能够审计策略影响，并在规则强制执行前后持续优化规则。
• REST API： 在企业、组织和仓库级别以编程方式管理执行保护。你可以创建、读取、更新和删除规则——包括工作流路径条件——从而将 Actions 策略作为代码进行管理，确保数百个仓库之间的规则保持一致，并将强制执行接入现有治理工具，而无需逐项点击设置。

评估模式也从预览阶段延续下来，因此你可以在影子模式下运行规则，在正式强制执行前查看哪些工作流运行会被阻止。

pull_request_target 工作流中的漏洞，例如 Pwn Requests，是 Actions 工作流中最常被利用的漏洞之一。pull_request_target 会在基础仓库的上下文中运行，并可访问你的密钥；因此，如果执行了来自 fork 的代码，这些不受信任的代码可能污染你的流水线并窃取密钥。我们正在推出一项默认保护规则，以限制 pull_request_target 事件的执行。

对于尚未具有适用事件策略的公共仓库，GitHub 将引入一项默认规则，禁用 pull_request_target。该默认规则不适用于私有或内部仓库。它最初会以评估模式运行，因此你可以在强制执行开始前查看哪些工作流运行将受到影响。

对于在正式可用之前使用默认 pull_request_target 策略的受影响仓库，我们将于 2026 年 11 月 2 日自动强制执行该默认规则。

为准备该规则的推出，你可以通过 Insights 查看评估规则的结果，并了解强制执行开始后哪些工作流运行会失败。

之后，你有两个选择：保留该规则以阻止 pull_request_target，或者，如果你的工作流仍依赖该触发器，则在适用的 Actions 事件策略中显式允许 pull_request_target。你可以使用新的工作流文件定向功能，将特定工作流加入允许列表。

要开始使用，请参阅关于 Actions 策略、控制工作流执行以及 Actions 策略 REST API 参考。

Workflow execution protections for GitHub Actions, previously in public preview, are now generally available for GitHub Enterprise, organizations, and repositories.

Execution protections let you define an allowlist that controls who can trigger an Actions workflow and what events can start it. Actor rules cover the who, event rules cover the what, and actions evaluate both before a run.

Alongside the actor and event rules you’ve used in public preview, general availability adds:

• Workflow file targeting: Scope execution protection rules to specific workflow files rather than an entire repository, so a single repository can apply different policies to different workflows. For example, restrict deploy.yml to a designated team while leaving CI workflows open to all contributors.
• Insights: See how actions evaluate and enforce your rules across your enterprise, organization, and repositories. This enables you to audit policy impact and tune rules both before and after you enforce them.
• REST API: Manage execution protections programmatically at the enterprise, organization, and repository level. Create, read, update, and delete rules — including workflow path conditions — so you can manage Actions policy as code, keep rules consistent across hundreds of repositories, and wire enforcement into your existing governance tooling instead of clicking through settings.

Evaluate mode also carries over from the preview, so you can run rules in shadow mode and see which workflow runs would be blocked before you enforce them.

Vulnerabilities in pull_request_target workflows, such as Pwn Requests, are one of the most commonly exploited vulnerabilities in action workflows. pull_request_target runs with access to your secrets in the context of the base repository, so if code is executed from a fork, that untrusted code could poison your pipeline and exfiltrate secrets. We’re rolling out a default protection rule to limit the execution of pull_request_target events.

For public repositories that do not already have an applicable event policy, GitHub is introducing a default rule that disables pull_request_target. This default does not apply to private or internal repositories. It initially runs in evaluate mode, so you can see which workflow runs would be affected before enforcement begins.

On November 2, 2026, we’ll automatically enforce the default rule for affected repositories that were using the default pull_request_target policy before general availability.

To prepare for the roll out of this rule, you can view the results of the evaluate rule using Insights and see which workflow runs will fail once enforcement begins.

From there you have two options: leave the rule in place to block pull_request_target, or explicitly allow pull_request_target in an applicable Actions event policy if your workflows still depend on the trigger. Specific workflows can be allow-listed using the new workflow file targeting.

To get started, see About Actions policies, Control workflow execution, and the Actions policies REST API reference.