上周跟南京河西一个做工业物联网的朋友吃夜宵，他扒着小龙虾跟我吐槽，上个月凌晨两点被客户的电话炸醒——生产网里扫出来个变种Log4j，全组人熬了三个通宵逐台机器打补丁，最后翻记录才发现，这个漏洞三个月前第一次扫描就报过，当时排期排到了半年后的系统重构节点，大家转头就忘了。
我当时嘴里的冰粉都差点掉出来。
大部分团队的漏洞管理，本质是在做临时抱佛脚的记账
很多团队现在的流程说穿了特别敷衍：漏扫工具定时跑一遍，导出个几千行的Excel，按CVSS分数给高危标个红，丢给开发团队就完事。
没人跟进。
过俩月漏扫再跑一轮，上次标红的高危漏洞还在系统里躺着，于是再发一遍通知，再催一遍，循环往复。
我上个月去一个做本地生活的团队做访谈，翻他们的漏洞台账吓一跳——2022年报的一个后台弱口令漏洞，到2024年还挂在“待处理”栏里。问为啥，说当时负责那个后台的开发已经离职两年了，新来的团队没人知道这个老系统归谁管，就一直晾着。
很多人对漏洞管理的误解特别深，觉得这事儿的终极目标就是“把所有漏洞都清零”。
根本不可能。
尤其是那些跑了五六年的遗留系统，上面叠了几十层二次开发的补丁，你动个Nginx配置都可能把整个业务链路搞崩，谁敢随便改代码？我见过太多团队为了追“漏洞清零”的KPI，最后逼着开发把漏洞的访问路径直接封了，表面上台账上的数字变好看了，实际上该存在的风险一点没少，哪天配置错了，漏洞直接露在公网上。
别拿CVSS分数当唯一的风险判断标尺
现在绝大多数团队的漏洞优先级逻辑简单到可笑：CVSS9分以上的7天必修，7分以上的30天必修，剩下的低危可以无限期挂着。
真的对吗？
你一个没有公网映射、只在内网测试环境跑的demo系统，就算有个满分10分的RCE漏洞，至于全组人熬通宵去打补丁？反过来，你一个直接对接用户支付的对外接口，就算有个CVSS只有6.5的越权漏洞，你敢等30天再修？
去年有个做跨境独立站的客户找我复盘，说他们之前就是严格按CVSS分数排优先级，把一个能爬全量用户收货地址、手机号的越权漏洞标成了中危，排到了两个月后的大版本迭代里。结果中间被黑产盯上，爬走了十几万条用户数据，光监管罚款加用户赔偿就掏了两百多万。
亏得肉疼。
其实判断一个漏洞该不该优先处理，根本不需要被那套分数绑死。核心就看三个维度：这个漏洞能不能从公网直接触达，触达之后能拿到多少核心敏感数据，修复这个操作会不会直接影响正在跑的业务。三个维度占俩，就算CVSS分再低，也得排在最前面。
很多团队花大几十万买的漏扫设备，跑出来的报告跟免费开源工具扫出来的没区别——只会告诉你“这里有个洞，分数多少”，根本不会帮你算这个洞离你的核心业务有多远。这钱花得，跟买了个只能拍模糊照片的相机有啥区别。
真正落地的漏洞管理，从来不是安全岗一个人的事
我见过太多团队的责任划分，说起来都好笑：漏扫是运维的活，记台账是安全岗的活，修漏洞是开发的活，上线验证是测试的活。等出了安全事件，大家互相推。
运维说我扫出来第一时间发群里了，开发不修关我啥事；开发说我手上排着三个业务迭代需求，哪有空管你这个非业务类的改动；安全岗说我在群里@了八遍了，大家都不动我有啥办法。
最后漏洞还在那，风险还在那。
之前接触过一个做企业SaaS的团队，他们的做法就特别实在：每个系统从第一次上线部署开始，就直接定好对应的漏洞责任人，不按部门划，按业务模块划——比如用户中心模块，不管是负责写代码的开发，还是负责运维的工程师，还是负责测试的同学，只要是跟进这个模块迭代的核心成员，就要对这个模块的漏洞修复进度负责。
每个月就开半小时的短会，过一遍上个月的漏洞台账。哪个洞拖了超过30天，对应的责任人直接说原因：是修复要改核心代码怕影响业务，就排到最近的迭代窗口一起上；是老系统要重构暂时动不了，就提前在WAF上把对应的攻击路径拦上，别光把漏洞挂在台账上积灰。
说实话，我见过太多团队砸几百万搭安全体系，最后连哪个老系统归哪个团队管都没理清楚。
挺荒谬的。
漏洞管理从来不是什么需要高深技术的高大上项目。说白了就是写字楼的物业，每天绕着楼转一圈，看看哪个消防通道堵了，哪个门禁坏了，记下来告诉对应的业主，该疏通的疏通，该换锁的换锁。别等火都烧到门口了，才想起来哦原来我们楼里还有物业这个岗位。