公开在 GitHub 上的 543,699 个凭据仍然有效（2026年调查）：为什么要吊销而不是删除，开发者该做什么

本文面向：把代码放在 GitHub 等公开仓库中的开发者，以及运营 API 的公司。本文用本站自己的话重述一家安全公司调查中的数字，不涉及如何查找他人的凭据。

这项调查是什么（不是 GitHub 官方调查）

2026年9月29日，销售密钥扫描工具的安全公司 Truffle Security 发布了一项关于公开仓库中遗留凭据的调查。作为检测工具的供应商，发布方在这个话题上有商业利益。本文按报告引用调查中的数字，并把本站的解读单独标明。

GitHub 并没有泄露任何东西。这些凭据是各个仓库的所有者写进代码并公开的。GitHub 的角色是提供推送保护（拦截包含密钥的推送）等预防功能，而如下文所示，这些功能覆盖的类型有限。

调查是怎样进行的，以及如何解读这些数字

• 源数据是 The Stack v3，这是第三方为训练 LLM（大语言模型）而收集的公开仓库数据集。收集截止于2025年8月7日。
• 只检查了收集时的默认分支（如 main）。更早的提交、其他分支以及在那之前已删除的内容都不包括在内。这不是对 GitHub 上所有公开代码的扫描。
• “有效”是指提供商确认该凭据在2026年7月27日至28日仍能通过认证。其中一些可能在那之后已被吊销。
• 自暴露以来的时间，从包含凭据的文件的最后修改日期开始计算。调查指出，这往往会低估实际时长。
• 某些类型没有计入部分数字。Google API 密钥只针对 Gemini 进行了测试，私钥在没有对应主机的情况下无法测试，所以这两类都没有计入按类型统计的存活数字。

数字：留下了什么，有多少

2024年2月29日那一周，GitHub 开始为所有用户对公开仓库的推送默认开启推送保护。根据调查，543,699个有效凭据中有199,843个（36.8%）是在那之后出现的。

此外，51.8%的有效凭据是连接字符串、Google API 密钥或私钥，这些类型推送保护默认不拦截。对于推送保护覆盖的类型，比较变更前后各12个月，每百万个文件中的泄露数量下降了约53%。不覆盖的类型只下降了约7%。调查本身也指出，其中可能混杂了其他因素，例如同一时期云服务商在推动客户改用短期凭据。

按类型看，有多少仍然有效

下表根据调查公布的数量重新计算了百分比。“发现数”是在默认分支上发现的凭据数量；“有效数”是其中在测试时仍能通过认证的数量。

MongoDB 使用的检测器只记录它成功连接上的字符串，所以无法计算比例，该类型没有计入存活数字。只报告了有效数。

为什么各类型差别这么大

差别与其说来自凭据是否容易被找到，不如说来自被找到之后是否有人去停用它们。在我们能从各提供商官方文档中确认的范围内，情况如下。

GitHub 的密钥扫描合作伙伴计划会把在公开仓库中发现的凭据通知给签发方。GitHub 的文档建议把它报告的任何密钥都视为已公开、已泄露，但具体实现交给签发方。是否吊销、重新签发或联系用户，由签发方决定。

两家云服务商的应对方式，与完全吊销并不相同。

• AWS：AWS 会给访问密钥可能已暴露的 IAM 用户附加一个名为“AWSCompromisedKeyQuarantineV3”的托管策略。它会拒绝某些操作，例如启动实例或修改 IAM，但不会删除密钥。AWS 要求客户不要移除该策略，并按照它开立的支持工单中的说明操作。
• Google Cloud：自2024年6月16日起，在公开仓库等地方检测到的服务账号密钥默认会被自动停用。组织可以通过组织策略约束 iam.serviceAccountKeyExposureResponse 选择不启用（WAIT_FOR_ABUSE）。调查仍然发现超过一半有效；调查没有解释原因。

如果发现自己泄露了凭据

预防泄露

推送保护有帮助，但单靠它并不够。正如数字所示，默认不拦截的类型会直接通过，用户也可以通过选择一个理由来绕过拦截。请结合以下措施。

• 在提交前扫描：用 gitleaks 等扫描工具，在推送之前就在你自己的电脑上拦截密钥（参见用 gitleaks 在提交前拦截密钥）。
• 扫描旧仓库的历史：推送保护对开启之前的提交不起作用。对于无人维护和已归档的仓库，至少完整扫描一次历史。
• 使用短期凭据：GitHub Actions 可以用 OIDC（每次运行时获得一个只在短时间内有效的凭据）连接 AWS 或 Google Cloud，而不是保存长期密钥。Hugging Face 也提供同样的方式。
• 缩小每个密钥能做的事：只读、仅限特定 API、来源 IP 或 referrer 限制，以及有效期。这可以限制泄露带来的损失。
• 不让数据库暴露在互联网上：如果从外部无法访问，泄露的连接字符串就没有用。数据库连接字符串是表中存活时间最长的类型。

不把密钥写进代码的基础知识，参见.env 文件和 API 密钥真正的危险之处；遗留在 Web 服务器上的密钥，参见检查公开目录。

给运营 API 的公司

把表格上方和下方区分开来的，是签发方是否会自动停用泄露的密钥。作为保护用户密钥的一方，可以考虑：

• 加入 GitHub 的密钥扫描合作伙伴计划，收到通知后吊销有效密钥并通知用户
• 给密钥加上有辨识度的前缀（例如以你的服务名开头），让它们易于检测
• 提供一个渠道或 API，让任何人都能报告并使泄露的密钥失效
• 把有有效期的密钥和权限范围窄的密钥设为默认

信息来源（公开资料）

本文中的数字来自以下公开资料。我们没有转载调查的文字或图表；只使用了其中的数量并重新整理。

• Truffle Security（密钥扫描工具提供商）的调查，2026年9月29日 — trufflesecurity.com
• 报道：BleepingComputer（2026年9月30日） / SecurityWeek（2026年10月1日） / GIGAZINE（2026年10月2日，日语）
• GitHub：默认开启推送保护（GitHub Blog） / About push protection / 支持的模式 / 合作伙伴计划 / 令牌的过期与吊销
• npm：npm Blog（2019年6月18日）
• Hugging Face：User access tokens（吊销泄露的令牌）
• AWS：AWSCompromisedKeyQuarantineV3
• Google Cloud：自动停用泄露的服务账号密钥（2024年5月16日） / 管理服务账号密钥的最佳做法

延伸阅读

• GitHub 设置：如何设置 GitHub 双重验证
• 预防：用 gitleaks 在提交前拦截密钥 / 密钥泄露检查工具（粘贴即可扫描）
• 基础：.env 文件和 API 密钥真正的危险之处 / 什么是 .env 文件
• 泄露的代价：AI 写的代码泄露了 API 密钥，导致被盗刷
• 针对开发者凭据的攻击：防御供应链蠕虫 / TanStack、Nx Console 与 GitHub 的连锁入侵（2026年5月）
• 缩小密钥权限：SSH 密钥的最小权限