上周我帮一家电商公司做授权渗透测试，他们的安全负责人很得意地告诉我，他们用了三家排名靠前的漏洞扫描器，每季度跑一次。我问能不能给我看看最近的报告，他打开一份46页的PDF，上面密密麻麻都是高危。可当我问那个高危里有多少是你能接受的业务逻辑漏洞时，他沉默了。这种场景我遇到太多次了。
我做过大概60次黑盒测试和30次白盒审计，发现一个规律：黑盒扫出来的漏洞里，真正能被利用的大概只有15%，剩下的都是配置问题和版本指纹误报。白盒刚好相反，代码审计找到的10个漏洞里有7个能打出实弹效果，但代价是每个漏洞平均消耗我3.5个小时去确认调用链。有一次在某个Java项目里，我用Semgrep定位到一个SQL注入，但那个接口藏在消息队列的消费者里，如果只做黑盒，绝对不可能触发。
印象最深的是去年一个金融公司的项目，他们自认为很懂安全，用了Burp Suite Pro加某国产扫描器，但没做任何手动验证。我登录后台系统，发现一个下载接口有个ID参数，我把它改成"../config/application.yml"，直接拿到了数据库密码。这种路径穿越漏洞扫描器为什么不报？因为扫描器不会先把会话登录态加进去，或者说它扫的那个URL根本不在认证范围内。后来我用白盒看了他们的Spring权限配置，才发现放行规则里写了/**，等于所有接口都开放。
所以我想说的是，安全测试不该是跑完扫描器就交付报告。扫描器适合做资产发现和已知CVE排查，但真正的风险往往藏在业务逻辑和认证边界里。我的做法是先用黑盒把攻击面画出来，拿到所有API清单和参数类型，再针对性做白盒代码审计，最后用自己写的脚本去验证那两三条真正可疑的链路。这样看起来慢，实际上一周能发现的有效漏洞，比扫描器一年报的还多。顺便说一句，别把CVSS评分当圣旨，那是给合规看的，不是给攻击者看的。
