GitHub 引入 AI 分类器：将密钥泄露防护扩展至非结构化数据并提速至毫秒级

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

如果开发者和智能体的行动速度加快，我们就有责任确保安全防护措施能够跟上代码创建加速的步伐。这意味着要在泄露发生之前阻止更多泄露，并使针对剩余暴露事件的响应更少依赖人工操作。

对于密钥泄露而言，这是一个关键转折点。开发者并非变得更加粗心，而是被速度甩在了身后。那些让开发者能够创建更多软件的工具，也应该承担更多保护这些软件的工作。

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

是被甩在后面，而非粗心大意

大约每两秒钟，公开可见的代码中就会出现一个新的密钥，过去三年里这一频率每年翻倍。公众舆论往往迅速得出结论，认为 AI 导致开发者变得粗心。

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

推送量增加，但推送中的密钥流行率没有明显上升 公开推送量：202M → 574M · 2.8× 0 | 300M | 600M 0% | 0.5% | 1.0% Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 2024 2025 2026 2026 Q2 · 574M 次推送 · 含密钥 公开推送量，2024 年 Q2–2026 年 Q2。推送流行率是指检测到密钥的推送所占比例。涵盖受支持的提供商模式，包括 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 毫秒内实现推送时的保护

GitHub 基于 AI 的通用密钥检测模型利用周围代码上下文，能够拦截数据库 URL、Kubernetes Secret 清单文件和 Dockerfile 中类似密码的值，同时允许占位符 changeme 通过。

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

将我们的模型纳入推送保护（push protection）功能，使我们能够阻止的密钥泄露数量增加了一倍以上。该功能目前处于私有预览阶段。本月晚些时候，该功能将面向拥有 GitHub Secret Protection 的组织开放，涵盖 Enterprise Cloud 和 GitHub Teams 版本。使用该功能将消耗 AI 积分。

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

• 从今天开始，任何 启用 AI 密钥检测的 组织都将 自动更新到 新模型。 由这些推送后扫描触发的警报仍包含在组织的密钥扫描购买服务中，无需额外付费。
• 该模型也将随 GitHub Enterprise Server 3.23 以公开预览版发布，即使在隔离网络（air-gapped）环境中，也能为 Secret Protection 客户提供 AI 检测到的警报。
• 我们将把分类器添加到 Copilot CLI 和 Copilot App 的 /security-review 命令中，这样即使没有组织的 GitHub Secret Protection 计划，Copilot 用户也能在推送前处理密钥问题。AI 积分的使用情况将在你的 AI 使用洞察数据中归算至 GitHub Secret Protection。

展望未来

我们期望的未来是：开发者可以将更多工作委托给智能体（agents），而无需监督每一个请求；同时，组织为保障凭证安全所需的人力投入不再随着代码量的增长而线性增加。我们在软件生产方面取得的进步，理应同样体现在软件保护方面，这是我们对开发者社区应尽的责任。

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

文章 Secret protection must scale with software 首发于 The GitHub Blog。