作者Erin Havens排版Alan Wang开发者并不是变得越来越粗心而是软件开发的速度已经超出了安全防护的跟进速度。帮助开发者更高效地开发软件的工具也应当承担更多密钥保护的工作。如今GitHub 上每三个拉取请求中就有一个涉及 AI 智能体。一年前这一比例还不到十分之一。如果这一趋势持续下去那么在未来两年内GitHub 上提交的大部分代码都可能由智能体编写。其中相当一部分代码可能从未被人类完整阅读过。当开发者和智能体的工作速度不断加快时我们有责任确保安全防护能够跟上代码创建速度的提升。这意味着我们需要在密钥泄露发生之前阻止更多泄露事件并降低对已发生泄露事件进行响应时对人工操作的依赖。对于密钥泄露问题而言这是一个关键的转折点。开发者并不是变得越来越粗心而是开发速度已经超出了安全防护的跟进速度。帮助开发者更高效地开发软件的工具也应当承担更多保护软件安全的工作。在这篇文章中我将分享支撑这一观点的九个季度的数据并介绍我们与 Microsoft Applied Sciences 合作开发的一款经过微调的分类器用于将推送保护扩展到非结构化密钥。该模型能够在不到两毫秒的时间内评估一组候选密钥有望使我们能够阻止的密钥泄露数量增加一倍以上。速度跟不上而非开发者粗心过去三年中公开可见的代码中每隔约两秒就会出现一个新的密钥而且这一数量每年都在翻倍。面对这一现象公众舆论很容易将问题归咎于 AI认为 AI 让开发者变得粗心。从 2024 年第二季度到 2026 年第二季度经过筛查的代码推送量增长了 2.84 倍而包含凭证的推送量增长了 2.59 倍。在九个完整季度的数据中我们没有发现每次推送中密钥出现率存在统计上显著的变化趋势。与此同时我们发现了一些数据表明开发者比以往更加了解意外泄露的风险也更不愿意接受这种风险。在同一时期开发者主动覆盖推送流程拦截措施的比例从 6.63% 线性下降至 3.93%。这些数据对一种常见说法提出了质疑智能体正在让开发者变得越来越粗心。推送量持续增长但单次推送中的密钥出现率并未明显上升公开推送数据时间范围为 2024 年第二季度至 2026 年第二季度。推送中的密钥出现率指检测到密钥的推送所占的比例。统计范围涵盖受支持的提供商密钥模式包括 GitHub 自身的令牌。如果密钥出现率保持不变那么活动量翻倍预期的泄露事件数量也会翻倍。如果每次泄露都需要投入同样的人力进行响应工作量也会随之翻倍。人工撤销密钥的平均耗时徘徊在 40 天左右大约 五分之一的密钥需要超过 90 天才能撤销。我们正在加速软件开发但已经暴露的凭证仍可能在数周甚至数月内保持可用因为人工修复的速度无法与开发速度同步增长。仅仅要求开发者更加谨慎并不能从根本上解决这个问题。随着代码量不断增长如果我们希望软件开发能够持续发展就必须阻止更多泄露事件并减少处理剩余泄露事件所需的人工投入。通过计算能力扩展预防能力过去几年我一直在 GitHub 从事密钥扫描工作过去一年则担任这一领域的产品负责人。我们取得的最大成效来自将检测能力与能够采取实际行动的系统连接起来。通过 密钥扫描合作伙伴计划GitHub 的合作伙伴目录已涵盖 150 多家技术合作伙伴。我们与参与计划的密钥发行方合作构建检测器并报告公开泄露事件以便他们采取相应措施。2026 年第二季度公开扫描成功报告的凭证匹配平均每秒达到 26 次其中包括重复发现的情况。收到通知后许多合作伙伴会立即撤销相应令牌例如 OpenAI API 密钥、Google Cloud 账户凭证、Slack Webhook、Hugging Face 用户令牌以及 SendGrid 密钥等。密钥所有者可能仍需要更换令牌但撤销操作可以在开发者发现并处理 GitHub 告警之前完成无须等待人工介入。推送保护则会更早介入。它能够在可识别的凭证进入代码仓库历史记录之前将其拦截让开发者或智能体有机会修正代码变更避免后续产生需要调查的泄露事件。我们与技术合作伙伴密切合作尽可能提高检测器的精确率直到我们有足够的信心能够默认启用这些密钥的推送保护为开发者社区提供防护。得益于合作伙伴的努力在过去一个月中推送保护平均每秒至少成功拦截一次密钥提交。对于与发行方绑定的凭证GitHub 拦截的密钥数量已经超过了未能拦截、最终泄露的数量。我很自豪我们已经让这种保护机制成为开发者日常工作中再自然不过的一部分。通过人力扩展修复能力将更多类型的密钥纳入检测范围后推送保护能够在新发现的密钥进入代码仓库历史记录之前拦截其中约 30%。遗憾的是其余 70% 的密钥是在凭证已经泄露之后才被发现的。此外还有以下几点值得注意预防能力可以随着计算能力的提升而扩展但修复能力仍然依赖人力。拒绝一次代码推送只需要消耗计算资源而清理已经进入公开历史记录的泄露密钥则需要占用开发者的时间和精力。随着代码量不断增长我们必须阻止更多泄露事件并减少处理剩余事件所需的人工投入否则新增漏洞的数量将变得难以承受。仅仅要求开发者更加谨慎无法解决这种不平衡。更早地在开发流程中识别出更多此类密钥是平台必须承担的工作。解决密钥保护的「四体问题」在密钥越过推送边界之前拦截它的成本很低而且决策是二元的阻止或放行。一旦密钥越过这道边界同一字符串就可能用于验证真实系统的身份而后续成本则可能没有上限。在许多情况下我们唯一的检测线索可能就是密钥周围的代码以及相关上下文。由服务提供商发行的令牌可能具有可识别的前缀而内部数据库密码则可能完全没有固定结构也不存在任何可用于识别的模式。此前我们已经在推送完成后利用上下文信息查找这类密钥真正的问题在于如何在结合上下文进行判断的同时平衡其他因素。我们将这一问题称为密钥保护的「四体问题」精确率、延迟、吞吐量和成本是彼此关联、相互制约的约束条件。预防机制必须值得开发者投入时间。适合留待后续审核的检测结果未必值得直接阻止一次推送。误报会打断开发者的工作也会降低他们对后续拦截提示的信任。如果检查过程过慢、成本过高或难以扩展就会限制它的运行频率。在推送阶段实现不到 2 毫秒的保护在推送阶段实现不到 2 毫秒的保护GitHub 基于 AI 的通用密钥检测模型会利用周围代码的上下文拦截数据库 URL、Kubernetes Secret 清单和 Dockerfile 中类似密码的值同时允许占位符changeme通过。我们新推出的 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命令中。这样一来即使没有组织级 GitHub Secret Protection 计划Copilot 用户也能够在推送代码之前处理密钥问题。在 AI 使用情况分析中这部分 AI 积分消耗将归属于 GitHub Secret Protection。展望未来我们希望实现这样的未来开发者能够放心地将更多工作交给智能体而不必监督每一项请求组织也不再需要随着代码量的增长持续增加保障凭证安全所需的人力。我们有责任在软件安全保护方面为开发者社区带来与软件生产效率提升相匹配的进步。我们希望人们能够开发更多软件。我们保护软件的能力应当随着我们创造软件的能力一同增长。