CVE 告警一年 500 条，开发早麻了——依赖漏洞到底怎么「分级 + 闭环」才不变成走过场？

背景 干了 10 年安全加固，最近帮两个团队做依赖漏洞扫描复盘，一个现象让我很扎心：扫描工具一年报出来 500+ 个 CVE，开发群里的反应是「又是那几条 log4j 之后的老面孔，能上生产的先上」。安全团队每月出一份「风险清单」，开发每月回一句「下个月排期」，两边都觉得自己很努力，但半年后再扫，高危漏洞一个没少。

我把这个现象比作「消防演习」：警报年年响，灭火器年年检查，可一旦真着火，大家发现疏散图上画的出口其实是堵着的——流程在跑，风险没动。

常见的几种做法（我观察到的）

1. 全量阻塞派：所有高危 CVE 必须修复才能发版。优点是底线清晰，缺点是经常把业务排期卡死，尤其老项目里一个十年前的依赖，修一个 CVE 要动半条链路。
2. 白名单豁免派：把「我们评估过、不影响」的 CVE 写进豁免清单，定期复审。优点是务实，缺点是豁免清单会越长越长，复审变成橡皮图章，最后变成「永久豁免」。
3. 只修「被利用中的」：只关注 CISA KEV（已知被利用的漏洞）或供应链攻击情报，其余降级处理。优点是聚焦，缺点是对「没被公开利用但业务真实暴露」的漏洞可能漏掉。
4. 按「暴露面」分级：同一 CVE，在对外服务里是高危，在内网工具里是低危，按实际暴露程度定优先级。优点是贴近真实风险，缺点是要有人持续维护「谁暴露在哪」的地图，成本不低。

我的倾向与理由 我倾向「4 + 3 的组合」：先按暴露面定基础级别，再叠加「是否被在野利用」做加权。理由有三点：

• 安全资源永远有限，「全修」是伪命题，必须把有限精力花在「真可能被坏人摸到」的地方；
• 豁免清单必须有 TTL（建议 90 天自动过期复审），否则就是慢性放弃；
• 闭环的关键不是「修了」，而是「验证修了」——修复 PR 里必须附带一次针对该漏洞的 PoC 复测记录，哪怕是手动 curl 也行，避免「升级版本号就算修好」的错觉。

也想听听大家

1. 你们团队现在是怎么给 CVE 分级的？有没有踩过「豁免清单失控」的坑？
2. 对于「老项目里一个十年前的依赖，修 CVE 成本极高」这种情况，你们是怎么跟业务谈的？
3. 你们有没有把「漏洞修复验证」做成可复现的自动化？还是靠人肉复测？
4. 一个具体场景想请教：一个 CVE 在 CISA KEV 里，但你们的版本其实根本没启用受影响的代码路径，这种情况你们会豁免还是修？

欢迎大家带具体案例来聊，越具体越好。