在中国最大的 Git 平台上扫描 725 万个公开仓库以寻找密钥

来源：https://www.mongodb.com/company/blog/technical/scanning-7-point-25-million-public-repositories-chinas-largest-git-platform-for-secrets 本文由独立安全研究员 Ben Zimmermann 撰写的客座文章，与 MongoDB 的 Kingfisher 团队合作完成。Ben 专注于跨公开源代码托管平台的大规模凭据暴露研究。

TL;DR： 我使用 TruffleHog 和 Kingfisher (https://github.com/mongodb/kingfisher) 扫描了 Gitee（中国最大的本土 Git 托管平台）上的 7,256,531 个公开仓库，发现了 26,400 个经过验证且仍然有效的唯一凭据。发现结果包括某大型企业级 AI 平台的一个有效的组织管理员凭据，以及数千个仍然有效的云服务商访问密钥。

什么是 Gitee？

Gitee 由 OSChina 于 2013 年推出，被中国工业和信息化部选为国家级开源代码托管平台。其公开 API 相较于 GitHub 和 GitLab 受到严重限制：没有分页的项目端点，站内代码搜索功能似乎也已在多年前被移除。2021 年一项尝试 (https://chinggg.github.io/post/git-leaks/) 研究 Gitee 上的凭据暴露情况，结论是其 API 过于受限，无法将研究规模化。

与任何大型 Git 平台一样，它是凭据暴露的高风险面：

• 它基于 Git，因此深埋在提交历史中的密钥会持续存在。
• 它托管了数百万个公开仓库，且提交活动活跃。
• 它没有类似 GitHub 上已成为标准的平台厂商密钥扫描合作关系的公开等价机制。

枚举数百万个 Gitee 仓库

Gitee 的公开 API 受到严重限制，因此枚举数百万个仓库需要组合使用多个入口：唯一能大规模返回有用数据的官方 REST 端点、平台的 Explore 信息流、网站上的每个用户的仓库页面和 stargazer 页面，以及驱动站内搜索 UI 的 Gitee 内部 Elasticsearch 小组件。

构建用户名语料库

唯一能大规模返回有用数据的官方 REST 端点是 GET /api/v5/search/users?q=。我使用三字符前缀查询（aaa、aab、……、zzz）访问它，并将结果与从公开 Explore 信息流（/explore/all?order=starred|popular|updated）中提取的用户名合并。然后我通过每个用户的关注列表和热门仓库的 stargazers 来扩展这个集合。这产生了 1,704,759 个用户名的种子语料库。

抓取前端上的每个用户页面

有了用户名语料库之后，两个按用户划分的页面可以提供仓库：gitee.com/{user}/projects（用户自己的仓库）和 gitee.com/{user}/stared_projects（用户标星的仓库）。/projects 的第 1 页返回完整 HTML；后续页面采用 AJAX 分页（X-Requested-With: XMLHttpRequest）。在用户名引导阶段使用的 stargazer 列表页面采用相同的分页方式，另外还需要从第 1 页 HTML 中提取 CSRF 令牌。

查询站内搜索小组件

平台的很大一部分不在社交图谱之内。为了触达这些内容，我使用了驱动 Gitee 站内搜索 UI 的同一个内部 Elasticsearch 端点：so.gitee.com/v1/search/widget/wong1slagnlmzwvsu5ya。它接受一个 queryID、一个 q 参数，以及通过 from + size 进行分页：

每次查询每页最多返回 20 个结果，总计硬性上限为 200 个结果（from + size <= MAX_RESULTS），无论实际匹配了多少结果。对于特定用户名，这通常没问题；对于常见用户名和针对小组件的三字符前缀查询，该上限会悄悄截断结果。

通过分桶拆分突破 200 条结果上限

小组件的响应包含 Elasticsearch 聚合功能，按编程语言（编程语言）和许可证（许可证）对结果进行分桶。对于按用户名抓取，当查询结果达到上限时，我会使用响应中已返回的语言桶来拆分查询：

对于针对小组件的三字符前缀查询（用于发现不属于任何已知用户的仓库），我将其扩展为对查询树的 BFS：达到上限的节点首先按语言拆分，然后按许可证拆分，再按更深的前缀拆分，直到每个分支都落在 200 条结果以内。

在对所有来源的仓库 ID 去重后，这产生了 7,256,531 个唯一公开 Gitee 仓库的工作集。

搭建扫描流水线

下一个挑战是克隆并扫描这 725 万个仓库。为此，我使用 Modal (https://modal.com/) 在单个 Python 脚本中完成——这是一个流行于 AI 工作负载的无服务器计算平台，也非常适合大多数并行任务。我对每个仓库同时运行 TruffleHog 和 Kingfisher 以提高覆盖率。两个扫描器各自能验证对方遗漏的凭据，因此同时运行两者比单独运行任何一个都能捕获更多暴露的凭据。

图 1. 双扫描器流水线架构。

Docker 镜像

容器镜像是一个多阶段构建，将两个扫描器二进制文件从各自的上游版本拉取到一个 Python 基础镜像中，外加用于克隆的 git 和 OpenSSH：

按仓库扫描的函数

单个 Modal 函数通过 SSH 对每个仓库进行裸克隆，然后将两个扫描器作为子进程并发运行，针对同一个磁盘上的克隆：

分批调度 725 万个仓库

我将语料库分成 50 个批次，每批约 15 万个仓库，以稳定运行 350 个并发容器的速率顺序执行。在这个规模下，较小的批次更安全，中断后更容易恢复；运行较大的批次不稳定，会触发克隆端的封禁。

成本与规模

总耗时：大约持续运行了一个月。每个仓库的克隆时间是主要贡献因素：Gitee 的服务器位于中国，跨太平洋的网络距离加上 SSH 协议开销使得每次克隆都明显慢于等量 GitHub 克隆。总成本为 $3,097.64，完全由 Modal 提供的 $5,000 计算积分赞助承担。相同的 Modal + 双扫描器架构只需替换克隆 URL 即可用于大多数 Git 主机。我在之前一项关于 Algolia DocSearch 管理密钥的调查 (https://benzimmermann.dev/blog/algolia-docsearch-admin-keys) 中使用了这种方法的小规模版本。

结果

在扫描的 7,256,531 个公开 Gitee 仓库中，双扫描器流水线在按令牌值去重后发现了 26,400 个唯一且经验证仍然有效的凭据。

两个扫描器都在扫描时通过各自厂商的 API 对每个候选凭据进行身份验证（TruffleHog 的 --only-verified 和 Kingfisher 的 --only-valid 模式），丢弃任何模式匹配但身份验证失败的凭据。26,400 这个数字是按原始密钥值去重的，因此跨仓库或跨扫描器的重复项只计一次。

单独使用任何一个扫描器都只能捕获大约一半的凭据。两个工具的检测器覆盖范围在很大程度上是互补的：TruffleHog 在阿里云密钥检测方面占主导（9,428 vs. 993），而 Kingfisher 在 DeepSeek（2,940 vs. 230）、OpenAI（1,198 vs. 150）、HuggingFace（154 vs. 1）以及 TruffleHog 没有检测器的中国 AI 服务（如智谱，1,489 vs. 0）方面占主导。

按类型分类的密钥

最常见的泄露凭据类型是阿里云 AccessKey 对：大约每 766 个 Gitee 仓库中就有 1 个包含一个经验证仍然有效的阿里云凭据。

图 2. 按厂商分类的凭据。

大量长尾厂商（LangSmith、OpenWeather、Algolia、PostHog、OpenRouter、MySQL、Stripe、Slack、Twitter 等）占据了其余部分。

按提交日期分类的密钥

绝大多数经验证仍然有效的凭据是在过去两年内提交的。仅 2025 年就占了 12,242 个唯一凭据，接近整个数据集的一半。

图 3. 按年份分类的唯一凭据提交量。

按提交者邮箱域名分类的密钥

大多数凭据是从个人邮件服务（qq.com、163.com、gmail.com）提交的，使得大规模的逐公司归属成为不可能。下面的公司域名数字是下限；即便如此，这些名称涵盖了中国和西方的主要科技公司。

图 5. 按提交者邮箱域名分类的唯一凭据。

还出现了来自 Oracle、Apple、Meta、Anthropic 等公司的较小规模足迹，以及中国的商业和学术域名。

与 GitLab 和 Bitbucket 的对比

最接近的既有数据来自 TruffleSecurity 对 560 万个公开 GitLab 仓库的扫描 (https://trufflesecurity.com/blog/scanning-5-6-million-public-gitlab-repositories-for-secrets)，以及该文章中引用的配套 Bitbucket 扫描。

Gitee 在原始数量和每仓库密度方面都超过了两个西方平台。一个方法论说明：TruffleSecurity 的扫描仅使用了 TruffleHog，而本次研究同时使用了 TruffleHog 和 Kingfisher。TruffleHog 的检测器库偏向西方厂商，而 Gitee 有大量中国厂商活动（阿里云、DeepSeek、智谱等），Kingfisher 的覆盖范围有助于发现这些；如果我们只保留 TruffleHog 的发现结果，Gitee 为每 1,000 个仓库 1.76 个凭据。

漏洞披露

我通过电子邮件联系了本次扫描中暴露量最大的厂商，为每家提供了协调报告，其中包含与其服务相关的全部经验证仍然有效的凭据列表，以及源仓库元数据，以帮助他们定位受影响的客户。

按开发者逐一通知（单独联系每个泄露凭据的提交者）在此规模下未被采用。厂商侧的撤销是更可靠的路径，因为它不需要泄露凭据的用户采取任何行动。

截至撰写本文时，已披露凭据的撤销状态尚未得到确认。

总结

• Gitee 是一个重要的凭据暴露面。 725 万仓库中有 26,400 个经验证仍然有效的凭据。每仓库密度高于已发表的 GitLab 和 Bitbucket 可比扫描结果。
• 主要科技公司出现在提交者元数据中，涵盖中国和西方。 范围包括华为、字节跳动、Google、Microsoft、Oracle 等，表明这并非纯粹的中国开发者现象。
• 披露路径存在不对称性。 西方公司通常设有漏洞赏金计划或可访问的安全沟通渠道。大多数中国公司没有，导致泄露的凭据缺乏明确的修复路径。
• 该架构可移植。 相同的 Modal + 双扫描器流水线只需替换克隆 URL 即可用于大多数 Git 主机；完整扫描成本约为 $3,000。