2021年12月，漏洞风险Apache Log4j2 被曝出一个远程代码执行漏洞。漏洞风险攻击者只需要往被攻击系统里注入一段特定字符串，漏洞风险就能在服务器上执行任意命令。漏洞风险这个叫 Log4Shell 的漏洞风险漏洞，CVSS 评分满分10分。漏洞风险那几天，漏洞风险全球安全工程师的漏洞风险周末全没了。有人半夜爬起来打补丁，漏洞风险有人盯着日志看到天亮。漏洞风险一个日志组件，漏洞风险平时谁在意它？漏洞风险偏偏它躺在几乎所有 Java 应用的依赖链里。

漏洞这东西，漏洞风险平时没人想它。漏洞风险等到出事，漏洞风险才发现它像水管里的锈——你看不见，但水一直在渗。

我见过一个中小企业的运维负责人，他的服务器跑着一套五年前部署的 CMS。后台登录页面还挂着默认管理员路径，密码是 admin123。我问他为什么不改，他说：“这系统就内部几个人用，外网访问不到的。”后来我扫了一下，那台机器 8080 端口直接暴露在公网。不是他主动暴露的，是防火墙规则写错了，一条 any 到 any 的规则静静躺了三年。

这就是漏洞风险最麻烦的地方：它往往不在你盯着的地方。你检查了应用层，忘了系统层；补了系统层，忘了第三方库；补了第三方库，忘了配置项。每一样单独看都没问题，叠在一起就是个筛子。

更让人头疼的是时间差。从漏洞公布到补丁可用，可能几小时，也可能几周。而从补丁可用到你真正打上去，中间隔着测试、审批、变更窗口、业务低峰期。攻击者不需要走这套流程。他们拿到 PoC 就能开工，自动化扫描器几分钟就能扫完一个 B 段。你还在排变更计划，人家已经拿到 shell 了。

有人觉得，小公司没人盯上。这话对了一半。定向攻击确实看不上小目标，但批量扫描不分大小。一个自动化脚本跑过去，谁有洞就打谁，跟钓鱼一样，广撒网。你的服务器被拿去挖矿、当跳板、发垃圾邮件，你甚至不知道。等云厂商发来欠费通知或者滥用警告，才反应过来。

我自己的习惯是，新项目上线前先跑一遍依赖检查。不是信不过开发，是信不过那些间接依赖。你引入 A 库，A 依赖 B，B 依赖 C，C 有个已知漏洞。你连 C 的名字都没听过。SBOM 这东西喊了好几年，真正落地的团队还是少数。

漏洞风险没法归零。你只能压缩暴露面，缩短修复窗口，然后接受剩下那点不确定性。打补丁不丢人，丢人的是明明知道有洞还假装没看见。安全这行干久了，会变得有点偏执。看到开放端口想扫，看到旧版本想升，看到默认配置想改。这种偏执不讨喜，但能让你少接几个半夜的电话。

Log4Shell 过去几年了。下一个“Log4Shell”什么时候来，没人知道。但可以确定的是，它已经在某个依赖树的深处等着了。你唯一能做的，是别让它在你的系统里住得太舒服。