Shannon：一个把源码分析和真实利用绑在一起的自主 AI 渗透测试代理
Shannon 是一款自主的白盒 AI 渗透测试工具，通过分析源代码识别攻击路径，并执行真实攻击来在上线前证明漏洞存在。
秒懂
- 它是什么？
- Shannon 是 Keygraph 开源的自主 AI 渗透测试器，它读你的源码、找攻击路径、跑真实利用，只把有 PoC 的漏洞写进报告。本文拆解它的运行机制、上手命令、已知边界，以及它和传统 DAST 的根本差异。
- 适合谁用？
- Shannon 适合那些已经具备 Docker 和 Node.js 18+ 环境、愿意自带 AI 模型密钥、并且有明确授权测试范围的团队。它不适合没有源码可读的黑盒场景，也不适合对模型供应商安全策略不敏感的组织。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 7 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
为什么需要一个每年能跑 365 次的渗透测试代理
Shannon 解决的问题很具体：开发团队用 Claude Code、Cursor 这类工具持续交付代码，但渗透测试通常一年才做一次。这个时间差就是漏洞窗口。Shannon 想把这个窗口关掉，它把渗透测试变成一个可以按构建或发布频率运行的自动化任务。它面向的是有源码访问权的 Web 应用和 API 团队，尤其是那些没有预算请全年驻场渗透测试员的中小团队。它不是一个黑盒扫描器，而是一个白盒代理，它先读你的代码，再决定打哪里。
从源码到 PoC：Shannon 的执行链路
Shannon 的工作方式分三步。第一步，它分析目标应用的源代码，识别潜在攻击向量。第二步，它用浏览器自动化和命令行工具对运行中的应用及其 API 发起真实利用。第三步，它只把有可用 PoC 的漏洞写进最终报告。这意味着报告里的每一条发现都对应一个可复现的利用步骤，而不是泛泛的警告。这种设计把误报率压到很低，因为每个结论都经过实际验证。从仓库布局看，它有一个 worker 容器，目标仓库以只读方式挂载进去，结果写到本地工作区。这个架构保证了被测代码不会被修改。
一条命令启动，但前置条件不少
上手命令很简单。先跑 `npx @keygraph/shannon setup` 配置凭证，再跑 `npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo` 开始测试。但前置条件比命令本身更值得注意。你需要 Docker 来跑 worker 容器，需要 Node.js 18+，还需要至少一个 AI 提供商的 API 密钥，支持 Anthropic、OpenAI、xAI、AWS Bedrock，以及任何兼容 Anthropic Messages API 或 OpenAI Chat Completions/Responses API 的自定义端点。Keygraph 不代理你的模型流量，这点对隐私敏感的组织是加分项。另外，Anthropic 和 OpenAI 对网络安全工作负载有实时防护，可能中断扫描，所以首次运行前必须完成它们的安全测试者审核流程。
报告长什么样：三个真实示例说明问题
README 里给了三个示例报告，都是针对故意含漏洞的应用。OWASP Juice Shop 的报告列出了 20 多个漏洞，包括认证绕过、SQL 注入、IDOR 和 SSRF。c{api}tal API 的报告大约有 15 个严重和高危 API 发现，涉及命令注入、认证绕过和批量赋值。OWASP crAPI 的报告有 15 个以上严重和高危发现，集中在 JWT、注入、SSRF 和 API 授权路径。这些数字不是承诺，只是示例，但它们展示了 Shannon 的输出风格：按严重度分类，每项都有可复现的步骤。如果你要评估这个工具，拿 Juice Shop 跑一遍，对比官方示例报告，是最快的验证方式。
安全边界和许可：AGPL-3.0 意味着什么
Shannon 的许可协议是 AGPL-3.0，这对商业使用有实际影响。如果你修改了代码并对外分发，你必须以 AGPL-3.0 开源你的修改。如果你只是通过 npx 运行它，不修改，那通常不需要开源你的应用代码，但具体场景最好咨询法律意见。另一个边界是安全警告：README 明确说它主动执行利用，只能针对你拥有或获得书面授权的环境运行，不要对生产系统使用。这个警告不是形式，因为自动化利用可能造成数据破坏或服务中断。另外，模型供应商的 cyber safeguards 可能随时打断扫描，这意味着你无法保证一次扫描能完整跑完，需要重试机制或人工干预。
和传统 DAST 的本质区别：白盒引导动态测试
传统 DAST 工具只从外部发请求，不读源码，所以它们经常报一堆无法确认的潜在问题。Shannon 的路径不同：它先用源码分析确定攻击计划，再用动态测试验证。这个顺序让测试更聚焦，也更容易找到需要业务逻辑知识才能发现的漏洞，比如 IDOR 或批量赋值。但代价是，它必须能读到你的源码。如果你只有编译后的二进制或第三方黑盒服务，Shannon 的优势就没了。另一个区别是它依赖 LLM 的推理能力，而传统 DAST 依赖预定义规则。这意味着 Shannon 的行为有一定不可预测性，你无法精确控制它下一步做什么，只能通过配置文件设定焦点区域和规则。
配置灵活性和已知的坑
Shannon 支持通过配置文件描述登录流程、测试凭证、TOTP、基于邮件的登录流程、焦点区域和规则。这意味着它可以做认证后的测试，这是很多黑盒扫描器做不到的。但配置文件本身需要维护，应用登录逻辑变了，配置也得跟着改。另一个坑是模型订阅支持的不一致：最新版支持 OpenAI Codex 和 xAI 的订阅，但不支持 Claude Code 订阅，要用 Claude Code 订阅只能退回 1.9.0 版本，那是基于 Claude Agent SDK 的最后版本。如果你依赖 Claude Code 订阅，要么接受旧版本，要么换用 API 密钥。这种版本分裂在工具演进中很常见，但值得在选型时确认。
编辑结论
Shannon 适合那些已经具备 Docker 和 Node.js 18+ 环境、愿意自带 AI 模型密钥、并且有明确授权测试范围的团队。它不适合没有源码可读的黑盒场景，也不适合对模型供应商安全策略不敏感的组织。在首次运行前，务必完成 Anthropic 或 OpenAI 的 cyber safeguards 审核，否则扫描可能被中途打断。用 `npx @keygraph/shannon setup` 配置凭证，用 `npx @keygraph/shannon start -u <URL> -r <repo>` 启动测试，先在一个故意含漏洞的应用（如 OWASP Juice Shop）上验证报告格式，再考虑接入 CI。AGPL-3.0 意味着如果你修改并分发代码，必须开源你的修改，这一点在商业集成前要评估清楚。
社区笔记