8.0
热点
AI SCORE
编程提效2026-10-08 01:45
GitHub 呼吁：代码安全保护须与软件规模同步扩展
GitHub Blog · AI/ML#GitHub#安全#DevSecOps
Editor brief · 编辑速览
GitHub 官方博文指出开发者创建软件的速度远超安全保护能力增长，呼吁Secret 防护工具必须随开发规模自动扩展。
如今，GitHub 上每三个 Pull Request 中就有一个涉及 AI Agent。一年前，这个数字还不到十分之一。如果保持这个增速，未来两年内，GitHub 上推送的大部分代码可能都将由 Agent 撰写。其中很多可能永远不会被人类完整阅读。
如果开发者 和 Agent 的速度越来越快，我们有责任确保防护措施能够跟上代码生成的加速步伐。这意味着要事前阻止更多泄露，并对残余的泄露事件降低对人工操作的依赖。
这是泄露密钥防护的关键时刻。开发者并没有变得更粗心，而是被速度所超越。使开发者能够创建更多软件的工具，也应该承担更多保护软件的工作。
在这篇文章中，我将分享支撑这一论断的九个季度的数据。我还要介绍我们与微软应用科学部门共同构建的精细调整分类器，它能将推送保护扩展到非结构化密钥。该模型在不到两毫秒内评估整套候选密钥，并且能够将我们能够阻止的密钥数量增加一倍以上。
公开可见的代码中，大约每两秒就会出现一个新的密钥，在过去三年中每年翻一番。公众讨论很快就会归咎于 AI 使开发者变得粗心。
在 2024 年第二季度和 2026 年第二季度之间，经过筛选的推送增长了 2.84 倍，而携带凭证的推送增长了 2.59 倍。在九个完整季度的数据中，我们没有发现关于每次推送流行程度的统计学可检测趋势。同时，我们发现数据表明，开发者比以往任何时候都更了解意外暴露的风险，而且更不愿意接受这种风险。在同一时期，开发者覆盖推送路径阻止的比例从 6.63% 线性下降到 3.93%。这些数据挑战了人们普遍认为 Agent 导致开发者变得更加粗心的说法。
在固定速率下，活动加倍会使预期暴露加倍。如果每次暴露都需要相同的人工响应，工作量也会加倍。手动撤销密钥的平均时间约为 40 天；大约五分之一需要超过 90 天。我们正在加速软件的创建，而暴露的凭证可能仍然可以使用数周或数月，因为人工修复无法与开发速度保持相同的规模。
仅靠告诉开发者要更加小心是无法解决这个问题的。如果软件开发生态要保持可持续发展，随着代码量的增长，我们必须防止更多的暴露，并减少剩余暴露所需的人工工作。
过去几年我一直在 GitHub 从事密钥扫描工作，过去一年担任该领域的产品负责人。我们最大的影响来自于将检测与能够采取行动的系统连接起来。
GitHub 的目录通过密钥扫描合作伙伴计划覆盖了 150 多个技术合作伙伴。通过我们的合作伙伴计划，我们与参与的密钥颁发者合作，构建检测器并报告公开暴露，以便他们能够做出响应。在 2026 年第二季度，公开扫描成功报告了平均每秒 26 次凭证匹配，包括重复观察。一旦被通知，这些合作伙伴中的很大一部分会立即撤销令牌：OpenAI API keys、Google Cloud account credentials、Slack webhooks、Hugging Face user tokens、SendGrid keys 等。所有者可能仍然需要替换令牌，但撤销可以在不等待开发者查找和处理 GitHub 警报的情况下发生。
推送保护在更早的阶段进行干预。它在可识别的凭证进入仓库历史之前阻止它们，让开发者或 Agent 有机会在需要调查的暴露发生之前纠正更改。我们与我们的技术合作伙伴合作，尽可能提高其检测器的精确率，直到我们有足够的信心为开发者社区默认推送保护这些密钥。
多亏了合作伙伴的努力，在过去一个月中，推送保护至少每秒阻止一次密钥。当涉及到颁发者绑定的凭证时，GitHub 阻止的密钥数量超过了泄露的数量。我为我们让开发者感到这种保护如此平常而感到自豪。
加上其他密钥类型，推送保护在约 30% 的新检测到的密钥进入仓库历史之前阻止它们。我们发现剩余的 70% 是在凭证已经不幸丢失之后的。
预防可以通过计算扩展，但修复仍然需要人工扩展。
拒绝推送消耗计算资源；清理已经丢失到可见历史中的密钥则消耗开发者的时间和注意力。
随着代码量的增长，我们必须防止更多的暴露，并减少剩余暴露所需的人工工作，否则引入的漏洞量将变得难以承受。仅靠告诉开发者要更加小心无法解决这种不平衡。在开发流程的更早阶段识别更多这些密钥，是平台必须承担的工作。
在密钥越过推送边界之前，阻止它的成本很小，决策是二元的：阻止或允许。越过之后，同一个字符串可以向真实系统进行身份验证，成本变得无界限。
在许多情况下，我们唯一的检测线索可能是周围的代码和世界上下文。提供商颁发的令牌可能具有可识别的前缀。内部数据库密码可能完全没有结构，没有任何可识别的模式。我们已经在推送后使用上下文来查找这些密钥；问题是在平衡这种上下文感知判断与其他因素。
我们将这称为密钥保护的"四体问题"：精确性、延迟、吞吐量 和成本是耦合的约束。预防必须值得开发者的时间。适合稍后审查的发现可能不足以证明阻止推送是合理的。误报会打断开发者，并使下一次阻止更难被信任。太慢、太昂贵或难以扩展的检查限制了它可以运行的频率。
GitHub 的 AI 驱动的通用密钥检测模型利用周围的代码上下文来阻止数据库 URL、Kubernetes Secret manifest 和 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 命令中，这样 Copilot 用户即使不需要组织的 GitHub Secret Protection 计划，也可以在推送之前处理密钥。AI 积分使用将归因于 GitHub Secret Protection 在您的 AI 使用洞察中。
我们想要的未来是开发者可以将更多工作委托给 Agent 而无需监督每个请求，而且组织需要保持其凭证安全所需的人数不再与其编写的代码量成正比。我们对开发者社区在保护软件方面负有与在生产软件方面相同的进步责任。
我们希望人们构建更多软件。我们保护它的能力应该与我们创建它的能力同步增长。
Erin Havens 是 GitHub 的产品经理，专注于安全产品。跨 Secret Protection 和 Dependabot 等产品交付了 100+ 次（而且还在继续）。
我们推出 ReviewBench，这是一个基于代表性 GitHub Pull Request、多源真实数据、校准评估和生产对齐指标的代码审查 Agent 基准。
学会指导 AI Agent，批判性地审查它们的输出，并将技术判断保持在工作流程的中心。
用简单的英语描述你需要的界面，然后让 Agent 构建一个你可以使用和更新的实时界面——这样你就可以减少适应工具的时间，更多地时间用于完成工作。