凌晨两点十七分，系统修复监控大屏上那条红色告警线终于跳了出来。漏洞数据库服务器的报告CPU占用率曲线像被掐住脖子的蛇，直挺挺地冲上99%。系统修复我灌了口凉透的漏洞咖啡，知道今晚又得跟那伙人打一场拉锯战——他们撬开了我们CRM系统的报告一个边角料漏洞，正往里面灌垃圾数据。系统修复

这个漏洞其实藏得挺深。漏洞上周做安全巡检时，报告扫描器报了个中危项，系统修复说是漏洞某个第三方登录组件存在越权访问风险。当时我看了眼详情，报告觉得影响范围有限，系统修复就把它排进了下个迭代的漏洞修复清单。谁知道对方比我的报告排期更着急，三天后就利用这个口子摸进了客户信息表。幸好他们只是写入了一堆乱码，没真把数据拖走，但这件事让我彻底改了性子——漏洞这东西，你永远不知道它会在哪个深夜咬你一口。

修复过程倒没太多戏剧性。先切断那个组件的网络映射，把受影响的表做了快照备份，然后直接在代码层面把越权判断补上。真正麻烦的是事后排查。我翻了两天日志，从几十万条访问记录里揪出了那几行异常请求，顺着IP反查，发现对方用了三层跳板，最后落在某个海外VPS上。追到这儿就断了，但至少确认了一点：不是内部人干的，也不是什么高级攻击团伙，就是有人用自动化脚本在扫全网漏洞，刚好撞上了我们的门。

这事给我提了个醒。以前总觉得安全团队报的那些中危漏洞可以缓一缓，优先赶业务功能才是正事。但那次之后，我把修复流程改了——高危漏洞四小时内必须处理，中危的也要在两天内给出明确方案，哪怕先打个临时补丁顶着。代价是开发节奏慢了点，但换来的是半夜不用再被电话吵醒。

报告写完的时候天已经亮了。我盯着屏幕上那行“已修复，影响范围受控”的绿色状态，忽然觉得挺讽刺的——我们花了大价钱买防火墙、装入侵检测、搞渗透测试，最后真正防住事的，反而是那次被逼着加班补上的一个小判断逻辑。安全这事，说到底不是靠堆设备，而是靠对每个可疑入口的较真劲儿。

现在那个第三方组件还躺在系统里，但我给它加了双因子认证，每次调用都强制校验会话上下文。日志审计也从每天一次改成了实时推送，稍有风吹草动，我的手机就会嗡嗡响。代价是多了些误报，可比起真出事时的鸡飞狗跳，这点烦人实在算不了什么。下次再有人跟我说“这只是个中危”，我就让他看看那天晚上的监控截图。