安全扫描红了，是「修到绿才放行」还是「评估后标记继续走」？一次密钥处置中两个团队的三种做法

【背景】

去年带一个 12 人后端组做安全加固，CI 流水线里加了 Semgrep + TruffleHog 两层扫描。上线三周后，一个典型分歧爆发了：

某支付网关服务，TruffleHog 扫出 3 处硬编码的 JWT signing key（sk_live_... 前缀），都在 2022 年写的一个内部对账脚本里。开发同学的反应是：「这脚本只在内网跑，key 已经用了两年，现在换 key 意味着 4 个下游服务要同步换，排期至少 2 周，而且线上正在跑对账，不能停。」

安全侧（我）的底线是：key 已经进了 Git 历史，按 OWASP 密钥管理基线，它必须视为已泄露，72 小时内轮换。

两边僵了三天，最后走了三条路：

• A 方案（开发推的）：把 key 挪到 K8s Secret，CI 标 # noqa: secrets 跳过，排期 2 周后再做 key 轮换。
• B 方案（我推的）：当天用 git filter-repo 清历史 + 签发新 key + 4 个下游同步切，预计 3 天（需要值班窗口）。
• C 方案（实际走的折中）：当天把 key 从代码挪到 Secret（10 分钟），同时启动轮换流程排到下个迭代；但我在 PR 描述里留了一条「已知风险：旧 key 仍在 Git 历史，窗口期 14 天」，并且加了告警——如果这 14 天内旧 key 在外部 API 网关出现调用记录，立即触发 P0。

【常见分歧 / 几种做法】

我观察到的团队大致分三派：

1. 阻断派：CI 红线就是红线，红了就不合并。好处是零漂移；代价是误报（或低风险项）会拖死发布节奏，开发会绕——比如本地 --no-verify 提 PR、或者把扫描工具从流水线里摘掉。
2. 评估派：扫描结果进 Issue，按 CVSS / 内部风险矩阵打分，高危 48h、中危 2 周、低危进 backlog。好处是合理；代价是「评估」本身需要安全工程师持续在线，人一走评估就停。
3. 工具兜底派：不靠人盯，全靠自动化——比如 key 进了 Git 就自动调 Vault rotate API、依赖漏洞用 Dependabot 自动 PR。好处是零人工；代价是自动轮换如果下游没做好兼容，反而制造事故。

【我的倾向与理由】

我倾向「分级阻断 + 可逃逸但留痕」：

• P0 类（硬编码密钥、生产环境 debug 开关、未鉴权管理接口）：CI 硬阻断，没有例外。理由是这类问题的「修复成本」远低于「泄露后的取证 + 通知 + 补偿成本」，而且拖得越久，攻击面暴露时间越长。
• P1 类（依赖库已知 CVE、不安全的反序列化模式）：允许 waive 但必须填风险说明 + 到期日，到期未修自动升级回阻断。
• P2 类（代码风格级安全建议，如「建议用 parameterized query」但当前实际已经用了）：纯提醒，不阻断。

核心原则：逃逸可以，但逃逸本身要产生一个「债务工单」，有 owner、有 deadline、有升级路径。 我见过太多「先跳过，回头再说」最后变成「没人回头」的案例。

另一个我坚持的细节：阻断规则本身要有「健康度指标」——每周统计误报率（开发标记为 false positive 的比例），超过 20% 就回去调规则。否则团队对扫描工具会失去信任，最终变成「红灯就点忽略」。

【想听大家怎么选】

几个具体问题想征集经验：

1. 你们的安全扫描是「硬阻断」还是「评估后放行」？误报率大概多少？谁来判断误报——开发自己还是安全团队？
2. 硬编码密钥的处置，你们有没有「72 小时轮换」的硬 SLA？如果下游服务多（>10 个），你们怎么协调同步切换？有没有踩过「换了一半、两边 key 不一致导致线上 500」的坑？
3. git filter-repo / BFG 清历史，你们线上仓库跑过吗？有没有遇到 LFS 对象引用断裂、或者 fork 仓库没同步清的情况？
4. 有没有团队真正做到「自动轮换 + 零人工」？用的什么工具链（Vault + Consul Template？AWS Secrets Manager + Lambda？自研？）？

我猜不同规模（<10 人 vs >100 人）和不同环境（全内网 vs 公网 SaaS）的选择会差很多，想听听大家的具体场景。