GitHub 指出密钥保护必须随软件规模同步扩展

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

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

这是密钥泄露的关键节点。开发者并非变得更加粗心；他们只是被速度甩在了后面。让开发者创建更多软件的工具，也应承担更多保护软件的工作。

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

被速度超越，而非粗心

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

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

推送更多，推送发生率未见明显上升

公开推送

推送发生率

202M574M · 2.8×

0300M600M

0%0.5%1.0%

Q2Q3Q4Q1Q2Q3Q4Q1Q2202420252026

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

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

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

仅仅告诉开发者更加小心，本身无法解决这个问题。随着代码量增长，如果我们希望软件开发保持可持续，就必须阻止更多暴露，并减少那些仍然存在的暴露所需的人力。

预防随算力扩展

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

GitHub 的目录通过我们的 密钥扫描合作伙伴计划覆盖了 150 多家技术合作伙伴。通过合作伙伴计划，我们与参与的密钥签发方合作，构建检测器并报告公开泄露，以便他们能够响应。在 Q2 2026，公开扫描成功报告的凭证匹配平均每秒 26 次，包括重复观测。一旦收到通知，这些合作伙伴中的很大一部分会立即撤销令牌：OpenAI API keys、Google Cloud account credentials、Slack webhooks、Hugging Face user tokens、SendGrid keys 等。所有者可能仍需更换令牌，但撤销可以在不等待开发者发现并处理 GitHub 警报的情况下完成。

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

得益于合作伙伴的努力，在过去一个月里，推送保护至少每秒拦截一次密钥。就签发方绑定的凭证而言，GitHub 拦截的密钥多于漏过的密钥。我为能让开发者觉得这已是寻常之事而感到自豪。

补救随人力扩展

若把其他密钥类型也计算在内，推送保护会在约 30% 的新检测到的密钥进入仓库历史之前将其拦截。遗憾的是，其余 70% 是在凭证已经丢失之后才被我们发现的。而且：

1. 预防随算力扩展，但补救仍随人力扩展。
2. 拒绝一次推送耗费的是算力；清理已经丢失到可见历史中的密钥，耗费的是开发者的时间和注意力。
3. 随着代码量增长，我们必须预防更多泄露，并减少处理那些仍然发生的泄露所需的人力，否则引入的漏洞数量将变得难以承受。

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

解决四体问题

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

在许多情况下，我们唯一的检测线索可能是周围的代码和世界上下文。提供商签发的令牌可能带有可识别的前缀。内部数据库密码则可能完全没有结构，根本没有任何识别模式。我们此前已经在推送之后借助上下文来发现这些密钥；问题在于如何将这种上下文感知判断与其他因素加以平衡。

我们将此称为密钥保护的“四体问题”：精度、延迟、吞吐量和成本是相互耦合的约束。防护必须值得开发者投入时间。适合稍后审查的发现，未必足以成为拦截一次 push 的理由。误报会打断开发者，并让下一次拦截更难获得信任。检查若过于缓慢、昂贵或难以扩展，就会限制其可运行的频率。

在 push 时于 2 ms 内完成防护

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

将我们的模型纳入 push 防护后，我们能够阻止的密钥数量有望达到原先的两倍以上。该功能目前处于私人预览阶段。本月晚些时候，该功能将向 Enterprise Cloud 和 GitHub Teams 中拥有 GitHub Secret Protection 的组织提供。它将消耗 AI credits。

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

• 即日起，任何 拥有 AI 密钥检测的组织 都 将 被 自动 更新为 新模型。 由这些 push 后扫描开启的警报，仍包含在组织购买的密钥扫描之中，无需额外费用。
• 该 模型还将随 GitHub Enterprise Server 3.23 一同发布 并处于公开预览阶段，即使在气隙环境中，也能为 Secret Protection 客户带来 AI 检测警报。
• 我们正 将分类器加入 Copilot CLI 与 Copilot App 的 /security-review 命令，以便 Copilot 用户即使没有组织的 GitHub Secret Protection 计划，也能在 push 之前处理密钥。AI credit 用量将在你的 AI 使用洞察中归属于 GitHub Secret Protection。

展望未来

我们希望的未来是：开发者可以将更多工作托付给智能体，而无需监督每一次请求；组织为保障凭据安全所需的人数，也不再随其编写的代码量而增长。我们在生产软件方面所交付的进步，同样应当体现在保护软件上，这是我们对开发者社区应尽的责任。

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

文章 密钥保护必须与软件同步扩展 首发于 The GitHub Blog。