Vigolium 拆解：Go 原生 324 个扫描模块，外挂一个会自己写攻击插件的 AI swarm

一、速览：值不值得你花时间

推荐指数：★★★☆☆（3.5 / 5）

先说为什么值得看：它是这批工具里唯一一个「传统扫描器底子 + AI 上层」两层都做实了的。很多 AI 安全工具是从零搭 agent，底层能力薄；Vigolium 反过来 —— 先用 Go 写了一套完整的 DAST 引擎（324 个模块、OAST 带外检测、语义感知参数变异、多阶段流水线、多会话认证），再在上面接 AI。这让它的 AI 层有真东西可调，而不是只能聊天。

几个我觉得做得到位的技术点：

• Value-aware mutation：不是无脑塞 payload，而是先把参数按语义类型分类（integer / UUID / JWT / email），再按意图变异。这直接提高命中率。
• OAST 自动化关联：盲 XSS / SSRF / 命令注入走 interactsh callback，payload 自动关联。
• Swarm 模式会自己写 JS 攻击扩展：master agent 分析输入 → 选模块 → 生成自定义 JS 攻击扩展 → 跑代码审计和 SAST → 执行扫描 → 分诊。这个闭环在开源里不多见。
• agent 运行时是自研的 Go 版 pkg/olium，进程内跑，不靠 subprocess SDK 池。

但分数被压到 3.5，是因为几件事都很硬：agent 模式明确无沙箱（LLM 对宿主机有完整 shell / 文件 / 网络权限，官方自己写的）；扩展能执行任意命令；许可证状态不一致（README 写 MIT，GitHub API 识别为 NOASSERTION）；以及作者是 @j3ssie、项目只有 7 个月，成熟度需要时间验证。

关键数据（截至 2026-10-02）

适合谁

二次开发

二、它是什么，不是什么

• 不是一个纯 AI agent。它的底座是一套完整的 Go DAST 引擎，AI 是可选项（Agentic Scan）。
• 不是 Nuclei 的替代品。Nuclei 是模板驱动的 PoC 匹配；Vigolium 有主动 fuzzing 和变异引擎。
• 不是 SAST。它有 agent audit 做源码审计，但那是 agentic 层的附加能力，主业是 DAST。
• 不是云端 SaaS（开源部分）。Cloud Console 是另外的付费升级版。

提炼三个关键词：dual-engine（原生 + agentic 双引擎）、value-aware mutation（语义感知变异）、in-process agent runtime（进程内 agent 运行时）。

三、Native Scan：324 个模块打底

这是它的价值基座。

流水线分层

soft-404 检测这条值得单独说 —— 目录爆破最大的噪声源就是「什么都返回 200」的应用，用指纹识别 soft-404 能显著降低误报。

上手命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 单目标（默认 balanced 策略）
vigolium scan -t https://example.com

# 指定策略预设
vigolium scan -t https://example.com --strategy deep

# 只跑指定模块
vigolium scan -t https://example.com -m xss-reflected,sqli-error

# 从 OpenAPI spec 扫
vigolium scan -T openapi.yaml -I openapi

# 从 stdin 管道喂 URL
cat urls.txt | vigolium scan

# 只跑单个阶段
vigolium run discovery -t https://example.com

# 出 HTML 报告
vigolium scan -t https://example.com --only discovery --format html -o report.html

认证扫描（IDOR/BOLA 的关键）

1
2
3
4
5
6
7
8
9
10
11
12
13

# 内联多会话（name:Header:value）
vigolium scan -t https://example.com \
  --auth "admin:Cookie:session_id=abc123" \
  --auth "user:Cookie:session_id=xyz789"

# 从文件加载会话
vigolium scan -t https://example.com --auth-file ./admin-session.yaml

# 带自动登录流 + token 提取
vigolium scan -t https://example.com --auth-file ./login-flow.yaml

# 自定义 header
vigolium scan -t https://example.com -H "Authorization: Bearer token123"

多会话是做 IDOR/BOLA 和越权检查的前提 —— 拿两个不同权限的会话去请求同一个资源，才能判断是否存在越权。这个能力在很多扫描器里是缺失的。

