代码审计工具

SonarQube 的代码扫描报告里躺着 47 个“严重”漏洞，团队花了两周修完，审计线上还是工具被 SQL 注入打穿了。问题出在工具只检查了字符串拼接的代码写法，没管 MyBatis 的审计 ${ } 占位符——那是 XML 文件里的东西，静态分析引擎压根没读。工具这种事我见过太多次了。代码代码审计工具不是审计万能药，它更像一把筛子，工具孔径选错了，代码沙子照样漏过去。审计

市面上主流的工具工具分两类。一类是代码 SAST，静态应用安全测试，审计Checkmarx、工具Fortify、Semgrep 都算。它们不跑代码，直接解析源码或字节码，把数据流从 source 追到 sink。听起来很靠谱，实际用起来误报率高得吓人。我试过用 Fortify 扫一个 Spring Boot 项目，三千行代码报了 200 多个问题，其中一半是“可能存在的路径穿越”——因为工具看到 new File(userInput) 就报警，根本不判断 userInput 有没有经过白名单校验。另一类是 DAST，像 Burp Suite、OWASP ZAP，它们对着运行中的服务发请求，看响应里有没有异常。好处是误报少，坏处是覆盖率低，一个需要特定权限才能触发的接口，爬虫根本爬不到。

真正让我觉得有意思的是 Semgrep。它不追求全量数据流分析，而是让你写模式匹配规则。比如你想找所有把用户输入直接拼进 SQL 的地方，写一条 execute("..." + $X) 就行。规则简单，跑得快，误报可控。我拿它扫过一个老旧的 Struts2 项目，十分钟内定位到三个 Runtime.getRuntime().exec() 调用，参数直接来自 HTTP 请求。这种场景下，Semgrep 比那些商业工具好用得多——它不试图理解整个程序，只找你告诉它要找的东西。

工具的选择取决于你信不过谁。信不过开发者的手写代码，就用 SAST 卡在 CI 里；信不过框架的配置，就用 DAST 定期扫；信不过第三方库，就用 SCA 工具查 CVE。但别指望一个工具解决所有问题。我见过一个团队把 SonarQube 的质量门禁设成“零严重漏洞”，结果开发者直接把 // NOSONAR 加在每一行报警代码后面。工具是死的，绕过它的办法多得是。

还有个容易被忽略的点：审计工具本身也会出错。去年 Log4j 漏洞爆发时，很多 SAST 工具根本识别不出 ${ jndi:ldap://...} 这种攻击模式，因为它们的规则库还没更新。等厂商推送新规则，已经过去三天了。那三天里，攻击者早就扫完一轮。所以别把工具当护城河，它顶多是个预警雷达。真正管用的，还是人对着代码一行行读——读不懂的地方，工具也帮不了你。

最后说个反直觉的观察。我见过最有效的“审计工具”，是一个团队自己写的 grep 脚本。他们把所有危险函数列出来，比如 eval、exec、deserialize，然后每天定时跑一遍，把新增的调用发到群里。没有数据流分析，没有抽象语法树，就是最笨的文本搜索。但就是这套东西，帮他们在半年内拦住了四次反序列化漏洞的引入。工具不需要多聪明，能持续用、能让人看懂，比什么都强。

很赞哦!（654）