目标
争论“有没有人看到过凭据”等于给攻击者送时间。响应顺序是固定的：先轮换夺走它的力量，再用保留下来的日志调查，最后堵上泄漏它的路径。轮换速度就是全部——泄露到失效的十分钟窗口，与拖到明天的窗口，是完全不同的两场事故。
步骤要点
- 确认与分级：验证密钥真实且现行（非已吊销或测试值），分级其作用域：只读令牌、部署密钥还是用户数据凭据。
- 立即双凭据轮换：先建新凭据并部署到消费方，再吊销旧密钥，平台支持时用双凭据过渡窗口。
- 从轮换前的日志追查旧密钥使用：异常源 IP、陌生 API 调用、提权或数据导出，输出覆盖泄露窗口的使用报告。
- 清理前保全证据：快照泄露载体（提交、工单、截图）与相关日志，再删除公开副本。
- 堵泄漏路径：修复致漏环节（钩子拦截、CI 打码、密钥管理器），并全仓扫描同类模式。
排错提示
先查清滥用再轮换是最危险的拖延，凡触及用户数据或生产的密钥一律先轮换；吊销后才发现要查的日志没导出，证据保全必须排在清理之前；同一漏洞第二次出现说明只修了点没扫面，每次泄露都要做同类模式的全仓排查。
适用边界
快速轮换依赖预建的轮换手册与双凭据支持，无此能力的系统暴露窗口不可控；滥用检测受审计日志覆盖度限制，未记日志的调用无法回溯。
代码示例
leak: deploy key in a public gist (found 14:02Z)
14:04Z confirmed valid, scope: repo write (prod deploy)
14:06Z ROTATE: new key deployed to CI (dual window)
14:12Z REVOKE old key -> auth fails everywhere
14:13Z hunt (audit log 10-22 00:00Z to 14:12Z):
usage: CI runner x 41 (expected)
anomalies: 14:07Z from 198.51.100.9?? no --
(post-revoke probe attempt, blocked)
evidence: gist snapshot + log export -> incident record
14:30Z scrub public copy (takedown + history note)
15:10Z path fix: pre-push secret scanner live