注意：--auth / --auth-file 之前叫 --session / --session-file，旧名字作为 deprecated alias 仍可用。

四、Agentic Scan：两种模式，一个自研运行时

所有 agent 模式都跑在原生 Go 的 pkg/olium 引擎上：turn-based loop、内置 tool registry、skills 支持、可插拔 provider driver，不用 subprocess SDK 池。这个选择让性能和可控性都好于「调外部 CLI」。

Autopilot vs Swarm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# Autopilot
vigolium agent autopilot -t https://example.com
vigolium agent autopilot -t https://example.com --source ./src --prompt "focus on auth bypass"
vigolium agent autopilot -t https://example.com --diff main...feature/auth   # 只看 diff
vigolium agent autopilot -t https://example.com --intensity deep

# Swarm
vigolium agent swarm -t https://example.com/api/users --vuln-type sqli
vigolium agent swarm -t https://example.com --discover                       # 全范围
vigolium agent swarm --input "curl -X POST https://example.com/api/login -d '{\"user\":\"admin\"}'"

# 源码审计
vigolium agent audit --source ./src                                  # 默认 auto
vigolium agent audit --source ./src --driver audit --mode deep       # 只跑 vigolium-audit
vigolium agent audit --source ./src --driver piolium --mode balanced # 只跑 piolium
vigolium agent audit --source ./src --driver both                    # 两者依次跑
vigolium agent audit --source ./src -S --output-dir ./audit-out      # 一次性 DB + HTML 报告

# 直接用 olium（TUI 或 headless）
vigolium ol                        # 启动 TUI
vigolium ol --prompt "..."         # 单次（-p 隐含 headless）

Swarm 会生成自定义 JS 攻击扩展这一点是它最特别的地方 —— 不是从固定模块库里选，而是让 agent 针对当前目标现写攻击代码。这既是亮点也是风险（见第七章）。

Provider 支持（10 种）

openai-compatible（默认）、openai-codex-oauth、openai-api-key、openai-responses、anthropic-api-key、anthropic-oauth、anthropic-cli、anthropic-compatible、anthropic-vertex、google-vertex。

同样的模式通过 REST API 暴露，带 SSE streaming 和一个 OpenAI-compatible chat endpoint。

五、Server Mode 与代理桥接

1
2
3
4
5
6
7
8

# 带认证启动 API server
vigolium server -k my-secret-key

# 开透明 HTTP 代理录流量
vigolium server -k my-key --ingest-proxy-port 9003

# 收到流量自动扫
vigolium server -k my-key --scan-on-receive

1
2
3

# 向运行中的 server 灌流量
cat urls.txt | vigolium ingest -s http://localhost:9002
vigolium ingest -s http://localhost:9002 -i api.yaml -I openapi

代理集成：官方给了 burp-vigolium（Burp Suite 扩展）和 caido-vigolium（Caido 插件），两者走同一个 bridge 协议（-B/--burp-bridge-url，别名 --caido-bridge-url），灌进去的流量会标注来源代理。

这条对实战很实用：你手工浏览一遍应用，把 Burp 里的流量直接喂给 Vigolium 去扫，比自己拼 URL 列表高效得多。

六、基准测试

官方声明持续对故意脆弱的应用做 benchmark，并通过 bug bounty 和负责任披露在真实目标上重度测试：

• 自托管（Docker）：DVWA、OWASP Juice Shop、VAmPI、crAPI、Vulnerable Java App、Vulnerable Nginx、OopsSec Store（自定义 Next.js 应用）
• 外部（托管）：Acunetix TestPHP、Gin & Juice Shop、Testfire
• XSS & 多漏洞：BruteLogic XSS、XBOW（XSS、SQLi、SSTI、LFI、SSRF、XXE、命令注入）

跑法：make test-canary（Docker 应用）或 make test-integration（XSS）。

但要注意：README 列了靶场清单，没有给量化的检出率 / 误报率数字。想评估效果得自己跑 make test-canary。这和 Dark-Moon 那种「57 个漏洞」的明示数字相比，透明度上差一档。

