GitHub 发布 AI 密钥检测模型，称可阻止的密钥数量将翻倍以上

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

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

对于泄露的密钥来说，这是一个关键时刻。开发者并没有变得更加粗心，而是在速度上被超越了。那些让开发者能够创造更多软件的工具，也应该承担更多保护软件的工作。

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

被超越，而非粗心大意

在公开可见的代码中，大约每两秒就会出现一个新的密钥，过去三年间每年翻一番。公众讨论往往很快得出结论，认为是 AI 让开发者变得粗心。

2024 年 Q2 至 2026 年 Q2 期间，经筛查的推送增长了 2.84 倍，而携带凭证的推送增长了 2.59 倍。纵观九个完整季度的数据，我们没有发现每次推送的密钥检出率存在统计学上可检测的趋势。与此同时，我们发现有数据表明，开发者比以往任何时候都更了解意外暴露的风险，也更不愿意接受这种风险。在同一时期，开发者绕过推送路径阻止的比例从 6.63% 线性下降至 3.93%。这些数字对“智能体正导致开发者变得更加粗心”这一普遍说法提出了质疑。

推送更多，推送检出率未见明显上升

公开推送

推送检出率

202M574M · 2.8×

0300M600M

0%0.5%1.0%

Q2Q3Q4Q1Q2Q3Q4Q1Q2202420252026

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

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

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

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

预防随算力扩展

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

通过我们的密钥扫描合作伙伴计划。，GitHub 的目录涵盖了 150 多个技术合作伙伴。借助这一合作伙伴计划，我们与参与合作的密钥签发方共同构建检测器，并报告公开暴露的情况，以便它们做出响应。2026 年第二季度，公开扫描平均每秒成功报告 26 次凭据匹配（包括重复观测）。收到通知后，这些合作伙伴中的大多数会立即吊销令牌：OpenAI API 密钥、Google Cloud 账户凭据、Slack webhook、Hugging Face 用户令牌、SendGrid 密钥等。所有者可能仍需要更换令牌，但吊销无需等待开发人员发现并处理 GitHub 警报即可完成。

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

多亏了合作伙伴的努力，在过去一个月里，推送保护平均每秒至少拦截一个密钥。就与签发方绑定的凭据而言，GitHub 拦截的密钥比漏掉的更多。让我自豪的是，我们已经让开发人员觉得这再平常不过。

修复随人力扩展

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

预防随算力扩展，但修复仍然随人力扩展。
拒绝一次推送消耗的是算力；清理一个已经进入可见历史、无法挽回的密钥，消耗的则是开发人员的时间和注意力。
随着代码量的增长，我们必须预防更多的泄露，并减少剩余泄露所需的人力投入，否则新引入的漏洞数量将变得难以承受。

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

解决四体问题

在密钥跨越推送边界之前，拦截它的成本很小，而且决策是二元的：拦截或放行。一旦跨越边界，同一字符串就可能向真实系统进行身份验证，成本则变得不可估量。

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

我们将这称为秘密保护的“四体问题”：精确率、延迟、吞吐量和成本是相互耦合的约束条件。预防必须值得开发者投入时间。一个适合稍后审查的发现，可能不足以成为阻止一次推送的理由。误报会打断开发者，并让下一次阻止更难被信任。而过于缓慢、昂贵或难以扩展的检查，则会限制其运行频率。

推送时保护，耗时不到 2 ms

GitHub 的 AI 驱动通用秘密检测模型利用周围的代码上下文，来阻止数据库 URL、Kubernetes Secret 清单和 Dockerfile 中类似密码的值，同时放行占位符 changeme。

我们全新的 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。

展望未来

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

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

文章秘密保护必须随软件一同扩展首发于 The GitHub Blog。