企业官网建设流程全解析

VulnHunter 是一款开源的Agentic AI 安全扫描工具，它的杀手锏是内置的证伪引擎（Falsification Engine）——一套专门用来"自证其伪"的推理流程，能在最终报告生成前自动淘汰掉约 50% 的误报漏洞，只把真正可被攻击者利用的缺陷交付给你。

什么是误报？为什么传统扫描器总是"狼来了" 🔍

用过传统SAST（静态应用安全测试）扫描器的朋友多半有这种体验：跑一遍扫描，动辄几百条告警，人工复核后却发现大量是"虚惊一场"。

根源在于，大多数扫描器采用sink-first（汇点优先）的思路：先满仓库搜危险函数（比如eval()、exec()、原生 SQL），再回头"猜测"有没有攻击者能喂数据进来。这种"先看到危险、再脑补攻击路径"的做法，天然会产生大量误报。

VulnHunter 把方向整个反转，改用attacker-first（攻击者优先）的前向分析：

• 从攻击者真正能接触到的入口（API、网络消息、文件上传）出发
• 顺着数据向前追踪到危险汇点
• 只有能证明"攻击者真的能得手"的，才算漏洞

证伪引擎全景：一条候选漏洞要闯过几道关 🎯

VulnHunter 的核心扫描命令是/vulnhunt，它把整个审计拆成一条流水线，而证伪引擎正是其中的 Phase 2b（Adversarial Verification，对抗式验证）这一环。官方在 vulnhunt/README.md 里把各阶段列得很清楚：

关键数字就藏在 phase2b_verify.md 里：

Historically, ~50% of candidate findings are false positives.

翻译过来就是：历史经验上，约一半的候选发现其实是误报。证伪引擎存在的意义，就是不让这"一半"混进你的报告，更不让你拿着一堆假告警去"丢人"。

5 道硬门禁：每个候选漏洞的"安检"清单 🛡️

在 Phase 2b 动手"证伪"之前，每个候选漏洞还要先闯过 5 道硬门禁（Hard Gates），定义在 phase2_shared.md。任何一道不通过，直接出局：

💡 这些门禁的共同原则是：不靠"想当然"，只靠能在file:line指出的证据。官方甚至明确禁止拿"前面可能有个 WAF"这类基础设施猜测去降级发现。

对抗式验证的 9 个检查点：专挑自己的毛病 ⚖️

Phase 2b 的精髓，是站在被告席的对面，替"这不是漏洞"这一方辩护。phase2b_verify.md 要求对每个候选逐一过 9 个检查点，挑几个最"反直觉"的：

1. 跨子图可见性规则— 追踪代理只在各自分区里看代码，可能漏掉别的模块里的公共中间件/防御。验证阶段必须全仓重搜，因为这些防御对原始代理是不可见的。
2. 注释怀疑（Comment Skepticism）— 代码里的注释、命名、文档都不算证据。"by design""downstream validates"这类措辞，一旦被当作门禁依据，就要用可执行代码重新实证。
3. 降级纪律（Downgrade Discipline）— 一个漏洞函数有 5 个调用点，你只查了 1 个发现它是安全的？不行。只有验证了全部调用点都不可利用，才能降级或消除。
4. 多写入者属性规则— 想把某个值说成"服务器可控"？先 grep 出它所有的写入路径，只有当 N 个写入者全是服务器可控时，这个说法才成立。

这些规则的落点非常具体：每一条FALSE POSITIVE（误报）判定都必须引用具体的file:line。

⚠️ 官方原话很直白：含糊的"No — transaction log"不够格；"txnLog由 coordinator 在 engine.go:441 写入，且没有用户可达的写路径"才算数。指不出具体代码位置，发现就不算被消除。

从"代码模式"到"攻击者真的得手"：PoC 与利用测试 ✅

闯过证伪引擎的候选，还会进入 Phase 3 再被"拷问"一次。这里的逻辑是：静态推理可能是错的——框架拦截器、类型强制、运行时守卫都可能挡住攻击。

所以 phase3_reproduce_test.md 要求为每个确认的漏洞写一个可执行的利用测试（exploit test），断言的是攻击者的最终目标是否达成，而不是"危险代码模式存在"：

• SQL 注入 → 断言真的拿到了未授权的数据
• 命令注入 → 断言攻击者的命令真的执行了
• 路径穿越 → 断言目录外的文件真的被读到了
• IDOR → 断言能访问别人的资源

官方把"误分类为 Code Smell"称为漏报的头号原因——所以降级前，你必须先真的把 PoC 和利用测试写出来，构造过程本身往往会揭示抽象推理漏掉的影响。

如何在项目中启动 VulnHunter 证伪扫描 🚀

VulnHunter 以Claude Code Skill形式发布（纯 prompt 驱动，无需安装 Python 包）。前置要求：已安装 Claude Code，并具备Claude Opus模型的访问权限。

1. 克隆仓库并安装

git clone https://gitcode.com/gh_mirrors/vu/VulnHunter cd VulnHunter ./install.sh # 把 vulnhunt、vulnhunt-fix-verify、vulnhunter-fix 三个技能装入 ~/.claude/skills/

2. 启动扫描

claude --model opus \ --add-dir ~/.claude/skills/vulnhunt \ --add-dir ~/.claude/skills/vulnhunt/phases

进入会话后输入/vulnhunt即可。扫描产物会写到一个*_VULNHUNT_RESULTS_*目录（含报告、可执行 PoC、利用测试），而且VulnHunter 从不修改你的目标代码——修复策略只会被记录，不会被自动打上。

🔧 想在 CI / 批量场景跑？vulnhunter-agent/提供无头运行时，harness/支持跨多个仓库的批量扫描与精度基准测试。

关键文件路径速查表 📁

写在最后

VulnHunter 的证伪引擎，本质上是把安全审计里最贵的部分——"这到底是真漏洞，还是狼来了"——变成了一套可执行、可引用、可复核的推理流程：先用 attacker-first 的前向分析锁定真实攻击路径，再用对抗式验证专挑自己论点的毛病，最后用可执行的利用测试逼出"攻击者真的得手"的铁证。

对新手来说，最直接的收益是：你收到的每一条告警，都带着file:line级别的证据和一段可复现的利用路径，而不是一堆需要你自己去甄别真伪的裸告警。