凌晨一点二十。群里有人甩了个链接，带一个 CVE 编号，后面跟了三个感叹号。
然后就是熟悉的流程：安全同学导出一份 Excel，两千多条，直接扔进项目群，标题写着「本周待修」。没人回复。第二天早上项目经理问了一句，先修哪个？群里又安静了。
这种画面，做过乙方驻场的应该都见过。我倒不是说谁不负责——是真的没法接。
扫描器给你的不是优先级，是一份焦虑清单
很多人对漏洞管理的想象，是装个扫描器，跑一遍，出报告，修。完事。但扫描器本质上只会做一件事：告诉你「这里有东西」。它不知道你的业务长什么样。
举个我印象很深的例子。一个跑在内网、只对两台机器开放 8080 的测试环境，扫出来一个 CVSS 9.8 的反序列化。另一边是对公网开放的支付回调接口，扫出来一个 7.5 的越权。
数字上 9.8 赢。业务上，答案反着来。
所以 CVSS 这玩意儿得用，但不能只用。这几年我越来越习惯把 EPSS（大概可以理解成「这个漏洞在未来 30 天里被真实利用的概率」）和 CISA 的 KEV 目录（已知被在野利用的漏洞清单）放在一起看。CVSS 高、EPSS 低、也不在 KEV 里的，大概率可以排到下一个迭代；反过来的，哪怕只有 5.0，也建议当天动手。
这里有个坑：别指望靠一套公式自动算出优先级。资产重要性、暴露面、有没有 WAF 挡在前面、能不能被横向移动——这些信息只在你们公司内部，不在任何一个漏洞库里。公式只能算前半段，后半段得靠人拍脑袋。
没人认领的漏洞会一直躺在那儿
很多团队的漏洞管理其实卡在流程，不是卡在技术。
我见过一个很典型的情况：安全团队发单，研发团队接单，但研发说「这个组件是基础架构的」，基础架构说「这机器是业务方自己申请的」。一圈下来两周过去了，漏洞还在原地。
我的看法是：漏洞必须有明确的责任人，而且这个责任人不能是安全团队。安全团队是裁判，不是运动员。裁判自己下场踢球，这比赛就没法看了。
实操上我比较推荐按资产归属来切。谁申请的机器，谁负责；谁写的服务，谁负责。资产台账不准的话，先花两周把台账理顺——这一步特别枯燥，但它是后面所有事情的地基。台账不准，你连「这个漏洞影响几个业务」都答不上来。
另外，SLA 别定太细。见过一个团队定了七档修复时限，从 24 小时到 90 天，最后没人记得住。留三档就够了：紧急（在野利用或者暴露在公网的核心资产）、常规、计划内。
让它变成排期表里的一行，而不是一份报告
说到底，漏洞管理最后拼的是排期。
几个我踩过坑之后留下来的土办法。
第一，把修复动作拆到「可验收」的粒度。「升级 log4j 到 2.17」比「修复 log4j 漏洞」清楚太多。前者能验收，后者只能扯皮。
第二，能靠基线和镜像解决的，别交给研发。基础镜像里的 OpenSSL 版本、统一的 JDK 版本，这些在 CI 流水线里拦掉就行，根本不该进工单系统。让研发手工改，改一百次错八十次。
第三，误报要有出口。扫描器的误报是会消耗信任的。第一次误报，研发认真看；第五次误报，研发直接点忽略。所以得有人定期去核误报，把比例压下来。这活儿不性感，但特别值钱。
第四，复盘别只复盘「修没修」，复盘「为什么引入」。一个组件漏洞反复出现三次，那就不是修的问题了，是依赖管理本身出了问题——比如有人手工往 lib 目录里丢 jar 包。
最后说个反直觉的观察。不少团队把「漏洞清零」当 KPI，结果就是季末突击修一批，下个季度照旧。比起清零，我更看重两个指标：高危漏洞的平均存活时间，以及重复出现率。前者看效率，后者看根因有没有被真正解决。
慢一点也没事。真的。