在应用安全领域，传统的渗透测试与自动化扫描之间存在显著差距。前者依赖安全专家手动执行，周期长、成本高；后者虽能快速覆盖，但往往产生大量误报，且难以验证漏洞的实际可利用性。Shannon 作为一款由 Keygraph 开发的自主白盒渗透测试框架，试图通过 AI 智能体与源码分析的深度融合，填补这一工程化安全测试的空白。该工具的核心设计理念是将静态代码分析作为攻击向量发现的引导器，再通过动态漏洞利用验证其真实可 exploitation 价值，最终输出仅包含可复现 Proof-of-Concept 的高可信度报告。
多阶段多智能体架构设计
Shannon 采用五阶段流水线架构，每一阶段由专门的多智能体协同完成。这种设计将渗透测试的完整生命周期分解为可并行执行、可断点恢复的独立工作单元。理解这一架构是掌握该工具工程化部署参数的前提。
第一阶段：预侦察（Pre-Reconnaissance）。 工具首先使用 Nmap、Subfinder、WhatWeb 等传统安全扫描器对目标进行外部指纹识别，获取基础设施层面的技术栈信息。同时，该阶段并行执行源码扫描，识别应用框架类型、入口点以及潜在的攻击面。这种「外部扫描 + 内部代码分析」的双通道输入，为后续阶段提供了更为精确的目标画像。
第二阶段：侦察（Reconnaissance）。 基于预侦察的发现，Shannon 构建详细的攻击面映射表。该阶段引入浏览器自动化能力，通过模拟真实用户行为探索应用功能。这一步骤的核心价值在于将代码层面的分析结果与运行时行为进行关联，发现仅通过静态分析无法识别的业务逻辑漏洞。
第三阶段：漏洞分析（Vulnerability Analysis）。 该阶段是整个框架的并行核心，五个独立智能体分别负责 Injection、XSS、SSRF、Authentication、Authorization 五个 OWASP 分类的漏洞假设生成。对于 Injection 和 SSRF 等数据流敏感型漏洞，智能体执行结构化的数据流分析，追踪用户输入到危险 sink 的完整路径。每个智能体输出的是「可 exploitation 的假设路径」列表，而非最终结论。
第四阶段：漏洞利用（Exploitation）。 接收上一阶段输出的假设路径后，专门的重放智能体尝试执行真实攻击。该阶段严格遵循「No Exploit, No Report」策略：只有成功完成 exploitation 并能演示实际影响的发现才会进入最终报告。无法被 exploitation 的假设直接被丢弃，这一机制从根本上降低了误报率。
第五阶段：报告（Reporting）。 最终阶段将侦察数据与成功利用的证据整合，生成专业的渗透测试报告。每项发现均附带可复制粘贴的 PoC 代码，供开发人员直接验证和修复。
静态 - 动态关联分析机制
Shannon Pro 版本引入的静态 - 动态关联分析是其区别于 Lite 版本的核心技术差异。该机制的核心创新在于将静态代码分析发现的数据流漏洞与动态渗透测试的 exploitation 结果进行双向关联。
在静态分析层面，Shannon Pro 将代码库转换为 Code Property Graph（CPG），融合了抽象语法树（AST）、控制流图（CFG）和程序依赖图（PDG）。基于这个复合图结构，工具执行两项关键分析：其一是数据流追踪，识别用户输入源（sources）到危险操作 sink（如 SQL 查询、命令执行）之间的完整路径，在路径的每个节点上，LLM 会评估当前上下文中应用的消毒措施是否足够，而非依赖硬编码的安全函数白名单；其二是单点问题检测，使用 LLM 识别弱加密、硬编码凭证、不安全配置等单点漏洞。
这种关联分析的工程化价值体现在：静态阶段发现的漏洞不会被直接报告为「理论风险」，而是被注入到动态渗透测试的利用队列中。攻击智能体会尝试对这些漏洞执行真实 exploitation，确认后可利用性后，报告将同时包含 PoC 和精确的源码位置。开发人员因此获得了两项关键信息：漏洞可被证明 exploitation 的证据，以及需要修复的具体代码行。
关键部署参数与工程化配置
在实际工程部署中，以下参数和配置选项对扫描效果有直接影响。
并发控制参数。 max_concurrent_pipelines 控制同时运行的漏洞分析管道数量，默认值为 5。降低该值可减少 API 速率限制触发的概率，但会显著增加整体扫描时间。对于使用 Anthropic 订阅计划的用户，由于其使用量按滚动 5 小时窗口重置，默认的 30 分钟最大退避策略会在窗口耗尽前提前终止，此时应配置 retry_preset: subscription 将最大退避时间延长至 6 小时并最多重试 100 次。
凭证管理。 支持三种凭证配置方式：环境变量优先级最高（ANTHROPIC_API_KEY），其次是配置文件。对于 TOTP 双因素认证场景，只需在配置中提供 totp_secret，工具即可自动生成认证码。
模型分层配置。 Shannon 使用三层模型架构：small 模型（claude-haiku-4-5）用于摘要生成，medium 模型（claude-sonnet-4-6）用于安全分析，large 模型（claude-opus-4-6）用于深度推理。在使用 AWS Bedrock 或 Google Vertex AI 时，需要显式指定各层级的模型 ID。
工作空间与恢复机制。 每次扫描创建独立工作空间，支持通过 -w 参数命名。扫描中断后，使用相同工作空间名称可从断点恢复，已完成的智能体任务会被跳过。每个智能体的进度通过 git 提交进行_checkpoint，确保恢复后状态的完整性。
基准测试与局限性
根据公开的基准测试数据，Shannon Lite 在无提示的、源码感知的 XBOW 安全基准上取得了 96.15% 的得分（100/104 次 exploitation 成功）。在针对 OWASP Juice Shop 的实际测试中，该工具单次运行识别了超过 20 个漏洞，包括 SQL 注入导致的认证绕过和数据库渗透。
然而，使用者应当注意其固有限制。首先，该工具明确限定为白盒测试模式，需要目标应用的完整源码和仓库结构。其次，Lite 版本的上下文窗口限制可能导致分析不够全面，Pro 版本通过 CPG 引擎缓解了这一问题。第三，LLM 固有的幻觉风险意味着人工复核仍是必要环节，工具文档明确建议对所有报告发现进行有效性验证。最后，运行时间通常在 1 至 1.5 小时，使用 Claude 4.5 Sonnet 模型的单次扫描成本约 50 美元。
小结
Shannon 代表了 AI 在工程化安全测试领域的一次有意义的探索。其通过静态代码分析引导攻击向量发现、再通过动态 exploitation 验证真实可利用性的设计思路，有效降低了传统自动化扫描的高误报率，同时填补了人工渗透测试在频次和成本上的缺口。对于需要在 CI/CD 流程中集成持续性安全验证的团队，该框架提供了一个可参数化配置的工程化选项，但使用者必须理解其适用边界：在获得高效漏洞验证能力的同时，仍需保持对 AI 生成内容的人工监督习惯。
资料来源：GitHub KeygraphHQ/shannon（AGPL-3.0 开源协议）