背景环境

GitHub成立于2008年，早于集中式密钥仓库和自动化扫描的普及。工程师把API Token写进配置文件、测试夹具、Bug Bounty报告——这是行业惯例，不是疏忽。但当安全团队开始评估密钥卫生时，他们意识到存量债必须还。

异常出现

在15,000+仓库中启用Secret Scanning试点，结果让团队倒吸凉气——超过20,000条密钥告警。按每人每天50条计算，四个人连续三个月才能清完。更致命的是，告警还在增长。

"我们不可能靠几个人一条条消灭两万条。"团队意识到，这首先不是技术问题，而是流程设计问题。

错误判断

团队按仓库、密钥类型、暴露时长做分层分析，发现一个关键洞察：数字会骗人。

仅仅5个仓库就贡献了约18,000条告警——全部是非活跃的测试夹具和假凭据。（GitHub自己开发Secret Scanning，测试仓库里全是长得像密钥的东西。）这18,000条是噪音，不是风险。真正需要处理的是剩下的2,000条。

排查过程

批量关闭低风险：对专用测试仓库中的假凭据直接标记"已解决"，几天内关闭18,000条。

有效性验证：当时Secret Scanning没有内置有效性检查，团队自建验证体系——核心问题只有一个：凭据还能不能用？对GitHub Token，向`GET /user`发一次低影响请求即可判断。验证范围严格控制，不访问私有资源，背后是与隐私和法律团队的紧密协作。

所有权归属：知道凭据有效之后，谁能轮换它？对自家签发的Token，直接在告警中暴露元数据（创建者、时间、权限）。对第三方凭据，问题更深——并非所有仓库都有明确所有者。这个痛点推动了仓库所有权体系建设，利用Custom Properties建立仓库与团队的映射，确保所有凭据有持久责任人。

技术决策

处理中遇到大量取舍场景：

密钥在Issue中？优先撤销凭据，保留审计历史，不删改。

密钥在Git历史中？优先轮换或撤销凭据，对历史中的已撤销密钥评估残留风险。重写Git历史会打断所有PR、使Commit SHA失效——代价远大于收益。

能直接删仓库吗？通常不行——删除仓库等于删除审计痕迹。正确做法：轮换密钥，归档仓库，保留历史。

关键工程措施

1. 强制Push Protection：在所有企业中开启推送保护，阻止新密钥进入代码库

2. Validity Checking内置化：与产品团队共建，将临时方案变为Secret Scanning原生能力

3. 纳入工程考核：绑定Engineering Fundamentals项目，密钥卫生成为团队衡量指标

4. 跨团队协作手册：与客服、应急响应、Bug Bounty团队制定统一处理剧本

经验总结

九个月后，20,000条告警归零。

分层是处理大规模告警的唯一方法。 不分层的20,000条是灾难；分层的20,000条是"18,000噪声+2,000可管任务"。

元数据比自动化更有价值。 让工具替你回答"有没有效""归谁管"，而不是替你做"要不要关"。

所有权是安全的地基。 找不到所有者，任何安全流程都跑不通。

将安全嵌入考核体系。 当密钥卫生成为工程健康度指标，安全不再是单方驱赶，而是全组织共同责任。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）