评审发现密钥怎么办
评审时看到提交进代码的真实密钥、令牌或连接串，要按「已经泄露」处理：先吊销并轮换凭据止损，再清理代码与提交历史，最后把扫描接进流程防止再次发生。只从当前文件里删掉不等于安全——凭据一旦进过远端仓库，就可能已经被克隆或抓取。
基本信息
| 处理原则 | 先轮换凭据，再清理代码与历史 |
|---|---|
| 公开风险 | 远端仓库的提交可能已被克隆或索引，历史删除不能保证回收 |
| 评审动作 | 阻止合并，说明凭据已暴露及其影响 |
| 预防手段 | 把密钥扫描接入提交钩子与流水线 |
处置步骤
- 第一步：吊销并轮换该凭据，先止损，再讨论怎么删。
- 第二步：评审中阻止合并，说明暴露范围与影响（该凭据能访问什么）。
- 第三步：清理代码与提交历史（如 git filter-repo 一类工具），并协调分支与本地副本。
- 第四步：检查该凭据的访问日志，确认是否已被异常使用。
- 第五步：把密钥扫描接入提交钩子与流水线，并说明环境变量的注入方式。
- 第六步：确认相关人员的本地环境与部署配置都已换成新凭据，避免旧值再次被写回代码。
- 第七步：把凭据改为从环境变量或密钥管理服务读取，并在文档里写清获取与轮换方式。
常见误判
| 做法 | 为什么不够 |
|---|---|
| 只删文件不轮换 | 泄露的凭据仍然有效，随时可用 |
| rebase 抹掉历史 | 已推送分支常被克隆，历史未必能真正清除 |
| 改成私有仓库 | 已克隆的副本与索引不会因此消失 |
| 把密钥写进占位符不换 | 占位符替换了文件，真实凭据依然有效 |
凭据进过一次远端仓库即按泄露处理：删除提交不能保证没有人克隆过。
在评审评论里描述凭据时不要粘贴完整值：把定位线索指向文件与提交即可，避免二次扩散。