GitHub 推出基于 ModernBERT 的 AI 通用密钥检测模型扩展 push protection

开发者并不是变得越来越粗心，而是被时代甩在了后面。让开发者能创造更多软件的工具，也应当承担起更多保护这些软件的工作。

2026年10月7日

|

7分钟

• 分享：

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

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

这是密钥泄露的一个关键节点。开发者并不是变得越来越粗心，而是被时代甩在了后面。让开发者能创造更多软件的工具，也应当承担起更多保护这些软件的工作。

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

被时代甩下，而非粗心大意

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

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

2026年第2季度 · 5.74亿次推送 · 含密钥

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

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

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

预防随算力扩展

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

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

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

得益于合作伙伴的努力，在过去一个月里，推送保护至少每秒拦截一次密钥。就与签发方绑定的凭据而言，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 客户带来 AI 检测的警报。
• 我们将把该分类器添加到 Copilot CLI 和 Copilot App 的 /security-review 命令中，这样 Copilot 用户即使没有组织的 GitHub Secret Protection 计划，也能在推送前处理密钥。AI 额度的使用将归入你 AI 使用洞察中的 GitHub Secret Protection。

展望未来

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

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

作者：

Erin Havens 是 GitHub 的产品经理，专注于安全产品。在 Secret Protection 和 Dependabot 等产品中发布了 100 多个功能（且仍在增加）。

相关文章

我们也做新闻通讯

在我们的双周开发者专属新闻通讯中发现技巧、技术指南和最佳实践。