一个会先推翻自己的安全工具：VulnHunter 的证伪引擎

上个月 Capital One 开源 VulnHunter 的时候我收藏了一下，没细看。这几天给内部项目补一轮安全自查，才把它翻出来认真拆了一遍。这篇只讲一个点——它那个「报漏洞之前先自己反驳一遍」的设计。这是整个仓库里最让我觉得值得记下来的东西。

先说传统 SAST 为什么惹人烦。大多数静态扫描是维护一份危险函数清单——SQL 拼接、反序列化入口、eval——拿这份清单去扫代码，命中就报。问题在于它找到的是「代码里存在危险模式」，不是「攻击者真的能走到这里」。一个危险函数如果根本不可达，报出来只会让开发者翻个白眼顺手标掉，标多了，真问题也懒得看。误报消耗的是信任，这个成本比漏报还难补。

VulnHunter 相反。它先列攻击者能从哪进来——API 端点、网络消息、文件上传——然后从这些入口往前推，看输入能不能一路流到某个危险操作。不是从危险模式往回找，是从入口做前向的数据流分析。这一步想明白了之后，我才理解它跟传统工具的差别不是检测能力，是回答的问题不一样：一个在猜「哪里危险」，一个在算「攻击者能不能真到那里」。

但真正让我记下来的不是这个方向转变，是它在这之上的那层自我怀疑。它在报一个漏洞之前，会沿着路径再走一遍，专门找有没有过滤、校验、类型转换把输入半路掰回去——如果找到了，这个发现就不上报。等于它怀疑自己一次，确认这条路真的走得通，才把结果拿给你看。

这个设计我特别吃。因为我见过太多 AI 安全工具的输出是「这个函数存在 SQL 注入风险」，你顺手查一眼，发现那个函数服务的是内部健康检查接口，根本没有外部输入。一次两次之后，你会对工具的所有输出都打个折扣。VulnHunter 选了另一条路：降低报告数量，把每条报告的证据链、完整利用路径、修复建议一起拉出来，让报告本身就是一份可以直接进修改流程的工单。这个取舍，从工程效率上讲我觉得是对的。

不过门槛也比较现实：想跑起来，得有 Claude Opus 4.8 的模型访问权限和可用的 Claude Code 环境。它不是一个独立的扫描器，是挂在 Claude 生态上的 Agent 应用。我手头没有权限，所以这篇只能写到读代码这一步，没法硬说「我本地跑通了」——留一个坑，等以后有条件了再补上实测的部分。

但就算只读代码，这个仓库也值得翻。它公开了「怎么让 AI 安全工具可信」这件事的一种解法：攻击者视角加上证伪引擎，外加输出证据链而不是裸结论。去掉证伪引擎，前向分析照样会报一堆被中间层拦掉的路径；去掉证据链，开发者还是得自己在代码库里走一遍路径，那跟传统工具报个名字让你自己查也没什么区别。

💡 小技巧：这种「先反驳自己一遍再下结论」的思路，不一定非要用在安全工具上。下次你拿到 AI 生成的一段代码改动，可以先让它顺着你给的输入走一遍，看看有没有哪一步会把它的结论推翻——和给代码写测试是一个道理，只是把验证挪到了提交之前。

这篇记下来了。下次自己项目里要做攻击面分析，应该能直接借鉴「入口→路径→证伪」这套思路。你可以挑一个自己的服务，从 API 入口顺着数据流走一遍，不用工具，看看能不能画出一条攻击者真正走得通的路径——画不出来，说明这个练习本身就很值。