漏洞扫描后续工作

扫描器跑完最后一个IP段，漏洞屏幕上弹出327条漏洞记录。扫描很多人到这一步就停了，后续导出PDF，工作发封邮件，漏洞任务标记为“已完成”。扫描三个月后同样的后续漏洞再次出现在报告里，连端口号都没变。工作问题不在扫描工具，漏洞在扫完之后那几天的扫描动作。

我见过一家做电商的后续团队，用某商业扫描器查出Struts2远程命令执行。工作开发负责人看了一眼说“版本对不上，漏洞误报”，扫描直接关掉工单。后续两周后服务器被挖矿程序占满CPU。事后复盘，那个“误报”的判断只花了十秒，代价是停机六小时。扫描器给出的漏洞描述里其实附了精确的版本范围，没人点开看。

验证是后续工作的第一道闸门。不是所有扫描结果都值得修，但“不值得修”必须建立在手动确认之上。我的习惯是：高危漏洞逐条复现，中危挑出对外暴露的服务验证，低危先记着。复现时用curl或者浏览器插件就够，没必要上重型渗透工具。有个小技巧——把扫描器的请求包复制到Burp里重放，改几个参数，误报往往在三十秒内现形。

确认漏洞真实存在后，排优先级比修漏洞本身更费脑子。CVSS评分是个参考，但不能全信。一个内网Redis未授权访问，CVSS可能给9.8，但如果那台机器只跑着测试数据、安全组只允许跳板机连接，实际风险远低于一个对外Web应用的文件上传漏洞。我通常画一张二维图：横轴是资产重要性，纵轴是漏洞利用难度。落在右上角的先修，左下角的排期到下个迭代。这张图不用工具，白板手画就行。

修复环节最容易脱节。安全团队说“升级到最新版”，运维团队说“这个版本和现有插件不兼容”。两边都没错，但漏洞还在。有效的做法是安全人员直接给出可执行的最小变更方案。比如Log4j2漏洞，不是笼统地说“升级”，而是明确：如果应用不能停机，先加JVM参数-Dlog4j2.formatMsgNoLookups=true；能停机就换jar包，并附上官方下载链接和校验值。把“做什么”变成“怎么做”，修复率至少翻一倍。

复测不是把扫描器再跑一遍。同一个工具、同一个策略，结果往往和上次一样——因为工具不知道你改了配置文件。复测要针对具体漏洞手工验证。SQL注入修了，就手工发那个payload看是否还被拼接；文件上传修了，就传一个带php后缀的图片试试。扫描器可以当辅助，但别让它当裁判。

最后一步经常被忽略：把这次漏洞的上下文写进知识库。不是写“修复了Struts2漏洞”，而是写清楚：哪个业务系统、什么框架版本、当时为什么没早发现、修复时踩了什么坑。下次扫描再报类似漏洞，值班的人能直接翻记录，不用从头查起。我见过一个团队把每次漏洞的复现步骤和修复命令做成内部Wiki词条，两年积累下来，新来的安全工程师上手速度比同行快得多。

扫描器是个起点，不是终点。那327条记录里，真正需要动手的可能不到三十条，但找出这三十条、推动它们闭环，才是后续工作的全部意义。工具不会替你判断，也不会替你沟通，更不会替你记住上次的教训。这些事只能人来做。