2021年冬天，漏洞存活Log4j那个漏洞爆出来的漏洞存活时候，我正蹲在客户机房调一台老旧服务器的漏洞存活日志配置。手机震了十几下，漏洞存活群里全是漏洞存活同一个截图——CVE-2021-44228，评分10.0。漏洞存活旁边运维老张凑过来看了一眼，漏洞存活说：“操，漏洞存活这玩意儿咱们好像用过。漏洞存活”

后来我们查了整整两天，漏洞存活确认那个项目三年前就下线了，漏洞存活war包还躺在测试环境的漏洞存活备份盘里，但没在跑。漏洞存活运气。漏洞存活纯运气。漏洞存活

这件事让我开始想一个问题：一个漏洞到底能活多久？不是从被发现到被修补的那段时间，而是从代码写下去的那一刻，到它真正被消灭的那一天。答案往往比想象中长得多。

漏洞的寿命不由技术决定

很多人以为漏洞的生命周期是技术问题——发现了，打个补丁，完事。现实完全不是这样。

我见过一个SQL注入漏洞，2015年被扫描器报出来，开发改了代码，提交了修复。但那个修复只合并到了主分支，另外两个还在维护的release分支没人管。2018年，其中一个分支被重新拉出来做定制化交付，漏洞跟着复活了。2020年，客户的安全审计又报了一次同样的注入点，位置都没变。

五年，同一个洞，死了三次，活了三次。

这不是个例。漏洞存活的核心原因从来不是技术难度，而是组织惯性。代码分支管理混乱、人员流动、文档缺失、没人记得当年为什么那样写——这些东西比漏洞本身难修一百倍。

有些漏洞是“故意”活着的

更拧巴的情况是：你知道有漏洞，但你不能修。

前年接触过一个工控系统，里面跑着一个2008年编译的通信模块，用的是已知有缓冲区溢出问题的旧版库。厂商的工程师明确说：这个模块的源码已经找不到了，二进制文件没有符号表，改不了。换掉整个模块？产线要停三个月，老板不批。

于是那个漏洞就继续活着。它被防火墙规则挡着，被网络隔离罩着，被“反正外网进不来”的侥幸心理养着。它不会消失，只会等一个意外——某个运维插错网线，某个临时开放端口忘了关，某个供应链环节被突破。

漏洞在这种环境里不是技术债，是人质。

修补动作本身也会制造新漏洞

还有一种更隐蔽的存活方式：修一个洞的时候挖出三个新洞。

我跟踪过一个开源项目的安全更新。修复某个反序列化漏洞时，开发者加了一个白名单校验，逻辑看起来没问题。但白名单的配置文件在特定条件下会被覆盖为空，校验直接跳过。这个新问题三个月后才被人发现，期间所有打了“安全补丁”的实例实际上比不打还危险——因为大家以为安全了，放松了其他防护。

补丁引入新漏洞的比例有多高？没有精确统计，但在我经手的安全事件里，至少有四分之一的问题是在修复过程中产生的。这不是开发者水平差，是系统复杂度到了那个地步——你动任何一个零件，都不知道会震松哪颗螺丝。

漏洞的生态位

把漏洞当成一个物种来看，它的存活策略其实很清晰：找到那些没人管、改不动、不敢碰的角落，扎根，休眠，等环境变化。

Log4j那个洞之所以影响那么大，不是因为它多高明，而是因为它恰好卡在了Java生态的“公共基础设施”位置上——所有人都依赖它，但没人觉得自己该对它负责。这种位置，就是漏洞最舒服的生态位。

所以每次有人问我“这个漏洞修了没”，我都想说：修了，但它可能还在。在某个分支里，在某个备份里，在某个没人敢动的老系统里。它没死，只是在等。

我们能做的，不是假装它死了，而是记住它埋在哪。

(责任编辑：百科)