OpenAnt：LLM 驱动的漏洞发现利器

一款让安全研究"飞起来"的扫描工具

想象你是一个开源项目的维护者，每天收到几十个 Pull Request，代码在不断迭代，功能在快速叠加。突然有一天，安全研究员告诉你：你的项目存在一个严重漏洞，攻击者可以利用它窃取用户数据。你会怎么反应？

更让人头疼的是，大多数传统 SAST 工具（静态应用安全测试）会在这个阶段给你扔出成百上千条"漏洞警报"，其中大量是误报——它们把正常代码判定为危险，把风格问题标记为安全漏洞。安全团队花大量时间排查这些"狼来了"式的误报，真正的高危漏洞反而淹没在噪音里。

OpenAnt 就是为解决这个问题而生的。

背景故事：安全研究员与 AI 的碰撞

OpenAnt 来自 Knostic——一家专注于 AI Agent 安全防护的公司。Knostic 的核心产品是保护 AI 编程助手（如 Claude Code、GitHub Copilot）不被滥用，防止它们在用户的授权下做出破坏性操作（比如 rm -rf 删除整个代码库）。

既然 Knostic 每天都在和 AI Agent 打交道，自然会想到一个问题：能不能用 LLM 来做漏洞发现？ 传统的静态分析工具虽然快，但缺乏语义理解能力；动态测试（Fuzzing）虽然更准确，但需要大量基础设施支撑。那么，如果让 LLM 直接"读懂"代码语义，再配合自动化验证来排除误报呢？

这个想法催生了 OpenAnt，2026 年 3 月正式开源。

核心原理：两阶段"过筛子"机制

OpenAnt 的漏洞发现流程分为两个阶段、多个步骤，本质上是一个漏斗式的筛选机制：

Stage 1 — 检测（Detection）：将代码库分解为"分析单元"（Unit）。每个单元包含一段代码（如函数或模块），以及它的调用者、被调用者等上下文信息。LLM 在这个阶段会识别出潜在的漏洞候选。

Stage 2 — 攻击验证（Attack Verification）：这是 OpenAnt 区别于大多数工具的关键一步。很多工具会让 LLM 直接扮演攻击者："你能利用这个漏洞吗？" 但 Knostic 的研究者发现，这种方式几乎总是会失败——LLM 太"好说话"了，会为任何代码构造出听起来合理的攻击路径，哪怕那段代码其实是安全的。

OpenAnt 采用了对抗性约束模拟（Adversarial Constrained Simulation）：LLM 不能假设自己拥有服务器访问权限，不能假设自己有数据库凭据，不能假设能读取本地文件。每一步攻击都必须基于"正常攻击者实际拥有的能力"来构建。如果在这样的约束下，漏洞依然可以被利用——那才是真正的漏洞。

此外，OpenAnt 还可以通过动态测试（Dynamic Testing）进一步验证：在隔离的沙箱容器中，自动生成漏洞利用代码并执行，结果为真则确认为漏洞，结果为假则排除。

整个架构的核心设计哲学是：Stage 1 发现，Stage 2 攻击验证，能活下来的才是真正的漏洞。

技术架构：Go CLI + Python 引擎

OpenAnt 的技术栈设计很有意思——它采用 Go CLI 包裹 Python 引擎的双层架构：

• Go CLI（apps/openant-cli）：负责用户工作空间管理、项目配置、扫描进度持久化、进程生命周期管理。
• Python 引擎（libs/openant-core）：负责解析、增强、分析、报告生成等核心逻辑。

两者通过一个狭窄的 JSON 契约通信：Go 端通过 python -m openant scan ... 调用 Python 端，Python 端通过 stdout 输出一个 {status, data, errors} 的 JSON 信封，stderr 负责人类可读的流式日志。

这种设计让 Go 端负责所有"系统层"的事情（文件系统、配置、信号处理），Python 端专注"分析层"的事情（AST 解析、LLM 调用、报告生成），职责清晰。

支持的编程语言包括 Go、Python、JavaScript/TypeScript、C/C++、PHP、Ruby、Zig、Swift、Rust。其中 Go 和 Python 支持最成熟，其余为 Beta 阶段。

