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