去年某电商平台被曝出用户数据泄露，软件源头是代码一个没做输入校验的查询接口。攻击者构造了一个畸形参数，安全直接把数据库里的漏洞订单信息拖走了。事后复盘，检测开发团队承认：这个漏洞如果在上线前用静态分析工具扫一遍，修复十分钟就能发现。工具问题在于，软件他们根本没跑过任何检测工具。代码
这事说明一个很朴素的安全道理——代码安全不能靠人眼盯。人总会犯错，漏洞尤其是检测在赶工期的时候。安全漏洞检测工具的修复价值，就是工具充当那个不知疲倦的审查员，在代码提交、软件构建、部署的每个环节帮你兜底。
静态检测：不运行代码也能找问题
静态应用安全测试（SAST）工具直接分析源代码或字节码，不需要把程序跑起来。它的原理说穿了也不复杂：把代码解析成抽象语法树，然后拿预定义的规则去匹配危险模式。比如检测到executeQuery("SELECT * FROM users WHERE id=" + userId)这种拼接字符串的写法，工具立刻标记为SQL注入风险。
Checkmarx、Fortify、Semgrep都属这类。Semgrep我用得比较多，规则写起来像在写代码搜索表达式，团队自己就能扩展。静态检测的短板也明显——误报率高。一个参数经过三层函数传递后最终拼进了SQL，工具可能追踪不到完整链路，要么漏报要么误报。所以实际使用时，规则调优比工具选型更花时间。
动态检测：跑起来才知道会出什么事
动态应用安全测试（DAST）走的是另一条路。它不关心代码怎么写的，只往运行中的Web应用发请求，看响应里有没有异常。SQL注入、XSS、命令注入这些漏洞，DAST通过构造恶意payload来验证。Burp Suite和OWASP ZAP是常见选择，ZAP还免费。
我见过一个案例：某API接口在静态扫描里干干净净，因为参数经过了严格的类型转换。但DAST发现，把Content-Type改成application/xml后，后端解析器居然开启了外部实体加载，直接导致XXE漏洞。这种问题静态工具很难覆盖，因为漏洞不在业务代码里，而在框架配置层。
修复不是改完就完了
检测出漏洞只是第一步。修复环节最容易出乱子——开发改了代码，测试没覆盖到，漏洞换个形式又回来了。更麻烦的是，有些修复方案本身引入新问题。比如为了防止XSS把用户输入全部HTML实体编码，结果前端展示时又用innerHTML还原，等于白做。
我的做法是：每个漏洞修复必须附带一个自动化测试用例。这个用例在修复前能复现漏洞，修复后能通过。这样既验证了修复效果，也防止后续代码变更重新引入问题。工具层面，SonarQube的Quality Gate可以卡住构建，漏洞没修完就不让合并。
工具组合比单点工具更实际
没有哪个工具能覆盖所有场景。SAST擅长找代码层面的注入和逻辑缺陷，DAST能发现运行时配置和部署问题，SCA（软件成分分析）负责第三方依赖的已知CVE。三个一起上，覆盖率才够看。
具体怎么配？我的建议：IDE里装个Semgrep或SonarLint做实时提示，提交时CI流水线跑SAST全量扫描，部署到测试环境后跑DAST，SCA每周跑一次依赖检查。工具之间肯定有重叠和冲突，容忍它。安全本来就是在成本和风险之间找平衡，不是追求零漏洞的完美主义。
最后说个数据：根据Veracode的年度报告，超过70%的应用程序在首次扫描时至少有一个高危漏洞。这个比例说明什么？说明大部分团队根本没在做持续检测。工具就在那里，开源免费的也不少，用不用才是分水岭。