Nexus：结构上无法产生幻觉漏报的离线AI渗透测试工具

如果你把任何一个 LLM 对准一个目标，然后让它"写一份安全报告"，它会信心满满地编造出根本不存在的漏洞：一个虚构的 TLS 弱点、一个"可能存在"的 SQL 注入、一场从未发生的密钥泄露。对于安全工具来说，幻觉出的发现就是最糟糕的输出——你不可能把一份基于虚构内容写成的报告交给客户。

这还有第二个问题，而且对很多实际工作来说是硬性障碍：客户的数据不能传到别人的云上。NDA、空气隔离环境、受监管的数据，或者单纯的不信任。"用 ChatGPT 就行了"不是一个选项。

我构建了 Nexus，一个同时解决这两个问题的自主红蓝对抗 agent。以下是它的工作原理。

理念：证据门

LLM 在某些事情上很擅长，在其他事情上却很糟糕，所以把两个职责分开：

模型负责尝试——它决定要测试什么并发送攻击载荷。这正是 LLM 擅长的领域。

确定性代码负责撰写报告（findings.py），一个发现只有在其响应被活靶子证实后才算数：XSS 标记返回时未被转义；../../etc/passwd 返回的内容包含 root:x:；引号触发了 SQL 错误；服务器在 ' OR 1=1-- 的请求下交出了令牌。

最终报告中的每一项发现都不是模型生成的文案，而是从对话记录中读取的——实际的响应字节——而不是模型"写出"的内容。幻觉出一个发现并非被禁止，而是结构上不可能。

$ nexus --target demo.testfire.net --authorized --rules-accepted
  -> /search.jsp?query=<script>alert(1)</script>
     [+] reflected UNESCAPED — XSS confirmed
  -> /index.jsp?content=../../../../etc/passwd
     [-] no root:x: in response — not confirmed, dropped
[gate]  writing report from EVIDENCE, not from prose
  [x] "weak TLS 1.0 cipher"    no evidence · DROPPED
  [+] HIGH    Reflected XSS
[done]  findings: 2 · hallucinated: 0

模型怀疑存在路径穿越和弱 TLS——但证据门把所有目标未证实的内容都丢弃了。

离线模式：纯 stdlib 核心，数据留在本地

核心是纯 Python 标准库，零依赖，可以运行在空气隔离的机器上。"大脑"是可插拔的：云端模型（如果允许的话）、本地 Ollama 模型，或者一个可以完全离线运行的小型微调模型。关键点在于：对于云端不可用的机密工作，你仍然能拥有一个可用的 AI 渗透测试工具，且客户的数据永远不会离开这台机器。

小型离线模型不就是个玩具吗？

通用的 1.5B 模型在真实评估中几乎无用：在一个留出基准测试上，它只会抓住两个被动发现，不会利用任何漏洞——35%。我在同一个 1.5B 上做了微调（基于教师蒸馏轨迹，用同一个证据门评分——在那里你无法伪造一个发现）：留出测试 95%、在一个从未见过的分布外目标上 71%、零误报。一个离线大脑真正在做工作而不是在模仿它。这些数字是可复现的（lab/ood_eval.py）。

不是扫描器导出——而是客户可用的报告

CVSS 3.1 评分（从公式计算而非猜测）、攻击链、CWE/OWASP/PCI 映射、包含具体修复方案的补救计划、多次运行之间的复测差异，以及一个可以就发现结果提问的副驾驶——它只从已证实的内容作答（问一个不存在的 XSS 它会说"无证据"而不是编造一个）。红队（审计）和蓝队（防守自己的主机）属于同一套方法论。

仅限授权范围，事先声明

范围是代码中的白名单，每次请求和每次重定向都会检查（SSRF 防护）。外部目标需要二次确认。无破坏性或 DoS 行为。这是一款用于你自己基础设施的工具，适用于有书面授权的渗透测试项目。

早期发布，源码可用（BUSL-1.1）

pip install nexus-sec

代码：https://github.com/alerta200/alerta

我最感兴趣的是证据门控方法本身在哪里会失效。显而易见的权衡是假阴性——一个如此严格的检测器会漏掉真正的漏洞。如果你遇到了这种情况，请发给我。