写过代码的人都怕这种事：PR合并之后才发现有人把key提交进去了，今天GitHub把这件事彻底截死了

写代码的人大概都怕这种事：辛辛苦苦 review 完一个 PR，结果合并之后发现——有人把 AWS key 提交进去了。secret scanning 早就有了，但大多数团队只是「扫了然后告警」，从来没真正把这件事变成门禁。

2026-09-09，GitHub 给 rulesets 上线了一个新规则：Require secret scanning alerts are resolved on pull requests。从这一天起，你可以在分支规则里加一道卡口：PR 必须把 secret scanning 扫出来的问题全解决掉，才能合并。

这个新规则过两个检查点才放行：

1. secret scan 必须在 head commit 上跑完
2. 这个 PR 引入的所有 alert 都得关闭

默认拦的是 provider pattern 的 secrets，你也可以加上 custom pattern 或 generic pattern 扩大范围。

这件事跟 push protection 有什么区别？

push protection 卡在 push 阶段，secret scanning alert resolution 则是事后关卡——专门补 push protection 没拦住或没配的场景。比如你 generic pattern 没开 push protection，但用 ruleset 要求合并前必须清零 alert，这个规则就能把漏洞补上。两层保护叠在一起，防御才完整。

怎么配置？

去仓库设置 → Rulesets → 新建或编辑分支规则 → 开启 Require secret scanning alerts are resolved。也支持 REST API：require_secret_scanning_alert_resolution rule type + secret_types 参数，或 GraphQL REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION。

前提：组织必须开通了 GitHub Secret Protection 或 GitHub Advanced Security，目前是 public preview 阶段。

下一步

如果你的团队已经在用 secret scanning，但只当告警用——现在可以打开仓库的 rulesets，把这件事从「知道有问题」变成「不让它流出去」。先去规则设置里找找这个选项，确认一下自己的组织有没有开通对应的安全产品。