秘密保护必须与软件一起扩展
开发人员并没有变得更加粗心，而是变得更加粗心。他们正在被超越。让开发人员创建更多软件的工具也应该承担更多的保护软件的工作。秘密保护必须随软件扩展一文首先出现在 GitHub 博客上。
来自 GitHub AI 的官方动态，版本与适用范围以发布方说明为准。
GitHub AI · 查看官方发布中文机器翻译 · 原文附后
正文 · 来源原文
Erin Havens 是 GitHub 的产品经理，专注于安全产品。 Secret Protection 和 Dependabot 等产品有 100 多个发货（并且还在增加）。
如今，GitHub 上三分之一的拉取请求涉及人工智能代理。一年前，这个数字还不到十分之一。如果保持这个速度，在接下来的两年内，推送到 GitHub 的大部分代码都可以由代理编写。其中大部分内容可能永远不会被人类完全阅读。
如果开发人员和代理行动得更快，我们就有责任确保保护跟上代码创建的加速速度。这意味着在更多泄漏发生之前防止更多泄漏，并使对泄漏的响应不再依赖于人工操作。
这是泄密的关键点。开发人员并没有变得更加粗心，而是变得更加粗心。他们正在被超越。让开发人员创建更多软件的工具也应该承担更多的保护软件的工作。
在这篇文章中，我分享了这一说法背后的九个季度的数据。我还介绍了我们与 Microsoft Applied Sciences 一起构建的微调分类器，以将推送保护扩展到非结构化机密。该模型在不到两毫秒的时间内评估一整套候选秘密，并且可以使我们可以阻止的秘密数量增加一倍以上。
超越，不粗心
公开可见的代码中大约每两秒就会出现一次新的秘密，在过去三年中每年增加一倍。公众很快就认为人工智能让开发人员变得粗心。
从 2024 年第二季度到 2026 年第二季度，经过筛选的推送增长了 2.84 倍，而带有凭据的推送增长了 2.59 倍。在九个完整季度的数据中，我们没有发现有关每次推送流行率的统计上可检测的趋势。与此同时，我们发现数据表明，开发人员比以往任何时候都更了解意外暴露的风险，并且不太愿意接受这种风险。同期，被开发商覆盖的推路区块比例从 6.63% 线性下降至 3.93%。这些数字挑战了普遍的说法，即代理商导致开发商变得更加粗心。
更多推送，推送流行率没有明显上升
2026 年第 2 季度 · 5.74 亿次推送 · 0.47% 有秘密
在固定利率下，活动加倍会使预期风险敞口加倍。如果每次暴露都需要相同的人类反应，那么工作量也会加倍。手动撤销机密的平均时间徘徊在 40 天左右；大约五分之一的时间超过 90 天。我们正在加速软件的创建，而暴露的凭据可以保持可用数周或数月，因为人工修复无法以与开发相同的速度扩展。
仅仅让开发人员更加小心并不能解决这个问题。随着代码量的增加，如果软件开发要保持可持续发展，我们就必须防止更多的暴露，并减少剩余代码所需的人力。
通过计算进行预防
过去几年我一直在 GitHub 上从事秘密扫描工作，去年担任该领域的产品负责人。我们最大的影响来自于将检测与可以采取行动的系统之间的点连接起来。
GitHub 的目录通过我们的秘密扫描合作伙伴计划覆盖了 150 多个技术合作伙伴。通过我们的合作伙伴计划，我们与参与的秘密发行者合作建立探测器并报告公开曝光情况，以便他们能够做出回应。 2026 年第二季度，公共扫描平均每秒成功报告 26 个凭证匹配，包括重复观察。一旦收到通知，大量合作伙伴会立即撤销令牌：OpenAI API 密钥、Google Cloud 帐户凭据、Slack webhooks、Hugging Face 用户令牌、SendGrid 密钥等。所有者可能仍需要更换令牌，但无需等待开发人员找到并处理 GitHub 警报即可撤销令牌。
查看英文原文
Secret protection must scale with software
Developers aren’t becoming more careless; they’re being outpaced. The tools that let developers create more software should also take on more of the work of protecting it. The post Secret protection must scale with software appeared first on The GitHub Blog .
正文 · 来源原文
Erin Havens is a Product Manager at GitHub, focused on security products. 100+ ships across products like Secret Protection and Dependabot (and counting).
Today, one in three pull requests on GitHub involves an AI agent. A year ago, that number was fewer than one in 10. If that pace holds, within the next two years, most of the code pushed to GitHub could be written by an agent. Much of it may never be fully read by a human.
If developers and agents move faster, we have a responsibility to ensure protection keeps up with the accelerated rate of code creation. That means preventing more leaks before they happen and making the response to exposures that remain less dependent on manual human effort.
This is a pivotal point for leaked secrets. Developers aren’t becoming more careless; they’re being outpaced. The tools that let developers create more software should also take on more of the work of protecting it.
In this essay, I share the nine quarters of data behind that claim. I also introduce the fine-tuned classifier we built with Microsoft Applied Sciences to extend push protection to unstructured secrets. The model assesses a whole set of candidate secrets in less than two milliseconds and could more than double the number of secrets that we can prevent.