GitHub 主张密钥保护应跟上软件增长，介绍 ModernBERT 检测模型

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

如果开发者和智能体的速度加快，我们就有责任确保护护措施跟上代码创建速度的提升。这意味着要在泄露发生前阻止更多泄露，并让对其余泄露事件的响应减少对人工操作的依赖。

对于机密信息泄露问题，这是一个关键节点。开发者并非变得更加粗心，而是跟不上速度。让开发者能够创建更多软件的工具，也应该承担更多保护软件的工作。

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

是跟不上速度，而非粗心大意

公开可见的代码中，大约每两秒就会出现一条新的机密信息，过去三年来，这一数量每年都翻一番。公众讨论往往迅速将其归因于 AI 让开发者变得粗心。

从 Q2 2024 到 Q2 2026，接受筛查的推送量增至原来的 2.84 倍，而携带凭据的推送量增至原来的 2.59 倍。在九个完整季度的数据中，我们未发现每次推送携带凭据的比例存在统计上可检测到的趋势。与此同时，我们发现的数据表明，开发者比以往任何时候都更了解意外泄露的风险，也更不愿意接受这种风险。同一时期，开发者越过推送流程拦截的比例从 6.63% 线性下降至 3.93%。这些数字对“智能体正导致开发者变得更加粗心”这一常见说法提出了质疑。

推送量增加，携带机密信息的比例未明显上升

公开推送

推送中机密信息的检出比例

202M574M · 2.8×

0300M600M

0%0.5%1.0%

Q2Q3Q4Q1Q2Q3Q4Q1Q2202420252026

2026 Q2 · 574M 次推送 · 0.47% 含有机密信息

公开推送，Q2 2024–Q2 2026。推送中机密信息的检出比例，是指检测到机密信息的推送所占比例。涵盖受支持的提供商模式，包括 GitHub 自身的令牌。

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

仅仅要求开发者更加小心，并不能解决这一问题。随着代码量增长，要让软件开发保持可持续性，我们就必须防止更多泄露，并减少处理其余泄露所需的人工投入。

预防能力随算力扩展

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

通过我们的机密扫描合作伙伴计划，GitHub 的检测目录已覆盖超过 150 家技术合作伙伴。通过该计划，我们与参与其中的机密签发方合作，开发检测器并报告公开泄露事件，以便他们作出响应。在 Q2 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 命令中，这样，即使无需组织的 GitHub Secret Protection 套餐，Copilot 用户也能在推送前处理机密。AI 额度用量将在你的 AI 使用情况洞察中归入 GitHub Secret Protection。

展望未来

我们希望，在未来，开发者可以将更多工作放心交给智能体，而不必监督每一次请求；组织为保障凭据安全所需的人员数量，也不再随着其编写的代码量增长。我们有责任为开发者社区在软件保护方面带来与软件生产方面同等的进步。

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

文章《机密保护必须与软件同步扩展》最先发表于 GitHub 博客。