GitHub 推出 ModernBERT 分类器以扩展 Secret Protection

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

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

这是泄露密钥问题的一个关键节点。开发者并没有变得更粗心；他们只是跟不上速度。让开发者能够创建更多软件的工具，也应该承担更多保护这些软件的工作。

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

跟不上速度，而非粗心

大约每两秒钟，就会有一个新的密钥出现在公开可见的代码中，并且在过去三年里每年翻倍。公众讨论很容易迅速得出 AI 让开发者变得粗心的结论。

在 2024 年第二季度到 2026 年第二季度之间，经过筛查的推送增长了 2.84 倍，而携带凭证的推送增长了 2.59 倍。在九个完整季度的数据中，我们没有发现关于每次推送中出现比例的统计上可检测趋势。与此同时，我们发现有数据表明，开发者比以往任何时候都更了解意外暴露的风险，也更不愿意接受这种风险。在同一时期，开发者绕过的推送路径拦截占比从 6.63% 线性下降到 3.93%。这些数字对“agent 正在导致开发者变得更粗心”这一常见说法提出了挑战。

推送更多，但推送中出现比例没有明显上升

公开推送

推送中出现比例

202M574M · 2.8×

0300M600M

0%0.5%1.0%

Q2Q3Q4Q1Q2Q3Q4Q1Q2202420252026

2026 Q2 · 574M 次推送 · 0.47% 含有密钥

公开推送，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. 随着代码量增长，我们必须防止更多暴露，并减少处理剩余暴露所需的人力投入，否则引入的漏洞数量将变得难以承受。

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

解决四体问题

在密钥跨过推送边界之前，阻止它的成本很小，决策也是二元的：阻止或允许。跨过之后，同一个字符串就可以对真实系统进行身份验证，而成本没有上限。

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

我们将其称为秘密保护的“四体问题”：精度、延迟、吞吐量和成本是相互耦合的约束。预防措施必须值得开发者花时间去做。一个适合稍后审查的发现，未必值得阻止一次 push。误报会打断开发者，并让下一次阻断更难被信任。过慢、过于昂贵或难以扩展的检查，会限制它能够运行的频率。

在不到 2 ms 的时间内实现 push 阶段的保护

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

将我们的模型纳入 push protection，使我们能够将可阻止的秘密数量提高到原来的两倍以上。该功能目前处于私有预览阶段。本月晚些时候，该功能将面向拥有 GitHub Secret Protection 的 Enterprise Cloud 和 GitHub Teams 组织开放。它将消耗 AI credits。

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

• 从今天开始，任何拥有 AI secret detection 的组织都将自动更新到新模型。 这些 post-push 扫描所产生的警报仍包含在组织购买的 secret scanning 中，不收取额外费用。
• 该模型还将随 GitHub Enterprise Server 3.23 一起发布公开预览版，即使在气隙环境中，也能为 Secret Protection 客户带来 AI 检测到的警报。
• 我们正在将该分类器添加到 Copilot CLI 和 Copilot App 的 /security-review 命令中，这样 Copilot 用户即使不需要组织的 GitHub Secret Protection 计划，也能在 push 之前处理秘密。AI credit 使用量将归因到你的 AI usage insights 中的 GitHub Secret Protection。

展望未来

我们想要的未来是：开发者可以把更多工作托付给代理，而无需监督每一个请求；同时，组织为保障凭据安全所需的人数，不再随着其编写代码量的增加而扩张。我们有责任为开发者社区带来与我们在生产软件方面同样的保护软件进步。

我们希望人们构建更多软件。我们保护软件的能力应当随着创造软件的能力一起增长。

文章 秘密保护必须与软件一起扩展 最先发布在 The GitHub Blog。