凌晨两点，漏洞某银行核心系统突然报警——数据库连接数飙到极限。不整值班工程师老周打开日志一看，漏洞上个月安全团队就发过整改通知：某接口存在SQL注入漏洞，不整建议三天内修复。漏洞老周翻了个白眼，不整把工单转给开发组，漏洞备注栏写着“影响核心交易，不整勿动”。漏洞

开发组组长刘姐第二天看到这行字，不整直接删了邮件。漏洞她手头排着三个新功能上线，不整产品经理天天催，漏洞老板每周问进度。不整漏洞？漏洞等出了事再说吧。这种默契在团队里心照不宣——安全部门提的整改，十有八九被当成“流程噪音”。

三个月后，渗透测试报告出来了。那个SQL注入漏洞还在，连带暴露了三个新的越权访问点。安全主管在会上拍了桌子，技术总监打了个圆场：“先记进风险台账，下季度统一安排。”台账是什么？就是给审计看的Excel表，里面躺着三百多条“待整改”，时间最早能追溯到三年前。

说实话，漏洞不整改，真不是技术难题。大部分高危漏洞，修起来就半天工作量。真正的坑在于组织架构——安全部门没有话语权，开发考核看功能上线速度，运维怕改动引发故障。谁愿意为一个“可能出事”的隐患，去背“影响业务”的锅？

去年某电商平台被拖库，八百万用户信息泄露。事后复盘发现，漏洞早在五个月前就报过，当时运营总监说“双十一期间禁止变更”。等大促结束，漏洞被遗忘，直到黑产用它薅走了所有优惠券。你看，不整改的代价从来不是技术问题，是管理问题——没人对“没发生的事故”负责。

我认识一个安全工程师，后来学精了。他不再发整改邮件，直接写“高危风险，建议立即处理”，抄送老板，标题加三个感叹号。开发组还是拖，他就每天在晨会上念一遍漏洞详情，念到第七天，老板终于问：“这玩意儿到底多严重？”他当场打开演示环境，用漏洞把测试账号改成管理员。会议室安静了，第二天开发组主动排期修复。

但更多时候，没这么幸运。漏洞就像墙上的裂缝，你不补，它不会自己消失。只会等某天地震，整面墙塌下来，砸到的恰恰是当初说“先放放”的人。

说到底，整改不整改，拼的不是技术能力，是公司愿不愿意为“看不见的风险”付钱。可惜多数管理者只信“看得见的故障”——服务器宕机了，半小时内必须恢复；数据泄露了，连夜开会追责。唯独漏洞报告躺在系统里，像医院体检单上那个“建议复查”，你看着它，它看着你，谁也不先动。