漏洞管理别做成季度突击救火

上周三在河西金鹰楼下的鸭血粉丝店，碰着之前在南京本地电商做安全的老周。

他皱着眉嗦完一口粉丝，说上个月刚被老板骂完。

上个月全公司扫了一轮漏洞，攒了427个高危项，刚把报告甩到开发群里，就收到业务端的消息：618大促的版本要赶上线，所有非核心需求全部往后排，漏洞修复等大促完了再说。

真的亏。

结果大促刚开卖48小时，就被人爬走了近3万条用户的手机号和收货地址——就是那个报告里标了”高危、未授权访问”的接口，没人修。最后赔了用户补偿、监管罚款加起来快20万，老周这个安全负责人，这个季度的绩效直接打了折。

为什么你扫出来的漏洞永远修不完

很多团队对漏洞管理的认知，还停留在”买个扫描设备，每季度跑一次，凑够修复率的KPI就算交差”的阶段。

我见过最离谱的团队，扫描完的漏洞表从2022年传到2024年，状态列永远是”待确认”，连个认领的开发都没有。安全部催一次，开发就说最近迭代太忙，等有空了看，催到最后大家都疲了，报告往共享文件夹一扔，再也没人打开。

企业内网漏洞扫描结果分类统计表

问题根本不是开发不愿意修。

你想啊，扫描报告出来的时候，对应的代码可能都已经迭代了三版，原来写这个接口的开发说不定都离职了。你让现在的开发对着半年前的代码找漏洞，找出来的问题还要抽时间修，占了本来就不够用的迭代排期，换谁都不愿意接这活儿。

别把漏洞扫描当成漏洞管理的终点。扫描只是把问题找出来，真正难的是怎么让这些问题被合理的人、在合理的时间点修掉，而不是攒成一堆烂账等着爆雷。

老周他们后来换了个思路，再也不搞季度大扫描那套了。

他们把原来挂在季度末的检测节点，全拆到了日常开发的流水线上：开发提交代码的时候，自动跑静态代码检测；测试环境部署完成后，自动跑动态应用扫描；引入第三方开源组件的时候，自动同步组件的漏洞库。有高危问题的代码，直接在流水线里打回，根本等不到上线后再出问题。

就这么改了两个多月，原来平均14天的漏洞修复周期，直接降到了2天。根本不用安全部天天在群里催，因为问题刚出现的时候，写代码的人还对这段逻辑熟得很，修起来根本不费时间。

说实话，很多团队总觉得上安全检测要占很多开发时间，实际上你把节点嵌在本来就要走的流程里，根本不会额外增加多少工作量。反而等漏洞攒了几个月再修，要花的时间是现在的十几倍。

我接触过不少团队，给安全部定的KPI特别简单：季度高危漏洞修复率95%以上。

听着挺合理对吧？但实际执行起来全是歪路。为了凑这个数，大家会先挑那些好修的低危、中危漏洞先搞定，那些要动核心逻辑、可能影响业务稳定性的高危漏洞，就被归到”历史遗留、暂不处理”的类别里，不算在KPI的分母里。

去年有个做在线教育的团队，对外吹自己漏洞修复率100%，结果上线的支付接口有个越权漏洞，被人刷了几十万块的免费课程。查来查去才发现，这个漏洞是三年前的版本写的，现在的开发团队根本没人对这段代码负责，统计KPI的时候直接把它排除在外了。

修复优先级从来不是按漏洞的CVSS评分定的，是按它对业务的实际影响定的。一个影响用户数据泄露的漏洞，哪怕评分只有7分，也比一个影响后台某个无权限访问的静态页面的9分漏洞要急得多。

说实话，漏洞管理从来没有什么一劳永逸的完美方案。你不需要买最贵的扫描设备，也不需要招一堆安全专家天天盯着服务器，只要别把这事儿攒到出事了再突击救火，就已经超过行业里80%的团队了。

哦对，老周现在每次迭代会专门留半天的安全缓冲时间，再也不搞季度末拉着全公司熬夜扫漏洞的事儿了。上次吃完粉丝，他说现在最大的好处是，再也不用天天盯着告警群，怕半夜接到电话说出事了。