漏洞管理的一线踩坑实录
2026-11-11 19:39:14
作者：
fawen
上周三凌晨两点我还在接微信电话。
对方是个做中小商户收银系统的创业公司技术负责人，隔着听筒都能听见他那边咖啡机嗡嗡的动静，说等了整整一个月的漏洞整改通知刚下来，业务端还没排期，安全团队已经被监管的预警函追得快躲进厕所了。
我当时听完差点笑出来。
这场景太熟了。几乎每一个找过我的技术团队，提到漏洞管理的第一反应都是”麻烦”——扫描器天天跑，整改通知天天发，大家天天追着填进度表，最后真碰到攻击的时候，还是会发现关键的地方漏了防护。
别把漏洞台账当护身符
很多团队对漏洞管理的认知，还停留在”把扫描结果导成Excel，按优先级排好，凑够整改率交差”的阶段。
我上个月去那个收银系统客户那边做复盘，翻了他们最近半年的漏洞台账，整整327条记录，其中192条是测试环境的旧版本依赖，37条对应已经下线快一年的旧域名，真正在公网生产环境暴露的高危漏洞，满打满算也就21个。安全团队光为了把整体整改率拉到95%的考核线，拉着开发团队花了整整三周，改了一堆根本没人能碰到的配置项。
企业漏洞管理台账Excel截图
80%的漏洞整改延误，根本不是开发不想改，是安全团队从一开始就没把漏洞的真实暴露面算进去。
说穿了，扫描器是不会分辨这个资产是真的在对外提供服务，还是只是内网里一个跑了测试流程的临时节点的。要是把所有扫出来的条目都一股脑塞进整改台账，最后只会把大家的精力耗在无意义的补漏上，真正有风险的点反而被埋在表格的最下面，没人顾得上。
整改排期要贴业务的真实节奏
我之前碰过最离谱的拉扯，是一个做垂类电商的客户。安全团队用扫描器扫出来一个支付接口的SQL注入漏洞，CVSS评分9.8，直接甩了个24小时整改的通知到业务群里，说晚了就要上报给公司管理层。
当时正赶上618大促的第一波预热，业务团队的负责人直接在群里炸了——24小时内改完整个支付链路的校验逻辑，万一出个支付失败的bug，一天的流水损失就是大几百万，这个责任谁担？两边吵了整整三天，最后还是先在WAF上配了精准的拦截规则，把攻击路径堵上，等大促结束的第一周，开发团队花了两个工作日就把代码逻辑调整完了，全程没出任何安全问题。
漏洞风险与业务成本权衡矩阵图
真正靠谱的漏洞管理从来不是追着开发要整改速度，而是在漏洞的暴露风险和业务的可承受成本之间找平衡。
那些上来就要求所有高危漏洞24小时必须改完的团队，本质上是在偷懒。他们根本不想花时间去评估这个漏洞被真实利用的概率有多大，也不想去算临时防护的成本和直接改代码的成本哪个更高，只想拿一个看起来好看的整改速度数据交差。
我还见过更夸张的，为了满足等保测评的整改率要求，安全团队逼着开发把已经下线半年的旧系统重新部署起来，改完上面的两个漏洞，再把系统关掉下线，前后折腾了两周，纯纯的资源浪费。
这不是做安全。
这是演安全。
别等漏洞爆了才补流程
做了这么多年技术编辑，我见过太多团队的漏洞管理流程，都是在出了安全事故之后才临时搭起来的。
之前有个做在线教育的客户，就是觉得自己家的系统用户不多，漏洞扫出来也不着急改，结果被人顺着一个公开的后台弱口令，拖走了30多万条用户的手机号和上课记录，最后光给用户的补偿和监管的罚款就交了快两百万。那个时候再想着补流程，算资产暴露面，找临时防护规则，早就晚了。
其实真要把漏洞管理做顺，根本不需要搞那么复杂的流程。
每次扫描完，先花半小时过一遍所有条目的资产归属，把那些根本没对外服务、甚至已经下线的资产对应的漏洞条目直接删掉，别占大家的精力。给每个需要整改的漏洞标清楚三个信息：这个漏洞的真实攻击路径是什么，被利用之后会影响哪个业务的什么功能，临时防护需要花多少成本。然后按照风险等级定整改周期：真的能直接拿到核心数据的高危漏洞，给7天的整改期，同时配套好临时的WAF规则或者访问限制；只在内网存在、需要突破两层以上边界才能碰到的中低危漏洞，就跟着正常的版本迭代走，给30天的整改周期就行。
每个月抽15分钟，和业务团队同步一次剩下的待整改漏洞，别攒着一摞通知直接甩到群里，没人会认真看的。
不过话说回来，我也不是说漏洞管理可以松松散散的。只是别把精力全花在做台账、凑整改率这些表面功夫上，毕竟你做漏洞管理的最终目的，从来不是为了给审计部门交一份完美的Excel，而是真的能把那些可能被人钻空子的风险点，堵在出事之前。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
漏洞管理的一线踩坑实录
文章链接：https://www.itcdj.com/news/734.html