一个用了七年的漏洞开源库，上周被爆出远程代码执行漏洞。漏洞维护者凌晨三点发了补丁，漏洞早上七点，漏洞GitHub上已经有二十多个项目在CI里挂了——因为依赖锁定的漏洞版本太旧，新补丁根本拉不进去。漏洞这不是漏洞段子，是漏洞上周真实发生的事。

漏洞这东西，漏洞以前是漏洞"发现一个修一个"，现在变成了"修一个，漏洞炸一片"。漏洞原因不复杂：软件越写越像搭积木，漏洞你用的漏洞库依赖别人的库，别人的漏洞库又依赖另一个人的库。一层套一层，最后谁也不知道最底下那块积木是谁放的、什么时候放的、有没有人还在管。Log4j那次就是典型，一个日志组件，几乎没人直接调用它，但它藏在几百个框架的深处。漏洞一出，全球安全团队连夜排查，有人发现自己项目里间接引用了它，但连源码都没打开看过。

更麻烦的是修复速度追不上披露速度。以前一个CVE编号能活几个月，现在从PoC公开到被大规模利用，可能不到48小时。攻击者也在用自动化工具扫资产，你今天没打的补丁，明天就是别人的入口。有个做安全运维的朋友跟我说，他们内部有个"补丁债"表格，列了三百多个待处理项，排期排到明年。领导问为什么不能一次全修，他说：修完业务就停了。

供应链攻击也在变多。不是直接打你，而是打你信任的上游。npm包投毒、PyPI抢注相似包名、CI/CD流水线里插恶意脚本——这些手法越来越常见。去年有个案例，攻击者往一个流行UI库的依赖里塞了段代码，专门检测环境变量里有没有AWS密钥，有就悄悄传走。这个包在npm上待了整整两周才被下架，下载量几十万次。你装的时候不会看那么细，`npm install`一敲，信任就交出去了。

还有个容易被忽略的点：很多漏洞根本不是"新"的，是旧代码里埋了十年的雷。C语言里的内存问题、老框架里的反序列化、配置模板里的注入点——这些东西在写的时候没人觉得是问题，因为当时的攻击面没这么大。现在系统联网了、API暴露了、数据值钱了，老代码突然就成了靶子。你不可能把十年前的代码全重写一遍，但攻击者可以拿今天的工具去扫十年前的逻辑。

修复这件事本身也在变形。以前打个补丁重启服务就完了，现在要过兼容性测试、要评估性能影响、要跟上下游对齐版本。微服务架构下，一个漏洞可能涉及十几个服务，每个服务的修复窗口不一样。有次我参与处理一个中间件漏洞，光是确认哪些服务真正受影响就花了两天——因为服务清单是过时的，有人改了端口没更新文档。

漏洞不会越来越少。系统越复杂、依赖越深、迭代越快，暴露面就越大。这不是悲观，是算术。你能做的，是把"发现-评估-修复"这条链路缩得尽量短，别让补丁债滚成雪球。至于那些藏了十年的老代码——只能祈祷它别在你负责的模块里爆。