七、边界与风险（必须诚实说的部分）

1）agent 模式没有沙箱 —— 这是最重的一条。 官方 SECURITY 章节原文：

Vigolium is an offensive security tool, and two parts of it are intentionally permissive: agent mode runs with no sandbox (the LLM has full shell, file, and network access on the host) and extensions can run arbitrary commands. Run agent mode in a disposable container/VM scoped to the engagement, and treat untrusted extensions like untrusted code.

翻译成人话：跑 agent 模式时，LLM 在你的宿主机上有完整的 shell、文件、网络权限。 它自己给了缓解建议 —— 用一次性的容器 / VM，并且把不受信任的扩展当成不受信任的代码。请务必照做，不要在你的开发机或任何有生产凭证的机器上跑 agent 模式。

对比一下：LuaN1ao 是每 Task 一个 Docker 沙箱 + Gateway 收口出网；Dark-Moon 是 AI 永不直接执行命令、全走 MCP。Vigolium 在这条上是明确落后的，而且它自己承认了。

2）扩展能执行任意命令。 同上，JS 扩展不是沙箱化的。装第三方扩展 = 装任意代码执行。

3）许可证状态不一致。 README 写的是 MIT License，但 GitHub API 把这个仓库识别为 NOASSERTION。这种不一致通常意味着 LICENSE 文件里有非标准条款，或者检测失败。企业使用前请人工读一遍 LICENSE 文件原文，别只看 README 或 API 返回的字段。

4）Cloud Console 是付费升级版，README 说它是「upgraded, fully-featured version」。 这暗示开源版可能在功能上有保留。具体差多少没说明，选型时要自己验证。

5）项目只有 7 个月，118 次提交。 对一套 324 模块的引擎来说，这个体量意味着很多模块可能未经充分实战验证。4 个 open issue 更可能反映的是社区还小，而不是没问题。

6）benchmark 没有量化数字。 见第六章 —— 有靶场清单，没有检出率数据。

7）platform/ 目录不属于核心扫描器。 README 说它装的是外部工具链和 UI Dashboard，且「No changes should be made to it」。看代码时别被这部分干扰。

八、上手建议（按这个顺序来）

1. 先用 Native Scan，别一上来就开 agent。 vigolium scan -t <target> --strategy deep 是零风险入口，能先把 324 个模块的价值吃透。
2. 装 Docker 版最省事，也顺便隔离。别在开发机上直接装二进制。
3. 第一次跑配好 --auth-file。 多会话认证是它做 IDOR/BOLA 的前提，不给会话等于放弃了这块能力。public/presets/sessions/ 里有现成示例。
4. 接 Burp / Caido 桥接。 手工浏览一遍应用再灌流量，比拼 URL 列表高效得多，这是它相对同类工具的一个实战优势。
5. 要用 agent 模式，先准备一次性 VM。 重申一遍：agent 模式无沙箱，LLM 有完整宿主机权限。 用一次性容器 / VM，跑完就扔。
6. 别装来路不明的第三方 JS 扩展。 扩展能执行任意命令，等同于装任意代码。
7. 想验证效果就自己跑 benchmark：make test-canary。别信任何没给数字的说法，包括官方的。
8. 企业用之前人工读 LICENSE 原文（README 的 MIT 和 API 的 NOASSERTION 对不上）。

九、一句话结论

如果你要的是一套模块扎实、输入源丰富、能接 Burp 的 Go 版 DAST，Vigolium 的 Native Scan 值得试；但 Agentic Scan 那层请只在一次性 VM 里碰 —— 它是我近期看到的、官方自己把「无沙箱 + 完整宿主机权限」写得最直白的项目。

给红队的第一动作：Docker 起一套 → vigolium scan -t <你的靶场> --strategy deep → 配 --auth-file 双会话跑一遍 IDOR → 接 Burp 桥接灌真实流量。 这四步走完，你就知道它的 324 个模块对你值多少了。agent 模式先别碰。