Shannon 拆解：一个「打不穿就不写报告」的 AI 渗透测试 Agent

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

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

给到这个分数的理由：它是目前把「利用验证」做进主流程、且工程完成度相当高的开源 AI 渗透 Agent —— 分析源码 → 找攻击面 → 真打一遍 → 只留打穿的。这一步过滤掉了绝大多数 AI 安全工具最烦人的问题：一堆看着像漏洞、实际打不动的噪声。

扣掉的一颗星在两个地方：一是 AGPL-3.0（不是 Apache-2.0，后面单独说，这条对企业很关键）；二是它会真的改目标系统状态，只能打 staging，而且每次跑都要烧模型 token，成本得自己掂量。

关键数据（截至 2026-09-19）

适合谁

一句话判断：它服务的是「有 staging 环境、想要可复现结论的人」，不是「想要一键合规报告的人」。

二次开发

允许吗？能改，但要看你怎么用。 AGPL-3.0 不同于 Apache-2.0：自己内部用、自己改、自己托管都没问题；一旦你把它包装成对外提供的服务（SaaS、托管扫描平台），网络交互就会触发 AGPL 的源码提供义务 —— 你的改动也得开源。这条直接决定了它能不能进商业产品的分发链路。

难不难？分层看：

二、先说它是什么，不是什么

它的官方一句话定位：autonomous AI pentester for web applications and APIs——面向 Web 应用和 API 的自主渗透测试 Agent。

跟常见工具的区别：

• 扫描器（nuclei、zap）：规则匹配 → 报「可能存在」→ 人工复现
• 评估派 AI 工具（Garak 等）：拿探针打模型，产出是分数
• Shannon：读你的源码 → 推攻击路径 → 对正在运行的应用真打一遍 → 只把打穿的写进报告

README 里那句口号就是它的产品哲学：No exploit, no report. 没有可复现的 PoC，就不算发现。

这个取舍很有意思：它必然漏报（模型没想到、或者想到了但没打成的漏洞，都不会出现在报告里），换来的是极低的误报。对「报告能不能直接交给研发去修」这件事，后者通常更值钱。

项目名来自 Claude Shannon（信息论之父）。作者给的理由挺贴切：渗透测试本质是个信息问题，每一次探测都在降低对系统状态的不确定性。

三、架构：两条候选流，一次裁决

1
2
3
4
5
6
7
8
9
10
11

源码 ──┬──► ① 侦察 + 漏洞分析（对着跑起来的应用）
       │                    │
       └──► ② Agentic 安全代码分析
                            │
            ③ 候选归并（去重 + 合并）──► 利用队列
                            │
            ④ 利用 Agent 真打（浏览器自动化 + 命令行）
                            │
            ⑤ 验证：打不穿的直接丢弃
                            │
            ⑥ 报告：PDF · Markdown · JSON · SARIF 2.1.0

六个阶段：

1. 侦察与漏洞分析：探索运行中的应用，把运行时行为跟源码对上，按注入、XSS、SSRF、认证、授权五类分派专门的 Agent
2. Agentic 安全代码分析：先画架构图 —— 信任边界、暴露接口、依赖、数据流、高风险资产，再对重点区域开定向调查
3. 候选归并：两条流的结果合并、去重，编成利用队列
4. 利用 Agent：对运行中的目标尝试真实 PoC
5. 验证：打不出来的全部丢掉
6. 报告：PDF + Markdown 带证据，另有 JSON 和 SARIF 给下游系统

只有状态为 exploited 的发现才计入 CI/CD 的严重度门禁 —— 代码分析的「假设」不会让流水线挂掉。这个设计很关键，否则 AI 的猜测会天天卡住发布。

每次扫描跑在一次性的 Docker 容器里，工作区隔离，目标仓库以只读方式挂载进去。

四、Shannon 3.0 带来了什么

README 顶部挂着 3.0 的公告，几条实打实的升级：

• 更深的安全代码分析
• 发现结果经过更严格的复核
• 重写的 CLI
• 原生 CI/CD（GitHub Action / GitLab CI 组件）
• 专业的 PDF 报告
• SARIF（exploit 模式默认开启）

