密钥保护必须与软件同步扩展

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

如果开发者和智能体的速度更快，我们就有责任确保保护措施跟上代码创建加速的步伐。这意味着在更多泄露发生之前加以预防，并使对仍然发生的暴露的响应更少依赖人工。

对于泄露的密钥来说，这是一个关键时刻。开发者并没有变得更加粗心，他们只是被超越了。 让开发者能创建更多软件的工具，也应该承担更多保护软件的工作。

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

被超越，而非粗心

在公开可见的代码中，大约每两秒就会出现一个新密钥，过去三年每年翻一番。公众舆论很快跳到 AI 让开发者变得粗心这一观点上。

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

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

仅靠告诫开发者更加小心，无法解决这个问题。随着代码量的增长，我们必须预防更多暴露，并减少仍然发生的暴露所需的人工投入，这样软件开发才能保持可持续。

预防随算力扩展

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

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

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

感谢合作伙伴的努力，过去一个月里，推送保护平均每秒至少阻止了一次密钥泄露。对于与颁发者绑定的凭据，GitHub 阻止的密钥数量多于漏掉的。我很自豪的是，我们已让开发者对这一切习以为常。

修复工作随人力扩展

在纳入更多密钥类型后，推送保护能在约30%新检测到的密钥进入仓库历史之前将其拦截。而其余70%，我们只能在凭据不幸已经泄露之后才发现。并且：

1. 预防随算力扩展，但修复仍然随人力扩展。
2. 拒绝一次推送消耗的是算力；清理一个已经进入可见历史的密钥，消耗的是开发者的时间和注意力。
3. 随着代码量不断增长，我们必须预防更多暴露并降低剩余暴露所需的人力投入，否则被引入的漏洞数量将变得无法承受。

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

解决四体问题

在密钥跨越推送边界之前,阻止它的成本很小,而且决策是二元的:阻止或放行。一旦跨越之后,同一个字符串就可能向真实系统进行身份验证,成本则是无上限的。

在许多情况下,我们唯一的检测线索可能只是周围的代码和上下文环境。提供商颁发的令牌可能有可识别的前缀,而内部数据库密码可能完全无结构,没有任何可识别的模式。我们此前已经在推送后利用上下文来发现这些密钥;问题在于如何平衡这种基于上下文的判断与其他因素。

我们将其称为密钥保护的“四体问题”: 精度、延迟、吞吐量和成本 是相互耦合的约束条件。防范措施必须值得开发者花时间。适合事后审查的发现结果,可能不足以证明应该阻止一次推送。误报会打断开发者,并使下一个阻止决定更难被信任。检查太慢、太昂贵或难以扩展,则会限制其运行频率。

推送时的保护,2毫秒内完成

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

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

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

• 从今天开始,任何 拥有 AI 密钥检测的组织 都将 被 自动 更新到 新模型。 从这些推送后扫描中打开的警报,仍包含在组织购买的密钥扫描服务中,无需额外费用。
• 该模型还将随 GitHub Enterprise Server 3.23 以公开预览形式发布,让 Secret Protection 客户即使在物理隔离(air-gapped)环境中也能使用 AI 检测的警报。
• 我们正在 将分类器添加到 /security-review 用于 Copilot CLI 和 Copilot App 的命令中,这样即使没有组织的 GitHub Secret Protection 计划,Copilot 用户也可以在推送之前处理密钥。AI 额度使用情况将在您的 AI 使用洞察中归入 GitHub Secret Protection。

展望未来

我们期望的未来是:开发者可以将更多工作托付给智能体,而无需监督每一个请求;组织为保护凭证安全所需的人员数量,不再随其编写的代码量而扩展。我们欠开发者社区的是:在保护软件方面取得与生产软件方面同样的进步。

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

这篇博文 机密保护必须随软件一起扩展 首发于 The GitHub Blog.