团队最怕的不是代码写错一行，而是把云厂商 Token 一起合进主分支。过去 push protection 主要在 push 阶段拦截，仍可能漏掉某些类型或绕过场景。GitHub 在 2026 年 9 月 9 日公开预览了一个更靠后的闸门：当 Pull Request 引入 secret scanning 告警时，Repository ruleset 可以直接阻止合并。本文不讨论“谁提交了什么”，只讲怎么理解这条链路、怎么配置，以及如何用一个安全的假值验收。
一、这次变化解决什么问题
新规则检查两件事：针对 PR head commit 的 secret scan 是否完成，以及 PR 的提交是否引入仍然开放的 secret 告警。两项都不满足时，未拥有 bypass 权限的参与者不能合并。它是合并前的第二道门，不是对 push protection 的替代。
功能属于 GitHub Advanced Security 相关能力的 public preview，适用范围和可用套餐应以当前组织页面为准。不要把预览功能直接当成所有仓库默认拥有的基础能力。
二、先把几个概念分开
Secret scanning负责发现疑似凭据；Push protection尽量在代码进入远端前拦截；Ruleset则把检查结果变成分支或标签的合并门禁。三者像扫描器、门卫和门锁：少一个都可能留下缝隙。
规则关注的是“本次 PR 引入的告警”，不是要求团队把历史全部清零才允许开发。历史告警仍应按组织流程处理，但不要用关闭一个无关告警的方式绕过当前 PR。
三、配置前的准备
- 确认组织或仓库已启用 Secret Protection 能力，并确认操作者拥有配置 ruleset 的权限。
- 明确保护对象，例如 default branch 或 release 分支；先在测试仓库验证，不要直接把生产发布分支锁死。
- 准备一个不会被任何系统接受的假值，例如
EXAMPLE_ONLY_NOT_A_REAL_TOKEN_123456。不要把真实 Token 写进测试。 - 记录绕过权限、告警处理人和异常恢复路径。门禁配置得很严，但没人知道如何修复，最后就会变成“大家一起盯着红灯发呆”。
四、创建 Repository ruleset
进入仓库的 Settings，找到 Rules，创建或编辑针对目标分支的 ruleset。选择分支匹配范围，启用要求 secret scanning 告警被解决的规则；如果界面提供 secret 类型筛选，先从 provider pattern 开始，再根据误报情况评估 custom 或 generic pattern。
保存前检查三点：目标仓库是否正确、目标分支模式是否正确、绕过角色是否最小化。规则集是组织治理配置，不能只截图给同事看，必须在实际 PR 上验证。
五、用安全假值做验收
- 从测试分支创建 PR，加入上述假值，放在普通文本文件中即可；不要调用任何云服务。
- 等待 head commit 的 secret scan 完成，观察 PR checks 和 ruleset 状态。
- 确认出现新增 secret 告警，且合并按钮被 ruleset 阻止。
- 删除假值，提交修复，关闭对应告警或按平台流程标记为误报。
- 再次等待扫描完成，确认 PR 不再有新增 secret 告警，门禁恢复可合并。
验收重点不是“页面出现了一个红叉”，而是从阻止到修复再到恢复的闭环真的走通。
六、常见失败分支
| 现象 | 优先检查 |
|---|---|
| 没有发现告警 | 扫描是否完成、假值是否匹配已启用的检测类型、PR 是否确实包含新提交 |
| 有告警但仍可合并 | ruleset 是否命中目标分支、规则是否启用、操作者是否拥有 bypass 权限 |
| 修复后仍被阻止 | 告警是否仍 open、扫描结果是否刷新、是否还有另一个提交引入同类 secret |
| 误报太多 | 先核对告警类型和验证状态，再调整检测范围；不要为了绿色直接关闭整套扫描 |
七、为什么不能只依赖一层防护
凭据可能从提交、分支合并、复刻仓库或自动化流程的不同路径进入代码库。push 阶段适合快速反馈，PR 阶段适合结合上下文做治理，运行时还应使用云厂商密钥轮换、最小权限和审计日志。任何扫描器都不是保险柜，真实凭据一旦泄露，第一动作仍然是撤销或轮换，而不是只删除那一行代码。
八、落地清单
- 目标分支已写入 ruleset，且规则集状态为启用。
- 测试 PR 的扫描完成状态可见，新增假值告警能阻止合并。
- 移除假值并处理告警后，门禁能恢复通过。
- bypass 权限经过最小化，异常时有明确处理人。
- 文档记录检测范围、例外流程、凭据轮换和审计周期。
九、结语
这项能力的价值不在于多一个按钮，而在于把“凭据安全”从个人习惯变成仓库合并的可验证条件。建议先用测试仓库跑通闭环，再逐步覆盖主分支和发布分支。门禁不是为了让开发更难，而是让秘密不要搭着 Pull Request 的顺风车出门。
参考：GitHub Changelog《Block pull requests with exposed secrets from merging》、GitHub Rulesets 文档、GitHub Secret scanning 文档。
🔕 评论已关闭