漏洞检查工具

去年秋天，漏洞一个朋友的检查公司被拖库了。攻击者没用什么零日漏洞，工具就是漏洞利用了一个三年前就公开的Struts2漏洞。他们的检查代码仓库里明明跑过扫描，报告显示"无高危问题"。工具后来一查，漏洞扫描工具版本太老，检查规则库半年没更新。工具这事让我意识到，漏洞漏洞检查工具最大的检查问题往往不在工具本身，而在用它的工具人。

市面上的漏洞扫描器大致分两类。SAST，检查静态应用安全测试，工具直接读源码，不运行程序。DAST，动态应用安全测试，把请求打过去看响应。前者像X光机，后者像安检门。各有各的盲区。SAST对反射调用、动态拼接SQL经常误报，DAST则很难覆盖需要登录态才能触发的逻辑漏洞。我见过一个团队只买了DAST，结果一个越权接口上线三个月没人发现——因为那个接口需要特定角色令牌，扫描器压根没爬到。

开源工具里，Semgrep这两年势头很猛。它的规则写起来像在写代码，一条YAML就能定义模式匹配。我试过用它扫一个Python项目，十分钟配好规则，抓出了两处硬编码密钥和一处不安全的反序列化。但Semgrep对二进制和混淆代码基本无能为力。另一款老牌工具SonarQube，代码质量检查做得更全，安全规则反而偏保守，很多中危漏洞它不报。有人嫌它吵，有人嫌它静，看你项目处在什么阶段。

商业工具贵有贵的道理。Checkmarx的污点分析引擎能跨文件追踪用户输入，从Controller一路跟到DAO层。我见过它在一个Spring项目里挖出一条完整调用链，把前端表单参数和最终拼接的SQL语句连了起来。但代价是扫描一次四十分钟，CI流水线根本等不起。很多团队的做法是：提交时跑轻量级Lint，合并前跑Semgrep，每周半夜跑一次全量Checkmarx。分层，看菜下饭。

工具报出来的漏洞，八成是误报。这不是工具烂，是安全本身就需要人判断。一个"SQL注入"告警，点进去看，参数经过了白名单校验，那它就是误报。但白名单是不是真的覆盖了所有危险字符？这得人看。我习惯把扫描结果按文件路径排序，同一个文件反复报同类型漏洞的，优先人工确认。经验是：连续三行代码里出现两次以上告警，基本是真问题。

漏报比误报可怕得多。误报浪费你十分钟，漏报可能让公司上新闻。减少漏报没有捷径，只能多工具交叉。SAST扫完，DAST再扫一遍；开源组件用SCA工具查CVE；容器镜像用Trivy扫系统包。每个工具覆盖不同层面，指望一个工具包打天下，等于只锁前门不关窗。

最后说个容易被忽略的点：扫描频率。很多团队把安全扫描挂在发布流程里，一个月跑一次。可代码是每天在变的。我现在的做法是，在Git的pre-commit钩子里挂一个极快的正则检查，专抓密码、密钥、内网IP。提交到远程后，CI里跑Semgrep和依赖检查。全量扫描放在每天凌晨两点，结果自动发到安全群。快慢结合，既不影响开发节奏，也不至于让漏洞活过夜。

工具终究是工具。它不会替你思考业务逻辑里的权限绕过，也看不懂你精心设计的加密方案有没有实现错误。但用好了，它能把那些低级的、重复的、肉眼容易漏掉的问题先筛一遍。剩下的，还得靠人盯着。