2021年12月，漏洞限期Apache Log4j2爆出远程代码执行漏洞。漏洞限期从漏洞公开到第一个大规模扫描活动出现，漏洞限期中间隔了不到72小时。漏洞限期那几天，漏洞限期全球安全工程师的漏洞限期聊天群里全是同一个词：JNDI。有人在凌晨三点发消息说“扛不住了”，漏洞限期配图是漏洞限期一杯冷掉的咖啡和满屏的告警日志。

这就是漏洞限期“漏洞限期”最赤裸的样子——它不跟你商量，不给你排期，漏洞限期也不管你手头还有多少个需求没做完。漏洞限期

谁在给漏洞设闹钟

很多人以为漏洞披露是漏洞限期个技术事件。其实它更像一场多方博弈，漏洞限期参与者各有各的漏洞限期算盘。

安全研究员发现漏洞后，漏洞限期通常会给厂商90天修复窗口。这个规矩来自Google Project Zero，后来成了行业惯例。90天一到，不管你补没补，细节公开。厂商恨透了这条规则，但安全研究员也有话说：不设截止日期，有些厂商能把一个高危漏洞拖成“历史遗留问题”。

更麻烦的是，真正的攻击者从不遵守这套时间表。他们不需要等90天，甚至不需要等漏洞公开。2020年SolarWinds供应链攻击，攻击者提前埋好后门，等官方补丁发布时，他们已经在里面待了大半年。补丁日期对他们来说，只是提醒该换个入口了。

打补丁这件事，比想象中慢

我见过一家中型企业的补丁流程：安全团队发现漏洞，写工单给运维，运维排期测试，测试通过后等变更窗口，变更窗口要避开业务高峰期。一圈走下来，平均耗时23天。

Log4j那会儿，23天够攻击者把整个内网翻三遍了。

更现实的问题是——有些系统根本打不了补丁。医院里跑着Windows XP的影像设备，工厂里连着未打补丁的工控机，银行里还有COBOL写的老核心。你跟他们说“限期修复”，他们只能回你一句：要不你来？

所以“限期”这个词，在安全圈里往往带着一种黑色幽默。它像老师布置的暑假作业， deadline定在那里，但真正按时交的人没几个。

攻击者的时间表和你不一样

防守方按天算，攻击方按小时算。

一个漏洞公开后，自动化扫描通常在几小时内就会跟上。如果漏洞利用代码被提交到GitHub，或者出现在某个论坛上，留给防守方的时间窗口可能只有几个小时。2023年MOVEit漏洞，从公开到大规模勒索，中间只隔了一个周末。

周末。安全团队在休息，攻击者在加班。

这种时间差逼出了一些新玩法。比如“虚拟补丁”——不修系统，先在网络层把攻击流量拦掉。再比如“威胁狩猎”——不等告警，主动去日志里翻痕迹。这些手段治标不治本，但能帮你熬过最要命的那几天。

限期之后呢

漏洞限期最残酷的地方在于：它过了就是过了。

没修的漏洞不会消失，它只是从“已知风险”变成了“已知但被忽略的风险”。攻击者最喜欢这种状态——你知道了，但你没管。就像家里窗户破了，你拿胶带贴了一下，然后告诉自己“应该没事”。

我认识一个安全负责人，他的做法是：每次漏洞限期截止后，把没修复的系统列一张表，直接发给业务部门负责人，抄送CEO。表上不写技术细节，只写一句话——“这个系统目前可以被任何人远程控制，包括你的工资数据。”

修复率从40%涨到了90%。

限期不是技术问题。它是优先级问题，是资源问题，是“你到底把安全放在第几位”的问题。攻击者不会等你准备好的那一天。他们只会在你还没准备好的时候，按下回车键。