Truffle Security开展的一项研究显示，尽管 GitHub 采取了旨在防止敏感秘密意外发布的工具，但在 7 月期间，公共 GitHub 仓库中仍有 543,699 个独特凭据有效且处于暴露状态。研究结果来自对 2.24 亿个仓库和超过 580 亿个文件的数据分析，其中包括派生仓库的副本。
问题并不局限于近期秘密；这些独特凭据对公众可见的中位时长达到 784 天。约 10% 的有效凭据早于 6.3 年，而研究发现的最早有效凭据可追溯至 2009 年。
暴露范围及其趋势
研究统计的凭据出现在超过 110 万个文件和仓库中。该分析基于一组为训练大型语言模型而准备的数据集，数据来自一次于 2025 年 8 月 7 日完成的抓取。
Truffle Security 表示，这一数量超过其 8 月检查 Hugging Face 平台时发现数量的两倍以上；当时该公司发现了 221,303 个有效凭据。此外，有效秘密的密度从 2015 年每百万个文件 3.72 个，上升至 2025 年的峰值 11.62 个。
Push Protection 改变了什么？
GitHub 于 2022 年 4 月向 Advanced Security 用户推出 Push Protection 功能，随后于 2023 年 5 月向公共仓库开放，并在一年后默认启用。该功能会扫描传入的代码，查找已知模式，例如 API 密钥和访问令牌，并在发现这些内容时阻止推送。
但该功能不会撤销或停用在被发现之前已经暴露的凭据。在 7 月仍处于有效状态的凭据中，有 199,843 个是在 2024 年 2 月面向所有用户启用 Push Protection 后被披露的，约占总数的 36.8%。此外，仍在使用的凭据中有 51.8% 属于默认保护不会阻止的类别，包括数据库连接字符串和 Google API 密钥。
尽管如此，该功能在其覆盖范围内似乎有效；默认启用后，受保护类别中的凭据披露率下降了 53%。
为什么这条消息很重要？
研究结果表明，阻止新的秘密被推送并不能解决全部风险。秘密可能长期留存在仓库历史记录或其派生副本中，而且响应效果会因凭据类型及其关联服务的不同而有所差异。
例如，在 101,886 个暴露的 npm 令牌中，只有一个仍然有效；而在分析时，126,963 个 Google Cloud 服务账号凭据中仍有 69,041 个有效。Truffle Security 建议立即轮换暴露的凭据，清理仓库，检查变更历史，并为活跃秘密设置自动过期机制。
该研究没有确定实际被窃取或用于攻击的秘密比例，因此它衡量的是可被利用的暴露规模，而不是已确认损害的规模。这一点仍是开放问题之一，不应与所发现的有效凭据数量混为一谈。