例外粒度为什么决定安全治理成本

刚开始做安全门禁那会儿，我觉得最爽的时刻就是第一次看到合并请求被干净利落地拦下来——规则编号清清楚楚，修就完了。三个月后再回头看，我发现真正让人头疼的根本不是规则拦不拦得住，而是另一件事：例外。它不像漏洞那样刺眼，但会慢慢把门禁啃成一个筛子。

我踩过最蠢的坑，就是图省事写了一句“全局忽略这条规则”。当时觉得，反正这条规则我们仓库根本用不上，一刀切多痛快。结果呢？半年后同样的规则命中了另一个模块的真实问题，被一起放过了。那次之后我才彻底明白一个道理：例外写得多粗，你的治理成本就有多高。粗粒度省下来的是当下十分钟的配置时间，赔进去的是未来每个季度的复核和排查成本。

粒度的选择其实就一句话：影响范围刚好覆盖被接受的风险，不多不少。规则级例外适用于整条规则在某个仓库里压根不适用的情况，比如规则针对 Java 框架而仓库全是 Python，这种要限定在仓库或分支范围，理由写技术依据，“误报”两个字不算理由。路径级例外适合遗留代码、生成代码或第三方 vendored 代码，但路径写宽泛的 glob 模式就等于没写。依赖坐标级要限定包名和版本范围，绝不能把整块告警级别调低——那等于给下一次真正的依赖风险提前发了通行证。密钥扫描的例外则要绑到具体检测器类型和路径模式上。

我现在的习惯是，例外记录至少要有决策理由、受影响范围、审批人、到期日期、修复计划和责任人。这些字段尽量跟代码放在一起，走合并请求变更——谁在什么时候改了什么门禁行为，提交历史里全留着，比散落在聊天工具里的“已同意”好找一百倍。

还有一个容易忽略的点：到期提醒别只发到一个没人看的邮件列表。把到期时间写进配置本身，再配一个轻量流水线去读它，提前一到两周提醒责任人和复核人。过期后先给个宽限期再切阻断，但宽限期也得有上限，否则又是一个换了马甲的永久例外。

说到底，例外不是错，没有边界的例外才是。每次门禁说“可以”的时候，重要的是知道这句话的有效期到哪天结束。