漏洞修复太慢

一个高危漏洞从被公开到厂商推出补丁，漏洞平均要等多久？修复IBM安全团队去年给出的数字是：60天。如果这个漏洞恰好落在某个关键基础设施系统里，太慢60天足够攻击者把整个内网翻个底朝天。漏洞更讽刺的修复是，很多漏洞的太慢利用代码在补丁发布前就已经在暗网流通了。修复速度跟不上攻击速度，漏洞这早就不是修复新闻，但问题一直摆在那里，太慢没人真正解决。漏洞

我认识一个做运维的修复朋友，他们公司用的太慢某款企业级VPN设备去年爆出一个远程代码执行漏洞。厂商的漏洞回应是“正在评估”，然后拖了整整43天才放出补丁。修复这43天里，太慢他们只能靠防火墙规则临时封堵，但攻击者换个端口就能绕过。他跟我说，那段时间每天上班第一件事就是看安全邮件列表，生怕看到“在野利用”四个字。补丁出来那天，他连夜升级了所有节点，凌晨三点才回家。这不是个例。很多厂商的漏洞响应流程长得离谱——先确认，再复现，再排优先级，再写补丁，再测试，再发布。每一步都合理，加起来就是灾难。

为什么这么慢？根源在于激励错位。厂商卖的是功能，不是安全。补丁开发不产生收入，反而消耗工程资源。一个漏洞如果没被公开，厂商恨不得永远不修。只有当漏洞被曝光、客户开始施压、媒体开始报道，修复才被提上日程。这种被动模式导致补丁永远在追着攻击跑。更糟糕的是，很多老旧系统的代码库早就没人维护了，修一个漏洞可能要重写整个模块。某工业控制系统的补丁延迟超过180天，原因就是底层驱动是二十年前的，原开发者早就不在了。

攻击者那边呢？他们可没有流程审批。一个漏洞公开后，几小时内就能看到武器化的利用脚本。自动化工具让攻击门槛低到脚本小子都能上手。防守方还在等补丁，进攻方已经在扫描全网了。这种时间差就是攻击者的窗口期，而且窗口越开越大。我见过一个数据：从漏洞公开到首次在野利用，中位数时间已经缩短到不到一周。补丁呢？还是平均两个月。这中间的五十多天，防守方基本在裸奔。

有人会说，那就用虚拟补丁、微隔离、EDR顶着。这些手段有用，但都是权宜之计。虚拟补丁只能挡已知的攻击模式，稍微变种就失效。微隔离部署复杂，老旧系统根本装不上。EDR误报率高，运维人员被告警疲劳折磨得麻木了。真正靠谱的还是原生补丁，但原生补丁就是慢。这不是技术问题，是流程问题和商业问题。厂商没有动力加快，客户没有筹码施压，监管没有牙齿咬人。

我有时候觉得，漏洞修复的速度其实反映了一个组织的真实安全优先级。嘴上说安全第一，行动上补丁拖两个月，那安全就是倒数第一。真正重视安全的团队会怎么做？他们会提前和厂商签支持合同，要求漏洞响应SLA；他们会自己搭建补丁测试环境，把升级周期从周压缩到天；他们甚至会资助开源项目的安全维护。但这些做法成本高、麻烦、不酷。大多数人还是选择等，等厂商发补丁，等别人先中招，等自己运气好。

漏洞修复太慢，慢的不是技术，是决心。攻击者不会等你准备好。他们已经在路上了。

很赞哦!（24411）