6月17日凌晨两点，网络运维值班的安全老张被短信告警炸醒。一台对外提供API服务的事件说明服务器CPU飙到98%，持续了整整七分钟。漏洞他爬起来连上VPN，整改发现Web日志里有一条奇怪的情况请求路径，长度超过两千个字符，网络后面跟了一串类似命令拼接的安全参数。老张没敢重启，事件说明先做了流量镜像，漏洞然后把这台机器从负载均衡里摘了。整改事后复盘，情况攻击者利用的网络是一个三年前就公开过的反序列化漏洞——但那个系统一直没打补丁。

这件事不是安全孤例。我翻了过去半年经手的事件说明十几份漏洞整改报告，发现一个共性：真正被利用成功的漏洞，八成以上是“已知但未修”的老问题。不是零日，不是高级持续性威胁，就是明晃晃挂在扫描器报告里、被标记为“中危”甚至“低危”的那些条目。安全团队催了三次，开发说排期紧，运维说变更窗口不够，最后谁也没动手。

拿这次出事的系统来说，漏洞本身在2021年就被公开了。厂商补丁也发了。但内部资产台账里，这台机器登记的操作系统版本是错的，导致漏扫工具一直没匹配到正确的CVE编号。你说这是技术问题还是流程问题？都是，但归根结底是人的问题。资产管不清，后面所有事都是空中楼阁。

整改动作分了三步走。第一步是止血：当天凌晨四点，临时在WAF上加了一条规则，拦截所有包含特定反序列化特征字符串的请求。这玩意儿只能挡脚本小子，真遇到会绕的照样穿。第二步是根除：第二天上午十点，走紧急变更流程，给那台服务器打了补丁。补丁不大，重启只花了九十秒。讽刺的是，从决定修到修完，前后不到两小时——之前拖了三个月。第三步是排查：用同样的指纹去扫全网，又揪出四台同版本未修复的机器。其中一台是测试环境，但数据库连接串指向生产库。要是攻击者先摸到测试机，照样能横向进去。

这里面有个细节值得说。补丁打完当天下午，安全团队想验证漏洞是否真的被封堵，于是用内部扫描器复测。结果扫描器报“仍然存在”。一群人又紧张起来，查了半天发现是扫描器的插件版本太老，把已经修复的响应特征误判了。工具不是万能的，别把扫描结果当圣旨。人得自己会看流量、看日志、看进程行为。

整改报告我写得比较直白，没堆术语。漏洞成因就一句话：资产台账不准导致漏扫覆盖不全，叠加变更流程僵化，让一个三年前的漏洞活到了现在。影响范围写了实际被利用的那台机器，以及理论上可横向的另外四台。修复措施分临时和永久两层，临时措施明确标注“仅能缓解，不能根治”。后续计划只列了两条：一是把资产盘点从季度改成月度，二是给中危以上漏洞设72小时强制修复窗口，超时自动升级到CTO。

有人问，为什么中危也要强制？因为攻击链里中危漏洞往往是跳板。单独看一个信息泄露或者一个SSRF，好像危害不大。但把它们串起来，就能从外网摸到内网，从低权限爬到域管。我见过太多案例，最后打穿整个环境的起点，就是一个被所有人忽略的“中危”。

报告交上去之后，CTO批了，但加了一条：所有紧急变更必须同步通知业务方，不能安全团队自己闷头干。这条加得对。那次打补丁虽然只重启了九十秒，但恰好赶上某个大客户在跑批量任务，断了。客户投诉到销售那边，销售又来找安全团队吵架。安全不能只管自己爽，得把业务影响算进去。后来我们改成了滚动重启，分批摘节点，虽然多花二十分钟，但业务无感知。

最后说个观察。很多团队把漏洞整改当成一个“关闭工单”的动作。扫出来，修掉，关单，完事。但真正的整改是改流程、改习惯、改认知。比如那次之后，我们要求每个开发在提交代码时，必须跑一遍依赖组件的CVE检查。不通过就卡住合并请求。一开始怨声载道，三个月后大家习惯了，反而主动来问“我这个库版本是不是太老了”。安全这事，靠人盯人永远盯不住，得把卡点嵌到日常工具链里。

老张后来跟我说，那天凌晨他其实可以先重启再查。但他没这么做，因为上次重启把内存里的证据弄丢了，被事后审计骂了一顿。这次他学乖了。你看，人都是在吃亏里长记性的。漏洞整改也一样，不出事的时候推不动，出了事跑得比谁都快。问题是，能不能在没出事的时候，就把该做的做了？