去年秋天，漏洞理一个做电商的何处朋友半夜给我打电话，声音都在抖。漏洞理他负责的何处系统被扫出一个SQL注入，攻击者已经拖走了三万多条用户订单。漏洞理他问我第一句话是何处：“我现在是先修代码还是先报警？”我说你先别动服务器，把网线拔了，漏洞理然后截图留证。何处这不是漏洞理电影桥段，是何处真实发生的漏洞应急现场。
漏洞处理的漏洞理第一原则：先止血，再治病。何处很多人一发现漏洞就扑上去改代码，漏洞理结果把入侵痕迹覆盖了，何处攻击者留的漏洞理后门还在，改完照样被控。正确的顺序是隔离受影响系统、保留现场证据、评估影响范围。我见过一个运维，发现Webshell后直接删文件，结果日志里那条关键的反连IP没了，最后连谁干的都不知道。
止血之后要判断漏洞的性质。是远程代码执行还是信息泄露？是未授权访问还是越权操作？这决定了你有多长时间窗口。RCE级别的漏洞，从发现到被大规模利用可能就几个小时。去年Log4j那个洞，凌晨爆出来，早上六点就有扫描器在全网探测了。你要是等到上班再处理，服务器早就是别人的肉鸡了。
修复方案得看实际情况。官方补丁是最省事的，但有时候打补丁会破坏业务逻辑——我就遇到过升级组件后支付回调全挂了的案例。这时候要么做临时缓解，比如WAF加规则、限制访问来源；要么自己写热修复。临时方案必须记下来，别修完就忘了，三个月后没人记得WAF里那条规则是干嘛的，一不小心删掉，洞又开了。
验证环节最容易被跳过。改完代码，本地测一下，觉得没问题就上线了。但攻击者的利用方式往往和你想象的不一样。有个经典案例：开发修了SQL注入，把单引号转义了，但忘了数字型注入点不需要引号，结果漏洞依然存在。验证要模拟真实攻击，用burp、sqlmap这些工具跑一遍，别自己骗自己。
漏洞处理不只是技术活。你得写报告，说清楚漏洞怎么来的、影响了什么、怎么修的、后续怎么防。这份报告要给领导看，给合规看，也可能给客户看。我写报告有个习惯：把技术细节和业务影响分开写。技术部分给工程师看，业务部分让非技术的人也能看懂“这个洞会导致用户数据泄露”而不是“存在未过滤的输入点”。
最后说个反直觉的观点：不是所有漏洞都值得立刻修。有些漏洞在内网，利用条件苛刻，修复成本极高，这时候接受风险、做补偿性控制可能更合理。我见过一个团队为了修一个低危漏洞，把核心服务停机了四小时，业务损失远超漏洞本身。风险评估不是走过场，得算账。
漏洞处理没有标准答案，但有底线：别瞒。瞒着不报，等数据泄露了再解释，没人会原谅你。那个电商朋友最后选择了上报，虽然被罚了款，但至少用户信任还在。漏洞是修不完的，但处理漏洞的态度，决定了你能在这行走多远。