SARIF 这点值得单独说：有了它，Shannon 的发现可以直接进 GitHub code scanning，跟其他扫描器结果放在同一个视图里看，不用再维护一套单独的看板。

五、上手

前置条件：Docker（worker 容器）、Node.js 18+、模型 API key（Anthropic / OpenAI / xAI / AWS Bedrock，或本地模型）。

1
2
3
4
5
6
7

# 交互式配置凭证
npx @keygraph/shannon@latest setup

# 对一个「源码可得」的目标开打
npx @keygraph/shannon@latest start \
  -u https://your-app.com \
  -r /path/to/your/repo

它会拉起 worker 镜像、启动本地基础设施、把目标仓库只读挂进临时容器，结果写进本地工作区。工作区可恢复 —— 扫描中断后能从断点接着跑，不重复已完成的工作。

接 CI：

1
2
3
4
5
6
7

- name: Run Shannon
  uses: KeygraphHQ/shannon-action@v1
  with:
    url: https://staging.example.com
    api-key: ${{ secrets.SHANNON_AI_API_KEY }}
    fail-on-severity: high
    upload-sarif: true

要求私有仓库、带 Docker 和 Docker Compose v2 的 runner、能从 runner 访问到目标环境。

一个便利细节：它支持 OpenAI Codex（ChatGPT Plus/Pro）和 xAI 订阅的登录方式，不想烧 API 额度的话可以走订阅。Claude Code 订阅则只有 1.9.0 及更早版本支持（那是最后一个基于 Claude Agent SDK 构建的发布）。

六、效果怎么评估

作者在仓库里放了一份 benchmark：拿 Photoview 2.4.0（Doyensec 对比 Aikido 和 XBOW 时用的同一个应用、同一个版本）跑了一遍，三种模型的报告（DeepSeek v4 Flash / Grok 4.6 / Claude Opus 5）的 PDF 和 SARIF 都公开在仓库里，方法论和局限也写在配套的文档里。

我的建议是别只看 star 数，去翻那份 SARIF：

• 看它报了什么类别（是不是集中在注入 / 越权这类它覆盖得好的面）
• 看证据链是否完整（请求、响应、复现步骤）
• 换你自己的项目跑一遍，对比人工渗透的结果，才能知道它在你的技术栈上有多少召回

star 数高说明社区热度，不等于在你的场景里好用。

七、边界与风险（这几条别跳过）

1. 它真的会改目标系统。 利用 Agent 会创建用户、提交表单、改变应用状态、触发对外请求。只在 sandbox / staging / 本地开发环境里跑，数据用一次性的。 别指向生产。

2. 授权是硬前提。 只打你自己拥有或已有明确书面授权的系统。这条不是免责话术 —— 它是主动发起攻击的工具，法律边界比被动扫描器严得多。

3. AGPL-3.0 的合规边界。 内部自用没问题，做成对外服务就要开源你的改动。企业引入前先过一遍法务。

4. 报告仍需人工复核。 README 自己就写明：LLM 生成的报告可能包含证据薄弱或错误的细节。别把 PoC 通过当成结论。

5. 模型能力决定上限。 模型不遵循指令时，扫描质量会明显下降；不同 provider 的表现差得挺多。

6. 覆盖有边界。 当前聚焦 OWASP 类可 exploited 的问题（注入、XSS、SSRF、失效认证、失效授权）。开源版定位是「日常开发和 CI 里的快速代码驱动渗透」，穷尽式的 agentic SAST、更宽的扫描覆盖、集中式治理和全生命周期漏洞管理，作者放在了商业版 Keygraph Platform 里。

八、一句话结论

Shannon 的差异不在「AI 会挖洞」，而在它愿意为每一条发现付出一次真实利用的代价，并接受打不穿就删掉的代价。这让它从「又一个 AI 扫描器」变成了「可以接进流水线的一道门禁」。

适合：有 staging、有授权流程、想让安全测试跟着发布节奏跑的团队。
不适合：想拿它替代年度人工渗透测试，或者打算闭源集成到商业产品里 —— 前者它自己就说做不到（定位是「把渗透左移」，不是替代专家），后者被 AGPL 挡着。

本文是 Scanners-Box 每日 AI 工具推荐 的详细分析篇。