2021年，软件Log4j2 被曝出一个远程代码执行漏洞，漏洞攻击者只需构造一段特殊字符串，检测就能在目标服务器上执行任意命令。软件这个漏洞的漏洞根源，其实只是检测日志组件里一个看似无害的 JNDI 查询功能。代码写的软件时候没人觉得有问题，直到有人把它用在了不该用的漏洞地方。漏洞检测要做的检测，就是软件在类似的事情失控之前，把它找出来。漏洞

静态分析是检测最早被大规模使用的检测手段。它不运行代码，软件只靠解析源码或字节码，漏洞寻找危险模式。检测比如 Java 里调用 Runtime.exec() 时参数是否来自用户输入，C 语言里 strcpy 的目标缓冲区大小是否可控。工具会把这些位置标记出来，交给人工判断。好处是快，能覆盖所有分支。坏处也明显——误报率高。我见过一个项目，静态扫描报了 300 多个“命令注入”，排查后发现 280 个是硬编码常量，根本不可达。开发人员后来直接把整个规则集关掉了。

动态分析是另一条路。它让程序跑起来，给特定输入，看输出或内存状态是否异常。模糊测试（fuzzing）是典型代表。AFL 这类工具会不断变异输入文件，喂给目标程序，监控是否崩溃。2016 年，Google 的 OSS-Fuzz 用这招在 OpenSSL 里挖出过多个 CVE。动态分析的误报低，因为崩溃就是崩溃，没什么可争辩的。但覆盖率是硬伤——没执行到的代码，永远测不出问题。而且构造能触发深层逻辑的输入，有时候比写代码还难。

两种方法经常被放在一起用。先静态扫一遍，圈出可疑点；再针对这些点写动态测试用例。听起来合理，实际落地时，团队往往卡在“谁来修”和“什么时候修”上。安全团队扫出漏洞，开发团队说排期满了。拖三个月，漏洞还在。我见过一个金融公司，扫描报告里有个高危的 SQL 注入，从发现到修复用了 11 个月。期间系统一直在线。

工具本身也在进化。CodeQL 把代码转换成数据库，用查询语言找漏洞。Semgrep 支持自定义规则，语法接近源码本身，写规则的门槛低了很多。这些工具的共同点是：把检测逻辑从“匹配字符串”推向“理解数据流”。比如追踪一个 HTTP 参数从进入 Controller 到拼进 SQL 语句的完整路径。路径通了，漏洞才成立。这比单纯看有没有拼接字符串要准得多。

但工具再强，也绕不开一个事实：漏洞的定义在变。五年前，反序列化漏洞没多少人关注。现在 Java 生态里，几乎每个框架都在这上面栽过跟头。检测规则得跟着更新，安全团队得持续学习。我认识一个做 DevSecOps 的工程师，他每周花半天时间看新披露的 CVE，然后回头检查公司内部规则库有没有覆盖。这活儿很枯燥，但漏掉一个，可能就是下一次 Log4j。

还有个容易被忽略的点：依赖项。现代软件项目里，自己写的代码可能只占 20%，剩下 80% 是第三方库。Log4j2 漏洞爆发时，很多团队根本不知道自己用了这个库——它是被另一个框架间接引入的。软件物料清单（SBOM）现在被反复提起，就是因为这个。生成 SBOM 不难，难的是持续监控其中组件的漏洞状态。一个项目引入 200 个依赖，每个依赖又有自己的依赖，树状展开后上千个节点。哪个节点出了新 CVE，得能立刻定位到受影响的业务系统。

漏洞检测没有银弹。静态加动态加依赖扫描，三管齐下，仍然会漏。真正能降低风险的，是把检测嵌入日常流程——提交代码时自动跑规则，合并请求里标注新增风险，构建镜像时检查基础层漏洞。让安全变成开发的一部分，而不是最后一道关卡。否则，检测报告永远只是一份没人看的 PDF。