漏洞整改通知书

昨天凌晨两点，漏洞某银行核心系统被扫出一个高危漏洞。整改对方利用的通知是Apache Log4j2的一个老漏洞，补丁打了三次，漏洞但开发组漏了一台测试服务器。整改就这一台机器，通知让整个内网门户洞开。漏洞安全团队连夜封IP、整改清日志、通知改防火墙规则，漏洞忙到天亮才发现，整改漏洞扫描报告三个月前就躺在邮箱里，通知标题写着“紧急”，漏洞收件人里躺着七个名字，整改没一个人点开过。通知

这种事儿不新鲜。我见过太多漏洞整改通知，写得像年终总结，开头是“根据集团要求”，中间是“请各单位高度重视”，结尾是“务必于X月X日前完成”。读的人扫一眼就扔进文件夹，该干嘛干嘛。你问他整改了吗？他说改了。你问他改了什么？他愣半天，说“我把密码换了”。

漏洞整改不是换密码，也不是打补丁。它是一次对系统架构的重新审视，是对运维流程的彻底复盘。我经手过一家电商公司，双十一前被扫出SQL注入漏洞。技术总监拍胸脯说“框架自带参数化查询，没问题”。结果呢？安全团队用sqlmap一跑，三分钟就拖出了用户表。问题出在哪儿？出在一个老程序员图省事，在某个报表模块里写了原生SQL拼接。他觉得自己写代码十年没出过事，就把框架的防护机制绕过去了。

整改通知发下去，得让收到的人明白三件事：第一，这个漏洞具体是什么，影响哪些系统，攻击路径是什么；第二，为什么会出现这个漏洞，是编码习惯问题，还是流程缺失问题，还是安全意识问题；第三，怎么修，修完之后怎么验证，怎么防止类似问题再出现。光写“请立即修复”没用，得像医生开处方一样，写清楚药名、剂量、服用方法。

有个制造业客户的做法值得借鉴。他们的整改通知书分三栏：左栏是漏洞描述，中栏是根因分析，右栏是整改措施和验证方法。每份通知后面附一张时间表，明确到小时。整改完成后，安全团队会做二次扫描，不是扫一遍就完，而是模拟攻击路径重新打一遍。打不进去，才算真改完了。

最怕那种“纸面整改”。某政府单位收到通知，反馈说“已修复”，结果安全工程师远程一测，漏洞还在。打电话过去问，对方说“我们改了配置文件啊”。再一问，改的是测试环境的配置，生产环境压根没动。这种事儿你说他是态度问题还是能力问题？我看是流程问题——整改通知里没写清楚“生产环境必须同步变更”，也没人跟进验证。

写整改通知的人，自己得先懂技术。别拿那种“请相关责任人加强安全意识”的套话来糊弄人。你写“加强安全意识”，对方回你“已加强”，这球就踢回去了。你得写“所有数据库查询必须使用预编译语句，代码评审时增加SQL注入检查项，上线前必须通过OWASP ZAP扫描”，对方才知道具体该干什么。

还有一点，整改通知要限时，但时限要合理。三天改完一个需要重构的系统，那是逼人造假。我见过最离谱的通知，要求一个涉及二十多个微服务的认证漏洞在48小时内修复完毕。开发团队直接回复“做不到”，然后双方扯皮了两周，漏洞就这么晾着。与其定个不切实际的截止日期，不如分阶段：第一周先阻断攻击路径，第二周完成代码修复，第三周全面回归测试。

最后说句实在话——通知写得好，不如制度建得好。漏洞是表象，管理才是根子。你通知写得再详细，如果团队没有安全编码规范、没有自动化扫描工具、没有定期的攻防演练，那下一份整改通知迟早还会来。而且大概率，还是同样的漏洞，换个马甲而已。