《GitHub 如何把密钥泄露告警清到 inbox zero》

导语

这篇 GitHub Blog 复盘的是一次内部密钥扫描治理：GitHub Security 在 15,000+ 个仓库里发现 20,000+ 个密钥告警，最后用九个月把未处理告警清到零。它不是“安全团队努力一点”的故事，而是一个标准的安全债务治理模型：先阻止新增，再分类降噪，验证真实风险，找到责任人，最后把治理变成可重复的组织流程。

1. 先承认告警数量会骗人

1.1 20,000 不等于 20,000 个真实风险

• GitHub 最初发现超过 20,000 个 密钥，数字很吓人。但深入后发现，五个仓库贡献了大约 18,000 个告警，而且都是测试夹具、已停用凭证或看起来像真的假密钥。剩下 2,000+ 个才是真正需要判断风险、轮换和修复的长尾。

1.2 降噪是治理的第一步

• 如果不先区分测试数据、无效凭证和真实凭证，安全团队会被告警淹没。GitHub 为高量低风险告警制定批量关闭标准：专用测试仓库、从未活跃、匹配已知测试模式，才可以批量关闭。

2. Secrets 不只存在代码里

2.1 支持工单、漏洞报告和 wiki 都会泄露

• GitHub 发现密钥不仅在源代码里，还出现在支持工单、漏洞赏金报告、事件记录和知识库页面。客户可能在工单里贴 token，研究者可能在复现漏洞时提交含 token 的 API 请求。

2.2 修复不能制造新泄露

• 团队和客服、安全事件响应、漏洞赏金项目一起制定 playbooks。关键约束是：不能为了修复密钥泄露，创建新的 issue、commit 或说明文档，把同一个秘密再次暴露出去。

3. 六阶段治理路径

3.1 Phase 1：全域启用，停止新增

• GitHub 先在所有企业和组织范围启用密钥扫描与推送保护，并用 GitHub Advanced Security 的组织级设置强制执行，避免 15,000 个仓库逐个配置，也避免团队悄悄退出。

3.2 Phase 2：理解和分流

• 团队按 repository、secret type 和 age 拆解 20,000+ 告警，先处理五个仓库的 18,000 个噪声项，再把剩余告警按真实风险和可操作性排序。

3.3 Phase 3：验证哪些仍然活着

• 当时密钥扫描还没有内置有效性检查，GitHub 自己搭了窄范围验证：例如对 GitHub token 调用 GET /user，并根据 200、401、403、429 等 HTTP 响应判断有效、已撤销、被限流或无法判断。目标不是探索权限，而是回答“凭证是否仍有效、该通知谁”。

3.4 Phase 4-6：归属、长尾和问责

• 后续阶段是找负责人、人工处理长尾，并把模式系统化。团队需要决定是否轮换、撤销、保留审计线索、是否重写 Git 历史。最终模式包括自动路由、明确责任、可度量进度和领导层可见性。

4. 难题不是技术，而是取舍

4.1 删除仓库通常不是好答案

• 有人会问能不能删除不用的仓库。GitHub 的一般回答是否定的，因为删除会带走审计线索。更稳的做法是先轮换或撤销暴露密钥，需要时归档仓库，但保留历史以便事件响应。

4.2 是否重写历史要看残余风险

• 对已撤销的密钥，留在历史里可能是可接受风险；但对仍有效或高敏凭证，就需要更强处置。重写 Git 历史会破坏 PR、commit SHA 和开发者流程，所以必须权衡安全收益和工程冲击。

5. 经验总结

5.1 没有 ownership 就没有修复

• 文章反复强调持久的归属基础设施。告警必须能路由到真正拥有系统和凭证的人；如果所有东西都落到安全团队手里，20,000 个告警永远清不完。

5.2 自动化必须服务人工判断

• 自动验证、告警分流和组织级强制设置都很重要，但它们的作用是让人把注意力放到真正风险上。密钥修复的核心不是关闭告警，而是安全地减少暴露。

5.3 原文里的配置和代码细节

• 原文还提到 GitHub 成立于 2008 年，验证请求使用 X-GitHub-Api-Version: 2022-11-28；示例包含 Authorization: Bearer TOKEN、Accept: application/vnd.github+json、{response##'\n'}、{response%$'n'}、status、(jq -r '.login // empty' <<< 以及 token appears invalid or revoked。组织治理侧还出现 Engineering Fundamentals、Custom Properties、只读验证和 90% 这类配置/比例信息。

思想框架

文章的治理框架是“止血、分诊、验证、归属、清尾、制度化”。它先用 push protection 阻止新增债务，再用数据分析把噪声从风险中分离，用 validity checking 判断凭证是否活着，用 ownership 把任务交给能修的人，最后把路线变成可复用流程。这个框架可迁移到许多工程债务：先控制入口，再清理存量，最后建立默认机制。