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

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

对于泄露的密钥而言，这是一个关键节点。开发者并非变得越来越粗心；他们只是被超越了。那些让开发者能够创建更多软件的工具，也应当承担起更多保护软件的工作。

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

被超越，而非粗心

大约每两秒钟就有一个新密钥出现在公开可见的代码中，过去三年里这一数字每年翻一番。公众舆论很快便倾向于认为 AI 让开发者变得粗心。

在 2024 年第二季度至 2026 年第二季度之间，经过筛查的推送量增长了 2.84 倍，而携带凭据的推送量增长了 2.59 倍。在九个完整季度的数据中，我们未发现每次推送的普遍率存在统计学上可检测的趋势。与此同时，我们发现数据表明，开发者比以往任何时候都更了解意外暴露的风险，并且更不愿意接受这种风险。在同一时期，被开发者覆盖的推送路径阻止比例从 6.63% 线性下降至 3.93%。这些数据挑战了智能体正在导致开发者变得更加粗心的普遍说法。

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

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

预防随计算规模扩展

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

GitHub 的目录通过我们的机密扫描合作伙伴计划覆盖了 150 多家技术合作伙伴。通过合作伙伴计划，我们与参与的机密签发方合作构建检测器并报告公开暴露情况，以便他们能够响应。在 2026 年第二季度，公开扫描成功报告了平均每秒 26 次凭据匹配，包括重复观测。一旦收到通知，大量合作伙伴会立即撤销令牌：OpenAI API（应用程序编程接口） 密钥、Google Cloud 账户凭据、Slack webhooks、Hugging Face 用户令牌、SendGrid 密钥等。所有者可能仍需要替换令牌，但撤销可以在无需等待开发者发现和处理 GitHub 警报的情况下完成。

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

得益于合作伙伴的努力，在过去一个月中，推送保护至少每秒阻止一次机密。对于签发方绑定的凭据，GitHub 阻止的机密数量超过了漏过的数量。我为我们将这一点对开发者而言变得如此平常而感到自豪。

修复的规模取决于人力

当包含额外的机密类型时，推送保护在新检测到的机密进入仓库历史之前阻止了约 30%。不幸的是，我们在凭据已经丢失之后才发现剩余的 70%。而且：

• 预防的规模取决于计算资源，但修复的规模仍然取决于人力。

• 拒绝一次推送消耗的是计算资源；清理一个已经丢失到可见历史中的机密消耗的是开发者的时间和注意力。

• 随着代码量的增长，我们必须预防更多的暴露并减少剩余暴露所需的人力投入，否则引入的漏洞数量将变得难以为继。

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

解决四体问题

在机密越过推送边界之前，阻止它的成本很小，决策是二元的：阻止或允许。一旦越过，同一个字符串就可以对真实系统进行身份验证，成本是无限的。

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

我们将其称为机密保护的“四体问题”：精确率、延迟、吞吐量和成本是相互耦合的约束。预防必须值得开发者花时间。一个适合后续审查的发现可能不足以证明阻止推送的合理性。一个误报会打断开发者，并使下一次阻止更难被信任。一个太慢、太昂贵或难以扩展的检查限制了它能够运行的频率。

推送时在 2 毫秒内提供保护

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

将我们的模型纳入推送保护，使我们能够阻止的密钥数量增加一倍以上。该功能目前处于私有预览阶段。本月晚些时候，该功能将面向 Enterprise Cloud 和 GitHub Teams 上拥有 GitHub Secret Protection 的组织提供。它将消耗 AI 额度。

我们还将把该模型引入推送之外的开发者界面。

• 从今天起，任何拥有 AI 密钥检测的组织都将自动更新到新模型。这些推送后扫描产生的警报仍包含在组织购买的密钥扫描中，无需额外费用。

• 该模型还将随 GitHub Enterprise Server 3.23 以公开预览形式发布，将 AI 检测警报带给 Secret Protection 客户，即使在气隙环境中也是如此。

• 我们正在将该分类器添加到 Copilot CLI 和 Copilot App 的 /security-review 命令中，这样 Copilot 用户即使没有组织的 GitHub Secret Protection 计划，也可以在推送前处理密钥。AI 额度使用将归因于您的 AI 使用洞察中的 GitHub Secret Protection。

展望未来

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

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

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：GitHub Blog

原创地址：https://github.blog/ai-and-ml/github-copilot/secret-protection-must-scale-with-software/