《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 为高量低风险告警制定批量关闭标准：专用测试仓库、从未活跃、匹配已知测试模式，才可以批量关闭。