扫完那台对外服务的漏洞测试机，报告里蹦出37个漏洞。扫描高危9个，结果中危21个，报告剩下7个低危。漏洞运维老张看了一眼，扫描说“还行，结果比上次少”。报告我盯着屏幕没接话——高危里有4个是漏洞同一个组件反序列化，等于门锁坏了四把，扫描钥匙还都插在门上。结果

这活儿干久了会发现，报告漏洞数量本身说明不了什么。漏洞真正要命的扫描是分布。比如这次，结果Web层只有两个XSS，但后台管理接口暴露了未授权访问，直接能改用户余额。前端修得再漂亮，后门敞着，等于白干。我见过太多团队把精力砸在首页扫描上，结果API网关的鉴权绕过被晾了三个月。

报告里有一条我特意标了红：/api/v1/export 接口存在SQL注入，且数据库账号是 db_owner。这意味着什么？攻击者不需要提权，直接能拖走整个库。更麻烦的是，这个接口在Swagger文档里没写，是开发自己留的“调试后门”。扫描器能发现它，纯粹是因为路径字典里碰巧有 export 这个词。运气好，但运气不能当饭吃。

中危那21个里，有11个是依赖库版本过旧。Log4j 2.14、Fastjson 1.2.68、Spring Boot 2.3.1——全是三年前的东西。开发说“业务跑着没问题就不动”。我理解这种心态，升级依赖确实容易踩坑。但漏洞扫描不是找茬，是告诉你：别人已经拿着这些CVE在批量扫全网了。你不修，下一个中招的就是你。

低危那7个更有意思。三个是目录列表开启，两个是HTTP方法未限制，还有两个是错误页面泄露了堆栈信息。单独看都不致命，可组合起来就是一条完整的攻击链：先通过目录列表找到备份文件，再从堆栈里拿到框架版本，最后用PUT方法上传webshell。安全圈管这叫“漏洞利用链”，扫描器只给低危，是因为它不会串起来看。

我习惯在报告最后附一段手工验证记录。这次试了试那个未授权接口，果然返回了200，还带着用户手机号和身份证号。没敢往下翻，直接截了前三条就关掉。这种事不能等保测评时才发现，那时候罚单已经开出来了。

修复建议写了三页。最前面三条是：一、把 /api/v1/export 下线或加IP白名单；二、Log4j升到2.17.1以上；三、后台接口统一走网关鉴权。后面那些XSS和目录列表，优先级往后排。资源有限的时候，先堵能直接进数据库的口子。

老张后来问我，为什么高危里有两个“信息泄露”被他标成了紧急。我说你去看详情——泄露的是数据库连接字符串，明文。这玩意儿比SQL注入还直接，连利用都省了。他沉默了一会儿，说“那今晚得加班了”。对，漏洞扫描报告不是拿来存档的，是拿来排期的。排期不执行，报告就是废纸。

最后说个观察：很多团队扫完漏洞，第一反应是“误报”。我承认扫描器有误报，但这次37个里，手工验证后只有2个是误报——一个是版本号识别错误，一个是需要特定配置才触发。剩下35个，全是真的。别急着关报告，先挑三个高危修掉，比争论误报率有意义得多。