漏洞应对策略

2021年12月，漏洞Log4j2爆出远程代码执行漏洞，应对全球数百万台服务器在几天之内暴露在攻击面下。策略运维群里炸了锅，漏洞有人连夜升级版本，应对有人直接写规则拦截JNDI请求。策略同一个漏洞，漏洞不同团队的应对应对速度差了整整两天。两天，策略足够攻击者扫描完半个互联网。漏洞

漏洞应对这件事，应对真正拉开差距的策略不是技术深度，而是漏洞暴露窗口——从漏洞公开到你完成修复之间的那段时间。这段时间越短，应对你越安全。策略道理简单，但做到很难。

先搞清楚你手里有什么

很多团队连自己跑了哪些服务、依赖了哪些组件都不清楚。Log4j那次，有人被通知了才知道自家系统里藏着一个两年前的日志库。这不是个例。资产清单做不扎实，后面所有应对都是盲人摸象。

我见过一个中型互联网公司的做法：他们把SBOM（软件物料清单）生成嵌进了CI流程，每次构建自动输出依赖树。漏洞爆发时，安全团队直接查清单，十分钟定位到受影响的十几个服务。没这份清单的团队，花了两天才理清范围。

CVSS评分有用，但不能只看分数。一个CVSS 9.8的漏洞，如果只影响你内网一台不存数据的测试机，优先级可以往后放。反过来，一个CVSS 7.5的漏洞如果卡在支付链路上，你得立刻动手。

判断优先级看三个维度：可达性（攻击者能不能碰到）、影响面（碰了之后能拿到什么）、利用难度（有没有公开EXP）。三个都高危，别开会了，直接修。

打补丁最干净，但现实里经常打不了。老系统依赖冲突、供应商还没出补丁、升级窗口排不开——这些情况太常见了。

临时缓解手段该用就用。WAF加规则、关闭特定端口、限制外网访问、在负载均衡层做流量过滤。Log4j那会儿，有人直接在JVM参数里禁用JNDI的远程加载类，虽然不优雅，但管用。关键是缓解措施要有时间表，不能变成永久方案。临时手段拖着不换，迟早出事。

技术问题通常能解决，沟通问题往往拖后腿。安全团队发现了漏洞，开发团队觉得优先级不高，运维团队说变更要走流程——三方一扯皮，窗口期就过去了。

有效的做法是提前定好规则：什么级别的漏洞可以跳过常规变更流程，谁有权拍板，多久必须响应。把这些写在纸面上，出事的时候直接按规则走，省掉大量扯皮时间。

漏洞修复的收尾动作经常被忽略：确认修复生效了吗？有没有遗漏的实例？攻击者是不是已经进来过了？

最后一条尤其重要。修补漏洞和排查是否已被入侵是两件事。有些攻击者拿到权限后会留后门，你补了漏洞，后门还在。查日志、看异常进程、检查外连——这些步骤不能省。

漏洞不会消失。你用的每一个开源组件、每一层依赖，都可能成为下一个入口。能做的是把暴露窗口压到最短，把流程磨到最顺。剩下的，就是接受这件事永远不会结束。