独立安全研究员 Ben Zimmermann 联合 MongoDB 旗下 Kingfisher 团队，于 10 月 28 日发布一份针对 Gitee（码云）的大规模凭证泄露审计报告。研究扫描了该平台 7,256,531 个公开仓库，经去重并逐一调用厂商接口实际验证后，确认存在 26,400 个唯一且当前仍然有效的私有凭证。其中阿里云 AccessKey 对数量最多，达 9,473 组。
事件概述
与以往大量「疑似泄露」的统计不同，这份报告的关键在于验证环节：所有计数都是通过真实调用对应厂商的接口确认过的活密钥，而不是在文本里匹配到一串像密钥的字符。整个扫描历时约一个月，覆盖的是每个仓库的完整提交历史，而不是当前文件快照。
按厂商维度分布如下：
- 阿里云 AccessKey 9,473 组、YouTube API Key 3,805 个
- DeepSeek 3,170 个、智谱 BigModel 1,489 个、OpenAI 1,348 个
- GitHub Token 600 个、Infura 499 个、JWT 391 个、Mapbox 346 个
- AWS 338 个、Google Cloud 283 个、Gemini 260 个
- Weights & Biases 222 个、MongoDB 220 个、HuggingFace 155 个
长尾部分还涉及 LangSmith、OpenWeather、Algolia、PostHog、OpenRouter、MySQL、Stripe、Slack、Twitter 等服务。研究者测算，平均每 766 个 Gitee 仓库中就有 1 个包含经确认仍有效的阿里云凭证。
技术细节
泄露成因几乎都是操作失误，而不是有意公开。典型情形是在快速开发阶段把 Token 直接硬编码进 .env、config.py 之类的配置文件，然后随手提交推送。
真正让问题长期存在的是 Git 的机制。提交历史是一条只增不改的账本，开发者事后从当前文件里删掉密钥、再提交一次，那条旧提交依然完整保留，密钥明文就躺在里面。本次扫描正是扒的完整历史，所以已经被「删除」的密钥同样被计入统计。按提交时间看，26,400 个里有 12,242 个来自 2025 年的提交，接近一半；其余更老，部分可追溯到 2000 年代末。
报告里最容易被低估的发现是两个扫描工具的命中差异：TruffleHog 找到 12,737 个有效凭证，Kingfisher 找到 14,664 个，两者重合的只有 1,001 个。也就是说，两个专业工具同时开同一扇门，只有 1,001 把锁是双方都打开的。漏检原因很具体——TruffleHog 没有智谱的检测规则，那 1,489 个密钥它一个也认不出。这条结论对做密钥扫描的团队有直接价值：单一工具的正则库决定了你能看见什么，多引擎交叉扫描不是冗余，而是必要。
此外，研究者还发现一个大型企业级 AI 平台的组织管理员凭证仍处于有效状态，平台未被点名。这类高权限密钥一旦被滥用，影响远不止单个接口的调用额度。
影响评估
被这类密钥攻破的路径和账号密码泄露完全不同。AI 服务的 API Key 授权的是以机器速度、按 API 规模执行的自主操作，不会产生登录事件、不会触发 MFA 提示、也不会留下会话记录——密钥直接执行。
云厂商 AccessKey 的风险则更高一层。拿到 AccessKey 就意味着可以列举资源、读对象存储、改配置，甚至开新实例；如果这对密钥绑定的 RAM 角色权限过宽，等于把整个账号的操作面交了出去。
披露流程上存在明显缺口：研究者把凭证清单发给了泄露数量最多的几家厂商，但没有联系把密钥推上去的开发者本身；发布时也未确认这些密钥是否已被吊销。这意味着两件事——部分密钥可能此刻仍然可用，以及这些密钥在被清理之前已经在公网上公开了数周。
修复建议
- 判断标准只有一条：任何曾经出现在公开 Gitee 仓库的密钥，一律视为已泄露，无论是否已经删除。删除代码是打扫房间，吊销密钥才是换锁。
- 处置动作是去服务商后台禁用旧密钥、重新生成新密钥，并把新密钥放进环境变量或密钥管理服务，不要回写进仓库。
- 阿里云用户重点检查 AccessKey 对应的 RAM 用户权限，把权限收敛到最小集，并为 AccessKey 配置使用监控与异常告警。
- AI 服务用户检查用量与账单，DeepSeek、OpenAI、智谱的密钥被他人使用会直接体现在配额与费用上。
- 把密钥扫描接进 CI，在 push 阶段拦截，而不是等定期扫描；同时至少用两个引擎交叉扫，覆盖不同厂商的规则库。
- 历史提交需要清理。仅删除文件无效，要用 git filter-repo 之类的工具改写历史，并强制所有协作者重新克隆。
对国内团队而言，这次审计的警示很直接：Gitee 上 9473 组可用的阿里云 AccessKey 不是一个抽象数字，而是一批当前仍然开着门、却没人知道归谁管的钥匙。凭证治理最难的部分从来不是扫描，而是确认某个密钥由哪个系统签发、权限范围多大、是否还在使用。