GitHub 推送保护扩展到预定义模式之外意味着什么

如果团队一直依赖 GitHub 的预定义秘密模式来拦截提交，那么这次更新值得单独看一遍：GitHub 在 2026 年 10 月 28 日宣布，推送保护可以扩展到没有固定、可识别格式的潜在秘密。它不是全站默认打开的“万能扫描器”，而是一个需要管理员显式启用的公开预览能力。

官方地址：https://github.com/

这次变化的核心，是把“凭据长什么样”扩展为“凭据在周围代码中怎样被使用”。开启前必须已有 AI 检测秘密和推送保护，随后再开启阻止 AI 检测秘密的选项；默认关闭，且公开预览阶段会消耗 AI credits。

预定义模式之外，新增的到底是什么

过去的推送保护更擅长识别有稳定前缀、长度或字符形态的秘密。例如某类服务令牌有固定格式，检测器可以把候选文本和已知模式比对。新的 purpose-built classifier 则会结合潜在秘密所在位置和周围代码，判断它是否像一个正在被程序使用的凭据，因此目标不再局限于“长得像某个已知令牌”的字符串。

这里要注意两个边界。第一，公告描述的是 AI-detected secrets 的新推送保护路径，不是把所有普通文本都判定为秘密。第二，GitHub 给出的是早期结果：分类器让推送保护捕获秘密的推送数量超过原来的两倍，用户报告的精确率接近秘密扫描合作伙伴提供的发行方检测器；这属于公告披露的早期结果，不应直接当成每个仓库的固定收益。

它会在哪些提交入口起作用

启用后，分类器会和基于模式的检测器并行运行，面向新的推送、在 GitHub 网页中创建的提交，以及文件上传。检测到潜在秘密时，GitHub 会拒绝这次变更并报告秘密所在位置。也就是说，它把拦截点放在秘密进入仓库历史之前，但不会自动替团队清理已经存在的历史内容。

实际排查时，我会先把“哪一次提交触发了阻止”和“秘密是否已经进入其他提交”分开看。GitHub 公告给出的处理要求是：从这次推送包含的每个提交中移除秘密后再试。只改最后一个文件、留下前一个提交里的同一段凭据，仍然可能继续被拦截。

这个模型也解释了为什么不要把推送保护当成密钥轮换系统。检测负责阻止进入，撤销、轮换和历史清理仍然需要沿用团队自己的凭据响应流程。

启用时要按三层依赖检查

最容易踩的坑是直接寻找“Block AI-detected secrets”，却没有先满足它的前置开关。仓库管理员可以在设置页进入 Settings > Advanced Security > Secret Protection > AI-detected secrets，然后打开 Block AI-detected secrets。组织和企业管理员则要通过安全配置，把相关能力应用到目标仓库。

官方公告给出的依赖关系可以压缩成三项：

• AI-detected secrets：先允许 AI 检测通用秘密。
• Push protection：提供提交进入仓库前的阻止路径。
• Block AI-detected secrets：把 AI 检测结果接入阻止动作。

如果使用安全配置 REST API，公告列出的字段是 secret_scanning_generic_secrets、secret_scanning_push_protection 和 secret_scanning_generic_secrets_push_protection。下面只展示字段之间的关系；真正请求还需要按组织或企业权限、认证方式和当前 API 文档准备环境。

# 先确认三项能力都由目标安全配置管理，再把配置应用到仓库
curl -L -X PATCH -H "Accept: application/vnd.github+json" -H "Authorization: Bearer " https://api.github.com/orgs/ORG/code-security/configurations/CONFIG_ID -d '{"secret_scanning_generic_secrets":"enabled","secret_scanning_push_protection":"enabled","secret_scanning_generic_secrets_push_protection":"enabled"}'

命令中的令牌、组织名和配置编号只是占位符，不应把真实凭据写进脚本或仓库。更稳妥的做法是先在一个非关键仓库观察阻止位置和团队处理路径，再扩大安全配置的应用范围。

被拦截后怎样处理，哪些结论不能过度延伸

被阻止时先完成两件事：确认报告的位置，并从推送中的每个提交移除秘密。之后重新提交。已有的 bypass 和 delegated bypass 流程仍然适用，但 GitHub 特别强调，代理在绕过或规避阻止前必须先获得授权。对团队来说，这意味着绕过不是“换一种写法继续推送”，而应当留下明确的审批和审计记录。

还要把公告里的限制记住：

• 功能目前是 public preview，且在 push protection 中默认关闭。
• 仓库必须同时具备 AI-detected secrets 和 push protection，才能打开阻止 AI 检测秘密。
• 预览启用后会消耗 AI credits，并从选择加入公开预览开始计费。
• 公告只说明新推送、网页提交和文件上传的覆盖，不等于已经公开承诺对所有历史秘密自动修复。

因此，标题中的“扩展到预定义模式之外”更准确的理解是：推送保护多了一层基于上下文的识别能力，扩大了进入仓库前的拦截面；它没有取消权限管理、秘密轮换、历史清理或人工授权流程。

常见问题

是不是打开 push protection 就自动启用 AI 检测秘密？

不是。官方公告明确要求 AI-detected secrets 和 push protection 都已启用，随后才可以启用 Block AI-detected secrets；该阻止能力默认关闭。

分类器能不能替代已有的秘密扫描规则？

不能。它与基于模式的检测器并行，目标是补充没有已知格式的潜在秘密，而不是让已有检测规则失效。

误报时能不能直接绕过？

是否绕过要遵守仓库、组织或企业的授权流程。公告保留了既有 bypass 与 delegated bypass 工作流；对自动化代理尤其要先拿到授权，再执行绕过动作。

对大多数团队来说，合理的落地顺序是先确认套餐和 AI credits 成本，再在试点仓库打开三项依赖，观察拦截位置、误报处理和秘密响应流程，最后才把安全配置推广到更大范围。这样才能把这次预览更新当作额外的入口防线，而不是一条未经评估的默认规则。