代码库密钥扫描
在提交前与 CI 中加入密钥扫描（如 gitleaks、trufflehog），可以拦截私钥、Token 与口令进入仓库。真正要记住的是处置原则：内容一旦推送到远端就视为已泄露，删除文件或改写历史都无法收回，正确动作是立即轮换对应密钥并评估使用记录。扫描应覆盖工作区、提交前钩子、CI 门禁与历史提交四个位置。
基本信息
| 覆盖点 | 工作区扫描、提交前钩子、CI 门禁、历史提交扫描 |
|---|---|
| 常见命中 | 私钥 PEM、云访问密钥、Token、口令文件 |
| 处置原则 | 轮换为先，清理历史为辅 |
| 误报处理 | 维护白名单并定期复核，避免噪音掩盖真实告警 |
| 成本 | 全量历史扫描较慢，适合定期执行而非每次提交 |
典型使用场景
- 新仓库接入 CI 时的门禁配置
- 定期扫描历史提交，发现早期遗留的密钥
- 收敛扫描规则与白名单，减少无效告警
- 事故处置：确认泄漏范围并列出待轮换密钥清单
- 与开发流程结合：用提交前钩子拦截，减少事后清理
扫描工具示例
扫描工具示例
gitleaks detect --source . --verbose # 扫描工作区与历史
trufflehog filesystem . --only-verified # 优先关注可验证的真实凭据
# 提交前钩子场景可只扫描暂存区，速度更快
# gitleaks protect --staged扫描位置对比
| 位置 | 时机 | 特点 |
|---|---|---|
| 提交前钩子 | 本地提交时 | 反馈快，但可被绕过 |
| CI 门禁 | 推送或合并时 | 覆盖全团队，需要白名单 |
| 工作区扫描 | 按需执行 | 适合事故排查 |
| 历史提交扫描 | 定期执行 | 耗时长，用于发现遗留问题 |
强推改写历史无法收回已经推送出去的内容：发现泄露后必须评估使用记录并轮换对应密钥，把「先轮换、后清理」固定为标准流程，而不是先花时间清理历史。
落地建议：先跑一轮全量历史扫描拿到基线，再按仓库收敛规则；把高频误报加进白名单并定期复核，避免告警疲劳。对确认为真实的命中项，直接登记到待轮换清单，跟踪到密钥全部替换完成。