扫描中国 Gitee 上的 725 万个代码仓库，发现 26,400 个有效凭据

# 扫描中国最大 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 专注于研究公共源代码托管平台上的大规模凭据泄露。* **摘要：**我使用 TruffleHog 和 Kingfisher (https://github.com/mongodb/kingfisher)，扫描了 Gitee（中国最大的本土 Git 托管平台）上的 **7,256,531 个公共仓库**，发现了 **26,400 个经验证仍有效的唯一凭据**。其中包括一个大型企业 AI 平台上仍然有效的组织管理员凭据，以及数千个仍然有效的云服务商访问密钥。 ## 什么是 Gitee？ Gitee 由开源中国于 2013 年推出，被中国工业和信息化部选为国家级开源代码托管平台。与 GitHub 和 GitLab 相比，它的公共 API 受到严格限制：没有支持分页的项目端点，而且站内代码搜索功能似乎早在几年前就已停用。2021 年的一次研究尝试 (https://chinggg.github.io/post/git-leaks/) 得出结论，Gitee 的 API 限制过多，无法开展大规模凭据泄露研究。 与任何大型 Git 平台一样，它也是一个值得关注的凭据泄露场所： - 它基于 Git，因此深藏在提交历史中的密钥会持续留存。 - 它托管着数百万个公共仓库，且提交活动活跃。 - 它没有类似 GitHub 上已成为标准做法的平台与服务商之间的公开密钥扫描合作机制。 ## 枚举数百万个 Gitee 仓库 Gitee 的公共 API 限制非常严格，因此，要枚举数百万个仓库，就需要结合多种渠道：唯一能够大规模返回有用数据的官方 REST 端点、平台的 Explore 信息流、网站上每个用户的仓库页面和仓库收藏者页面，以及为站内搜索界面提供支持的 Gitee 内部 Elasticsearch 组件。 ### 构建初始用户名语料库 唯一能够大规模返回有用数据的官方 REST 端点是 GET /api/v5/search/users?q=。我使用三字符前缀查询（aaa、aab、……、zzz）请求该端点，并将结果与从公共 Explore 信息流（/explore/all?order=starred|popular|updated）中提取的用户名合并。随后，我通过每个用户的关注列表以及热门仓库的收藏者列表扩充这个集合。最终得到了包含 **1,704,759 个用户名**的初始语料库。 ### 抓取前端的用户页面 有了用户名语料库后，可以从每个用户的两个页面获取仓库：gitee.com/{user}/projects（用户自己的仓库）和 gitee.com/{user}/stared_projects（用户收藏的仓库）。/projects 的第 1 页返回完整 HTML；后续页面则通过 AJAX 分页加载（X-Requested-With: XMLHttpRequest）。构建初始用户名集合时使用的收藏者列表页面采用相同的分页方式，但还需要从第 1 页的 HTML 中提取 CSRF 令牌。 ### 查询站内搜索组件 平台上有很大一部分仓库位于上述社交关系网络之外。为了找到这些仓库，我使用了为 Gitee 站内搜索界面提供支持的同一个内部 Elasticsearch 端点：so.gitee.com/v1/search/widget/wong1slagnlmzwvsu5ya。它接受 query ID、q 参数，并通过 from + size 进行分页： 每次查询每页最多返回 20 条结果，而且无论实际匹配多少条，**总结果数都被硬性限制为 200 条**（from + size <= MAX_RESULTS）。对于具体用户名，这通常没有问题；但对于常见用户名以及针对该组件的三字符前缀查询，这个上限会在没有提示的情况下截断结果。 ### 通过分桶拆分突破 200 条结果的上限 该组件的响应包含 Elasticsearch 聚合，可按语言（编程语言）和许可证（许可证）对结果分桶。在按用户名抓取时，如果查询触及上限，我就根据响应中已有的语言分桶拆分查询： 对于针对该组件的三字符前缀查询（用于发现与任何已发现用户都没有关联的仓库），我将这一方法扩展为对查询树进行广度优先搜索（BFS）：触及上限的节点先按语言拆分，再按许可证拆分，最后使用更长的前缀继续拆分，直到每个分支的结果都不超过 200 条。 对所有来源的仓库 ID 去重后，最终得到了包含 **7,256,531** 个唯一公共 Gitee 仓库的工作集。 ## 搭建扫描流水线 接下来的挑战是克隆并扫描这 725 万个仓库。为了通过一个 Python 脚本完成这项工作，我使用了 Modal (https://modal.com/)。这是一个在 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 对 993），而 Kingfisher 在 DeepSeek（2,940 对 230）、OpenAI（1,198 对 150）、HuggingFace（154 对 1），以及智谱等 TruffleHog 尚无对应检测器的中国 AI 服务（1,489 对 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。**按提交者邮箱域名划分的唯一凭据。 甲骨文、苹果、Meta、Anthropic 等公司也出现了数量较少的记录，此外还有中国企业和学术机构的域名。 ### 将 Gitee 与 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 扫描结果。 - **提交者元数据中同时出现了中国和西方的大型科技公司。**涉及华为、字节跳动、谷歌、微软、甲骨文等多家公司，表明这一现象并非仅限于中国开发者。 - **披露渠道存在不对称。**西方公司通常设有漏洞赏金计划或易于联系的安全渠道。多数中国公司没有这类机制，导致泄露的凭据缺乏明确的补救路径。 - **该架构可迁移。**同样的 Modal + 双扫描器流水线，只需替换克隆 URL，基本上就能用于大多数 Git 托管平台；完整扫描成本约为 3,000 美元。