GitHub 推出基于 ModernBERT 的通用密钥检测模型，扩展推送保护

开发者并非变得越来越粗心；他们只是被甩在了后面。让开发者能够创建更多软件的工具，也应当承担起更多保护这些软件的工作。

2026年10月7日

|

7分钟

• 分享：

如今，GitHub 上每三个拉取请求中就有一个涉及 AI 智能体。一年前，这个数字还不到十分之一。如果这一速度保持下去，未来两年内，推送到 GitHub 的大部分代码可能都由智能体编写。其中许多代码可能永远不会被人类完整阅读。

如果开发者和智能体行动得更快，我们就有责任确保防护能跟上代码创建的加速步伐。这意味着要在更多泄露发生之前加以阻止，并让对仍然存在的暴露的响应更少依赖人工操作。

这是泄露密钥问题的一个关键节点。开发者并非变得越来越粗心；他们只是被甩在了后面。让开发者能够创建更多软件的工具，也应当承担起更多保护这些软件的工作。

在本文中，我分享了支撑这一说法的九个季度的数据。我还介绍了我们与 Microsoft Applied Sciences 共同构建的微调分类器，它将推送保护扩展到非结构化密钥。该模型能在不到两毫秒内评估一整组候选密钥，并可能使我们能够阻止的密钥数量增加一倍以上。

被甩在后面，而非粗心

大约每两秒钟，公开可见的代码中就会出现一个新的密钥，过去三年里这一数字每年翻一番。公众舆论很快便认定是 AI 让开发者变得粗心。

在 2024 年第二季度到 2026 年第二季度之间，经过筛查的推送增长了 2.84 倍，而携带凭据的推送增长了 2.59 倍。在九个完整季度的数据中，我们未发现每次推送的普遍率存在统计学上可检测的趋势。与此同时，我们发现数据表明，开发者比以往任何时候都更了解意外暴露的风险，并且更不愿意接受这种风险。在同一时期，被开发者覆盖的推送路径阻止占比从 6.63% 线性下降至 3.93%。这些数字挑战了智能体正导致开发者变得更加粗心的普遍说法。

2026 年第二季度 · 5.74 亿次推送 · 含密钥

公开推送，2024 年第二季度至 2026 年第二季度。推送普遍率是指检测到密钥的推送占比。涵盖受支持的提供商模式，包括 GitHub 自身的令牌。

在固定比率下，活动翻倍会使预期暴露翻倍。如果每次暴露都需要相同的人工响应，工作量也会翻倍。手动撤销密钥的平均时间徘徊在 40 天左右；大约五分之一超过 90 天。我们正在加速软件的创建，而暴露的凭据却可能保持可用数周或数月，因为人工修复无法与开发同步扩展。

仅仅告诉开发者要更加小心，本身并不能解决这个问题。随着代码量的增长，如果软件开发要可持续，我们就必须阻止更多暴露，并减少剩余暴露所需的人工投入。

防护随算力扩展

过去几年我一直在 GitHub 从事密钥扫描工作，过去一年担任该领域的产品负责人。我们最大的影响来自于将检测与能够采取行动的系统连接起来。

GitHub 的目录通过我们的秘密扫描合作伙伴计划覆盖了 150 多家技术合作伙伴。通过该合作伙伴计划，我们与参与的秘密签发方合作构建检测器并报告公开暴露情况，以便他们能够做出响应。在 2026 年第二季度，公开扫描成功报告了平均每秒 26 次凭据匹配，包括重复观测。一旦收到通知，大量合作伙伴会立即撤销令牌：OpenAI API 密钥、Google Cloud 账户凭据、Slack webhook、Hugging Face 用户令牌、SendGrid 密钥等。所有者可能仍需替换令牌，但撤销无需等待开发者发现并处理 GitHub 警报即可完成。

推送保护介入得更早。它在可识别的凭据进入仓库历史之前就将其阻止，让开发者或代理有机会在出现需要调查的暴露之前修正更改。我们与技术合作伙伴合作，尽可能提高其检测器的精确率，直到我们有足够信心为开发者社区默认对这些秘密启用推送保护。

