网络安全漏洞自评报告

上周三凌晨两点，网络我盯着扫描器吐出的安全报告，一个高危漏洞赫然在列——某台对外服务器上跑着三年前版本的漏洞Struts2。那一刻后背发凉，自评因为这玩意儿早在2017年就被爆出远程代码执行，报告补丁也发了快五年。网络可它还在那儿，安全像个没锁的漏洞后门，谁都能推一把试试。自评

这不是报告个例。我翻了过去半年经手的网络十二份渗透测试记录，有七份的安全初始入口都是"已知漏洞未修补"。什么叫已知？漏洞就是厂商发了公告、安全社区写了分析、自评甚至脚本小子都能在GitHub上找到利用工具。报告可偏偏有人不当回事。问起来就是"业务太忙""测试环境不影响生产"，等真被拖库了才拍大腿。

漏洞自评这件事，最怕两种极端。一种是过度自信，觉得自家系统没价值，黑客看不上。去年有家做本地生活服务的小公司，数据库里存着二十万用户的手机号和地址，老板跟我说"我们体量小，没人盯"。结果呢？攻击者用Shodan扫到他们暴露的Elasticsearch端口，没设密码，直接打包下载。数据在黑市上卖了三千块。三千块，连一次应急响应的工时费都不够。

另一种是恐慌性自评。看到CVE数量就头皮发麻，恨不得把所有服务都下线。我见过一个团队，为了修一个需要物理接触才能利用的漏洞，把整个内网文件共享停了三天，业务部门差点掀桌子。漏洞评分要看上下文——CVSS 9.8的漏洞如果只在内网、需要认证、且网络分段做得扎实，实际风险可能远低于一个暴露在公网的CVSS 5.0。

说说我自己的自评流程。拿到资产清单先不急着扫，花半小时跟运维聊：哪些是核心业务？哪些对外？最近有没有变更？有次运维提到"上周刚把测试库连到生产网络"，我立刻把那条链路标红。后来果然在那里发现未授权访问。工具扫出来的东西是死的，人的信息是活的。Nessus、OpenVAS这些当然要用，但别让它们替你思考。

优先级怎么排？我的土办法是问三个问题：能不能直接触达？需不需要认证？利用后能拿到什么？三个都往坏的方向走，今晚就得加班。有一个能缓解，可以排进下周。去年有个Log4j2的漏洞，内部CRM系统用了，但那个系统只在内网、访问要VPN加双因素、且日志里没发现异常外连。我把它标成中危，先修了对外网关的那个。后来证明判断没错——攻击者确实试了，但卡在认证那步。

修复环节最容易掉链子。开发说"升级会影响兼容性"，运维说"重启窗口只有凌晨四点"，安全说"必须今天修完"。三方拉锯，最后往往是不了了之。我的做法是提前准备回滚方案，把升级包和旧版本都打包好。有次修一个Spring框架的漏洞，开发死活不肯动，我直接在他测试环境跑了一遍，业务功能正常，性能还涨了3%。数据甩脸上，比吵一小时管用。

最后说个扎心的观察。很多团队的自评报告写得漂漂亮亮，风险矩阵、热力图、整改计划一应俱全。但你去问一线工程师"那个高危漏洞修了吗"，他一脸茫然。报告是给领导看的，漏洞是给黑客留的。这两件事得对齐。我现在的习惯是，每份报告末尾附一个"未修复漏洞跟踪表"，谁负责、截止日期、当前状态，每周更新。丑是丑了点，但管用。

漏洞不会自己消失。你不管它，它就管你——通常是在你最不想被打扰的时候。