把漏洞管理从救火清单变成日常台账

上周三晚上十点半，我在软件大道口的全家便利店碰到老陈。

他蹲在店门口的台阶上啃肉包，手机屏幕亮着，是密密麻麻的漏扫告警列表。

他说这周已经连续加了四天班。上周刚清完去年遗留的三个高危组件漏洞，这周新爆出的Spring核心框架变种漏洞就弹在监控告警里，业务端的618活动页还等着提测，整个团队的排期表上根本腾不出半天的时间做全量漏扫。

“真的要熬不动了。”他咬了一口包子，油蹭到了运维服的袖口上。

别把漏洞管理等同于扫漏工具跑批

很多团队对漏洞管理的认知，到现在还停留在“买个漏扫工具，每周定时跑一遍，把标红的高危漏洞派给开发改完就算交差”的阶段。

老陈他们团队就是这样。去年年底花了十几万采购的漏扫系统，到现在规则库快半年没更新，扫出来的结果一半是误报。比如把测试环境跑的临时组件报成生产环境的高危漏洞，开发熬了两个通宵改完，才发现对应的服务根本没对外上线，纯纯白忙活。

漏扫工具的规则库如果超过3个月不更新，误报率会飙升到40%以上，很多团队为了凑漏洞整改的完成率，对着一堆误报折腾，真正藏在生产环境的漏洞反而没被扫到。

还有个更离谱的情况，老陈说他们公司有个2019年就上线的老订单系统，上面跑着已经停止维护的Struts2组件，对应三个CVSS9分以上的漏洞，但是这个系统现在只有财务部三个人用，根本不对外暴露。之前团队为了凑整改率，硬要排期重构这个系统，财务那边直接拍桌子——重构期间打不了订单，影响的流水谁赔？

最后还是找了网络组在前面加了访问白名单，把外部的访问全拦了，才把这个事压下来。

漏洞的优先级从来不是CVSS分值说了算

之前和很多安全团队聊天，发现大家排漏洞整改优先级的逻辑特别简单：拿漏扫工具导出的CSV表，按CVSS分数从高到低排，9分以上的一周内改完，7到9分的两周内改完，低于7分的就扔在列表里没人管。

这逻辑真的站不住脚。

CVSS分值只是漏洞本身的严重程度参考，和实际的业务风险没有直接对等关系。

就像老陈他们上周扫出来的那个Fastjson漏洞，CVSS评分9.8，但是对应的组件只在内部的测试环境跑，根本没有对外暴露的接口，就算漏洞能被远程利用，黑客也摸不到这个服务的边，整改的优先级完全可以往后排。

反倒是有个CVSS7.2的Apache日志组件漏洞，对应的是对外的用户登录接口，而且前一周刚有同行业的公司被利用这个漏洞拖走了用户数据库，这种漏洞就算分数不高，也要排到最前面优先改。

我之前见过太多团队，为了赶合规要求的整改率，把所有高分值的内部测试环境漏洞改完，结果对外的核心业务系统因为有个低分值的SQL注入漏洞被拖库，得不偿失。

老陈他们后来改了评估逻辑，不再唯分数论，先把所有资产按暴露程度分成三档：对外可访问的核心业务系统、内部办公用的非核心系统、完全离线的僵尸遗留系统。每档资产对应的漏洞，再看有没有在野传播的利用POC、会不会直接影响核心业务数据，最后才排整改顺序。改完之后，他们团队每周处理的漏洞数量少了一半，但是实际的风险敞口降了60%多。

别等漏洞爆了才想起来补台账

说穿了，绝大多数团队的漏洞管理做的累，根本不是整改慢，是从一开始就没搞清楚自己到底有多少资产。

老陈他们之前出过一次事。去年双11的时候，临时上了个促销的落地页，活动结束之后大家都忘了把这个服务下线，对应的域名快过期了也没人管，结果被黑客扫到了页面上的SQL注入漏洞，偷了三千多条用户的收货地址信息，光合规罚款就交了小二十万。

后来复盘的时候才发现，他们的资产台账还是2021年导出来的，上面列的系统一半都已经下线了，新上的二十多个微服务、临时的活动落地页，一个都没在台账里记。漏扫工具根本扫不到这些没登记的资产，自然也就发现不了上面的漏洞。

资产台账的动态同步，才是漏洞管理效率提升的核心前提。

老陈他们后来改了流程，把资产登记的要求嵌到了上线的流程里——不管是新上的服务还是临时的活动页，只要要对外暴露端口，就必须先在资产台账里登记对应的组件、负责人、业务关联，对应的信息会自动同步到漏扫系统里，不用等漏扫工具去盲扫。

现在他们每周的漏洞复盘会，不再对着厚厚的漏扫报表念数字，而是对着实际的攻击面清单核对：这周有没有新多出来的对外端口，有没有公开的POC对应到他们在用的组件，有没有已经下线的资产还在跑服务。开发改漏洞的平均时间从之前的7天，降到了现在的2天，因为再也不用对着一堆误报和无关的漏洞折腾。

上周我又在那个便利店碰到老陈。

他这次没蹲在台阶上，点了杯热奶茶，说现在不用天天熬到半夜了。上周618的活动页上线之前，系统自动同步了所有用到的组件信息，提前发现了两个小版本的依赖漏洞，提前两天就改完了，没出乱子。

他说之前总觉得漏洞管理就是要把所有漏洞都清干净，现在才想明白——哪有什么零漏洞的系统，把真正会影响业务的风险兜住，就已经比大多数团队强了。