得益于合作伙伴的努力，在过去一个月里，推送保护至少每秒阻止一次秘密。对于签发方绑定的凭据，GitHub 阻止的秘密多于漏过的秘密。我为我们已经让开发者对此习以为常而感到自豪。

当包含更多秘密类型时，推送保护会在约 30% 的新检测到的秘密进入仓库历史之前将其阻止。遗憾的是，我们是在凭据已经泄露之后才发现其余 70%。而且：

1. 预防随算力扩展，但修复仍随人力扩展。
2. 拒绝一次推送消耗算力；清理一个已经泄露到可见历史中的秘密消耗开发者的时间和注意力。
3. 随着代码量的增长，我们必须预防更多暴露并减少剩余暴露所需的人力投入，否则引入的漏洞数量将变得难以为继。

告诉开发者要更加小心无法解决这种失衡。在开发流程中更早地识别更多此类秘密，是平台必须承担的工作。

解决四体问题

在秘密越过推送边界之前，阻止它的成本很小，且决策是二元的：阻止或允许。一旦越过，同一个字符串就可以向真实系统进行身份验证，成本则变得没有上限。

在许多情况下，我们唯一的检测线索可能是周围的代码和世界上下文。提供商签发的令牌可能有可识别的前缀。内部数据库密码可能完全无结构，没有任何可识别的模式。我们已经在推送后使用上下文来查找这些秘密；问题在于如何在这种上下文感知判断与其他因素之间取得平衡。

我们将其称为秘密保护的“四体问题”：精确率、延迟、吞吐量和成本是相互耦合的约束。预防必须值得开发者花时间。适合后续审查的发现可能不足以证明阻止一次推送是合理的。误报会打断开发者，并使下一次阻止更难被信任。检查如果太慢、太贵或难以扩展，就会限制其运行频率。

在 2 毫秒内实现推送时保护

我们全新的 ModernBERT 分类器在上下文中评估候选密钥，无需生成代码或文本。它不仅比现有的基于 LLM 的流水线更精确，而且速度极快，能在两毫秒内评估候选批次。它还具有极高的成本效益，足以在关键路径上大规模运行。

将我们的模型纳入推送保护，使我们能够阻止的密钥数量增加一倍以上。该功能目前处于私有预览阶段。本月晚些时候，该功能将面向 Enterprise Cloud 和 GitHub Teams 中拥有 GitHub Secret Protection 的组织提供。它将消耗 AI 额度。

我们还将把该模型带到推送之外的开发者界面。

• 从今天起，任何 拥有 AI 密钥检测的组织 都将 自动 更新到 新模型。 这些推送后扫描产生的警报仍包含在组织购买的密钥扫描中，无需额外费用。
• 该 模型还将随 GitHub Enterprise Server 3.23 一起发布 ，处于公开预览阶段，即使在气隙环境中也能为 Secret Protection 客户带来 AI 检测的警报。
• 我们 正在将分类器添加到 Copilot CLI 和 Copilot App 的 /security-review 命令中，这样 Copilot 用户即使没有组织的 GitHub Secret Protection 计划，也能在推送前处理密钥。AI 额度使用将归因于您 AI 使用情况洞察中的 GitHub Secret Protection。

展望未来

我们想要的未来是，开发者可以将更多工作委托给代理，而无需监督每一个请求；也是组织维护凭据安全所需的人员数量不再随其编写的代码量而增长。我们欠开发者社区的，是在保护软件方面取得与我们在生产软件方面同样的进步。

我们希望人们构建更多软件。我们保护软件的能力应当与创造软件的能力同步增长。

作者

Erin Havens 是 GitHub 的产品经理，专注于安全产品。在 Secret Protection 和 Dependabot 等产品中交付了 100 多项功能（且仍在增加）。

相关文章

我们也做新闻通讯

在我们的双周开发者专属新闻通讯中，探索技巧、技术指南和最佳实践。