LLM 适配层：支持任意主流 LLM

OpenAnt 的 LLM 调用层设计为适配器模式，目前支持以下 LLM Provider：

• Anthropic：Claude 系列（参考实现），适合检测/验证阶段
• OpenAI：GPT-4o 等，适合上下文和报告生成
• Google：Gemini，适合动态测试和报告
• AWS Bedrock：通过 AWS 凭证链调用，无需 API Key
• OpenRouter：聚合多个 Provider，一个 Key 管理多个模型
• Ollama：本地模型，零成本推理

配置方式有两种：快速路径（openant set-api-key sk-ant-... 使用内置 Claude 默认配置）和向导路径（openant setup llm 交互式配置每个阶段的模型）。向导默认建议在检测/验证阶段使用强推理模型（Claude Opus），在上下文/报告阶段使用轻量模型（Gemma/GPT-4o-mini），节省成本。

使用体验：命令行 + Web UI 双入口

命令行适合集成到 CI/CD 流水线：

openant init <repo-url> -l go
openant scan --verify

OpenAnt 的退出码设计很专业：0 = 无漏洞，1 = 发现漏洞（正常退出），2 = 扫描失败（错误）。对于习惯用 set -e 的 CI 脚本，正确做法是：

openant scan --verify /path/to/repo || rc=$?
if [ "$rc" -gt 1 ]; then
  echo "scan FAILED" >&2; exit "$rc"
fi

Web UI 通过 openant serve 启动，本地监听 127.0.0.1:8080，可提交仓库 URL、实时查看扫描日志、阅读 HTML 报告和 Markdown 摘要。服务器仅绑定本地回环地址，不暴露到网络，适合个人开发机使用。

此外，OpenAnt 支持增量扫描（--diff-base、--pr、--staged），可以只扫描 PR 变更部分，适合高频迭代的开发场景。

局限与挑战

尽管设计精巧，OpenAnt 仍面临一些现实问题：

1. Beta 阶段的质量稳定性：官方坦言部分语言（JavaScript/TypeScript、C/C++ 等）支持仍在 Beta，扫描结果可能不如 Go/Python 可靠。
2. API 成本：完整扫描需要多次 LLM 调用，每个阶段调用不同模型。以扫描 OpenSSL、WordPress 等大型项目为例，Token 消耗不可忽视。如果用云端 API（Anthropic/OpenAI），成本是必须考虑的因素。
3. 误报率虽低但非零：对抗性约束和动态测试大幅降低了误报，但无法完全消除。关键业务系统仍需人工复核。
4. 依赖外部 LLM：扫描效果本质上受限于所用 LLM 的推理能力，较小的本地模型（如 Ollama 上的小模型）可能无法可靠处理复杂的攻击验证环节。

行业意义：开源安全工具的新范式

OpenAnt 的出现，代表了一种新的 SAST 范式：将 LLM 的语义理解能力与传统静态分析相结合，再用对抗性验证来压制误报。

传统的 CodeQL、Semgrep 等工具依赖规则匹配，对新型漏洞（特别是逻辑漏洞、AI 生成的代码漏洞）识别能力有限。OpenAnt 通过让 LLM"理解"代码行为，能够发现规则引擎无法覆盖的问题。

同时，Apache 2.0 开源许可证意味着任何人都可以自由使用、修改、分发。Knostic 选择开源的理由很务实：他们的核心业务是保护 AI Agent，而不是做漏洞研究，开源 OpenAnt 既能回馈社区，又不会影响自身商业模式。

快速上手

# 方式一：快速开始（Anthropic API）
openant set-api-key sk-ant-your-key-here
openant scan /path/to/repo

# 方式二：向导配置（多 Provider）
openant setup llm
openant scan /path/to/repo --llm-config my-config

# 启动 Web UI
openant serve
# 访问 http://127.0.0.1:8080

# 扫描 GitHub PR
openant scan --pr 123

---

项目主页：https://www.knostic.ai/openant | GitHub：https://github.com/knostic/OpenAnt | 许可证：Apache 2.0