Secret protection must scale with software

The GitHub Blog

The GitHub Blog2026年10月7日

Secret protection must scale with software

6.9内容质量

TL;DR · AI 摘要

Title: Secret protection must scale with software URL Source: Published Time: 2026-10-07T10:45:34-07:00 Markdown Content...

核心要点

主题聚焦：Secret protection must scale with software
来源：The GitHub Blog，建议结合原文判断细节。
AI 分析暂不可用，本条为保底评分与摘要。

#AI#编程#后端#云计算#安全

打开原文

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

当开发者和代理的速度加快时，我们必须确保保护措施能够跟上代码创建的加速节奏。这意味着在泄露发生前阻止更多泄露，并使对剩余暴露的响应减少对人工操作的依赖。

这对泄露的秘密来说是一个关键转折点。开发者并非变得粗心大意，而是被技术发展速度超越。让开发者能够创建更多软件的工具，也应承担更多保护软件的工作。

在本文中，我将分享支持这一论点的九个季度数据。同时，我将介绍与微软应用科学团队共同开发的精细分类器，该分类器可将推送保护扩展到非结构化秘密。该模型可在不到两毫秒的时间内评估一组候选秘密，使我们能够阻止的秘密数量可能增加一倍以上。

被超越，而非粗心

公开代码中每两秒就会出现一个新的秘密，过去三年中这一频率每年翻倍。公共讨论往往急于归咎于AI导致开发者粗心大意。

从2024年第二季度到2026年第二季度，经过筛查的推送量增长了2.84倍，而包含凭证的推送量增长了2.59倍。在九个完整季度的数据中，我们未发现每推送的普及率存在统计学意义上的趋势。同时，我们发现数据表明，开发者比以往更清楚意外暴露的风险，并且越来越不愿意接受这种风险。在同期，开发者覆盖推送路径块的比例呈线性下降，从6.63%降至3.93%。这些数据挑战了“代理导致开发者变得粗心大意”的常见说法。

2026年第二季度 · 5.74亿次推送 · 包含秘密

2024年第二季度至2026年第二季度的公开推送。推送普及率是指检测到秘密的占比。涵盖受支持的提供者模式，包括GitHub自己的令牌。

在固定速率下，活动量翻倍会使预期暴露量翻倍。如果每次暴露都需要相同的人工响应，工作量也会翻倍。手动撤销秘密的平均时间约为40天；约五分之一的案例超过90天。我们正在加速软件的开发，而暴露的凭证可能在数周或数月内仍可使用，因为人工修复无法与开发速度同步。

仅告诉开发者要更加小心无法单独解决这个问题。随着代码量的增长，我们必须阻止更多暴露，并减少剩余暴露所需的人工工作量，以确保软件开发的可持续性。

预防规模与计算能力同步

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

GitHub 的目录通过我们的机密扫描合作伙伴计划覆盖了 150 多个技术合作伙伴。通过该合作伙伴计划，我们与参与机密发行方合作，构建检测器并报告公开泄露情况，以便他们及时响应。2026 年第二季度，公共扫描成功每秒平均报告 26 个凭证匹配，包括重复观测结果。一旦收到通知，大量合作伙伴会立即撤销相关令牌：OpenAI API 密钥、Google Cloud 账户凭证、Slack Webhook、Hugging Face 用户令牌、SendGrid 密钥等。虽然所有者可能仍需更换令牌，但撤销操作无需等待开发者发现并处理 GitHub 警报。

推送保护更早介入。它在凭证进入仓库历史记录前就阻止可识别的凭证，为开发者或代理提供机会在暴露前修正更改。我们与技术合作伙伴合作，尽可能提高检测器的精确率，直到我们确信可以默认为开发者社区提供推送保护。

得益于合作伙伴的努力，过去一个月中，推送保护每秒至少阻止一次机密。就发行方绑定的凭证而言，GitHub 阻止的机密数量多于泄露的机密数量。我为开发者对这一过程的体验变得如此平常感到自豪。

当新增更多机密类型时，推送保护在凭证进入仓库历史记录前阻止约 30% 的新发现机密。我们发现剩下的 70% 是在凭证不幸泄露后才发现的。并且：

预防规模随计算能力增长，但修复仍需依赖人力。
拒绝推送会消耗计算资源；清理已泄露到可见历史记录的机密则会消耗开发者的精力和时间。
随着代码量的增长，我们必须阻止更多暴露，同时减少剩余暴露所需的人力成本，否则引入的漏洞数量将变得不可持续。

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

解决四体问题

在机密跨越推送边界之前，阻止它的成本较低，决策是二元的：阻止或允许。一旦跨越边界，相同的字符串可能在真实系统中进行身份验证，而成本是无限的。

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

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

推送保护在 2 毫秒内完成

视频 4

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` 命令中，这样 Copilot 用户即使没有组织的 GitHub Secret Protection 计划，也能在推送前处理密钥问题。AI 信用额度使用情况将在您的 AI 使用洞察中归因于 GitHub Secret Protection。