去年秋天，安全我帮一个做跨境电商的扫描朋友看服务器。他跟我说网站总被挂马，工具每次清理完过两天又中招。安全我登上机器扫了一眼——好家伙，扫描web目录里藏了十几个webshell，工具文件名伪装成正常的安全图片。他说之前用过某款"安全扫描工具"，扫描扫完报告显示"未发现威胁"。工具我问他扫的安全哪个目录，他说扫的扫描`/var/www/html`。问题在于，工具他的安全网站实际跑在`/home/site/wwwroot`下面，扫描器压根没碰到真正有问题的扫描文件。

这事让我重新审视一个老话题：安全扫描工具到底在扫什么？工具很多人以为装个扫描器就等于上了保险，其实差得远。扫描工具本质上是把已知的漏洞特征、恶意代码模式、配置缺陷规则做成一个库，然后拿着这个库去跟目标系统做匹配。匹配上了就报警，匹配不上就沉默。它的能力边界，完全取决于规则库覆盖了哪些东西，以及你告诉它去扫哪里。

常见的扫描工具大致分几类。端口扫描类的，比如Nmap，干的事是探测目标开了哪些端口、跑了什么服务。这类工具本身不判断"有没有漏洞"，它只是给你一张地图。漏洞扫描类的，像Nessus、OpenVAS，会拿着CVE库去比对服务版本，告诉你"这个版本的OpenSSL存在Heartbleed漏洞"。Web应用扫描类的，AWVS、Burp Suite这些，专门针对HTTP层面，检测SQL注入、XSS、文件包含之类的Web漏洞。还有代码审计类的，比如Semgrep、Fortify，直接读源码找问题。

分类清楚之后就能看出来，没有哪一款工具能覆盖所有场景。你拿Nmap去扫Web漏洞，扫不出来；拿Burp去扫服务器端口，也不是它的活。我见过不少团队买了一套工具就觉得安全建设到位了，结果连资产清单都没整理清楚——扫描器扫的是哪些IP、哪些域名、哪些路径，一问三不知。

说个具体的。某次我用AWVS扫一个客户的管理后台，报告里SQL注入、XSS列了一长串。客户技术负责人看完很紧张，我让他先别急，挨个手动验证。结果大部分是误报——AWVS发现某个参数回显了特殊字符，就判定可能存在XSS，但实际上那个参数在服务端做了严格过滤，只是回显在HTML里没转义而已，攻击者利用不了。误报这事在扫描工具里太常见了，尤其是Web扫描器，规则写得宽一点就误报多，写得严一点就漏报。你永远在误报和漏报之间找平衡。

漏报更麻烦，因为你看不见。前年有个供应链攻击事件，攻击者在npm包里面藏了恶意代码，很多团队用SCA工具（软件成分分析）扫了，没报。为什么？因为那个恶意代码是运行时动态加载的，静态扫描根本看不到。攻击者太清楚扫描工具的工作方式了。

所以我的看法是：扫描工具该用，但别把它当答案。它更像一个体检仪器，能查出一些指标异常，但查不出所有病。真正管用的做法是——先把自己的资产摸清楚，知道有哪些域名、哪些IP、哪些服务、哪些代码仓库；然后根据场景选合适的工具组合，端口扫描加漏洞扫描加Web扫描加代码审计，各管一摊；扫出来的结果必须人工验证，别直接丢给开发去修，误报会把人逼疯；最后，扫描频率要跟上变化，新上线的服务、新引入的依赖，都得纳入扫描范围。

回到开头那个朋友的案例。后来我帮他做了几件事：把网站真实路径加进扫描配置，换了一款支持自定义路径的Web扫描器，又加了一条定时任务每天凌晨扫一次。上个月他跟我说，已经两个月没被挂马了。工具还是那些工具，区别在于用的人知不知道它到底在干什么。