密钥安全防护必须跟上软件生产的速度
如今，GitHub 上每三个 pull request 就有一个涉及 AI agent。而一年前，这个比例还不到十分之一。照这个速度发展下去，未来两年内，推送到 GitHub 的代码可能大部分都出自 agent 之手，其中很多也许永远不会被人类完整读过。
开发者和 agent 的速度越来越快，我们就有责任让安全防护跟上代码生成的加速节奏。这意味着在泄露发生前拦截更多风险，同时让剩余暴露的响应处置更少依赖人工。
对泄露的密钥（secrets）而言，这是一个关键节点。开发者并非越来越粗心，而是被速度甩在了后面。帮助开发者创造更多软件的工具，也应该承担起更多保护这些软件的工作。
在这篇文章中，我将分享支撑这一判断的九个季度数据，并介绍我们与 Microsoft Applied Sciences 合作构建的微调分类器，它把推送保护扩展到了非结构化密钥。该模型能在不到两毫秒内评估一整批候选密钥，有望把我们能阻止的密钥泄露数量翻一倍以上。
被速度超越，而非粗心大意
公开可见的代码中，大约每两秒就会出现一个新密钥，过去三年里逐年翻倍。公共舆论很快就把它归因于 AI 让开发者变得粗心。
从 2024 年二季度到 2026 年二季度，被扫描的推送增长了 2.84 倍，而携带凭证的推送增长了 2.59 倍。在九个完整季度的数据中，我们没有发现单次推送泄露率存在任何统计学上的显著趋势。与此同时，数据表明，开发者比以往任何时候都更了解意外暴露的风险，也更不愿意接受这种风险。同期，推送路径上的拦截被开发者绕过的比例从 6.63% 线性下降到 3.93%。这些数字与“agent 正让开发者变得更粗心”的流行说法相矛盾。
推送量持续增长，泄露率却没有明显上升公开推送推送泄露率202M574M · 2.8×0300M600M0%0.5%1.0%Q2Q3Q4Q1Q2Q3Q4Q1Q22024202520262026 Q2 · 5.74亿次推送 · 0.47% 含密钥公开推送，2024 Q2–2026 Q2。推送泄露率是检出密钥的推送占比。覆盖支持的 provider 模式，包括 GitHub 自家的 token。在固定泄露率下，活动量翻倍意味着预期暴露也翻倍。如果每次暴露都需要同样的人力响应，工作负载也会随之翻倍。人工吊销一个密钥的平均时间约为 40 天；大约 五分之一超过 90 天。我们在加速创造软件的同时，被暴露的凭证却可能持续可用数周甚至数月，因为人工修复的速度根本跟不上开发的节奏。
单靠提醒开发者“多加小心”解决不了这个问题。随着代码量不断增长，我们必须预防更多暴露，并减少剩余暴露所需的人力投入，软件开发才能持续下去。
预防能力可以随算力扩展
过去几年我一直在 GitHub 从事 secret scanning 相关工作，过去一年担任该领域的产品负责人。我们最大的影响力，来自于把检测环节与能够采取行动的系统连接起来。
通过 secret scanning 合作伙伴计划，GitHub 的目录已覆盖 150 多家技术合作伙伴。通过这一计划，我们与参与合作的密钥签发方共同构建检测器，并上报公开暴露的密钥，便于他们及时处置。2026 年 Q2，公开扫描平均每秒成功上报 26 条凭证匹配（含重复观察结果）。收到通知后，大量合作方会立即吊销 token：OpenAI API key、Google Cloud 账号凭证、Slack webhook、Hugging Face 用户 token、SendGrid key 等。所有者可能仍需更换 token，但吊销这一步不必再等开发者发现并处理 GitHub 告警。
Push protection 在更早的环节介入：在可识别的凭据进入仓库历史之前就将其拦截，让开发者或 agent 有机会在暴露发生之前修正改动，而不必事后排查。我们与技术合作伙伴一起，尽可能提升其检测器的精确率，直到有足够把握为开发者社区默认开启这些密钥的 push protection。
多亏合作伙伴的努力，过去一个月里，push protection 平均每秒至少拦截一个密钥。对于 issuer 绑定的凭据，GitHub 拦截的数量已经超过了漏掉的数量。让这一切对开发者来说变得如此平常，我为此感到骄傲。
补救靠人力扩展
把更多密钥类型纳入后，push protection 能在约 30% 新检测到的密钥进入仓库历史之前将其拦下。剩下 70% 的凭据，很遗憾，被发现时已经泄露。而且：
- 预防靠算力扩展，补救却依然靠人力扩展。
- 拒绝一次 push 只耗费算力；清理一个已经进入可见历史的密钥，耗费的却是开发者的时间和注意力。
- 随着代码量增长，我们必须阻止更多暴露，并降低剩余暴露所需的人力投入，否则新引入漏洞的数量将变得不可收拾。
光靠提醒开发者“更小心”无法解决这种失衡。在开发流程中更早、更多地识别出这些密钥，是平台必须承担的工作。
解决四体问题
在一个密钥越过 push 边界之前，拦截它的成本很低，决策也是二元的：放行或阻止。一旦越过之后，同一串字符就能向真实系统完成认证，代价则是无上限的。
很多时候，我们唯一的检测线索只有周围代码和上下文环境。服务商颁发的 token 可能带有可识别的前缀，而内部数据库密码可能完全无结构，没有任何可辨识的模式。我们早已在 push 之后的检测中利用上下文来发现这些密钥，问题在于如何在上下文判断和其他因素之间取得平衡。
我们把这称为密钥防护的“四体问题”：精度、延迟、吞吐量和成本是相互耦合的约束条件。防护必须值得开发者花时间。适合事后审查的发现，未必有理由阻断一次推送。误报会打断开发者，并让下一次阻断更难被信任。而检查太慢、太贵或难以扩展，会限制它能运行的频率。
推送时的防护，2 毫秒内完成
我们全新的 ModernBERT 分类器会在上下文中评估候选密钥，不生成代码或文本。它不仅比现有基于 LLM 的流水线更精准，而且速度极快，批量评估候选值用时不到两毫秒。它还非常省钱，足以大规模运行在关键路径上。
将该模型纳入推送防护后，我们能阻止的密钥数量翻了一倍还多。该功能目前处于私有预览阶段。本月晚些时候，拥有 GitHub Secret Protection 的组织（覆盖 Enterprise Cloud 和 GitHub Teams）即可使用，它会消耗 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。
展望未来
我们期望的未来是：开发者可以放心地把更多工作交给 agent，而不必逐一监督每个请求；组织保护凭证所需的人力，也不再随代码量的增长而增加。我们在用 AI 提升软件生产效率的同时，也应该为开发者社区带来同等的软件安全保护方面的进步。
我们希望人们构建更多软件，而我们保护软件的能力，也应该与创造软件的能力同步增长。