在自主漏洞发现领域，误报率一直是制约工具实用性的关键瓶颈。传统扫描器往往因过度泛化的规则或无效的状态转换而产生大量误报，导致安全团队在警报洪流中疲于奔命。Shannon 作为一款完全自主的 AI 渗透测试工具，通过创新的 "证明性利用"（Proof-by-Exploitation）方法论，将误报控制提升到了新的工程高度。其核心在于构建了一个确定性外层状态机与随机性内层代理协作的混合架构，实现了 "No Exploit, No Report" 的严格策略 —— 只有成功执行的概念验证（PoC）才会被报告，从根本上过滤了理论漏洞与可实际利用漏洞之间的噪声。
混合架构：确定性外壳与随机内核的协同
Shannon 的架构设计体现了工程上的精妙权衡。外层是一个确定性的五阶段状态机：侦察（Reconnaissance）→ 扫描（Scanning）→ 利用（Exploitation）→ 后利用（Post-Exploit）→ 报告（Reporting）。这五个阶段构成了一个不可变的工作流序列，每个阶段的进入和退出条件都是明确定义的。例如，侦察阶段必须完成资产发现、子域名枚举和技术指纹识别后才能进入扫描阶段；扫描阶段需要生成假设性漏洞路径后才能触发利用阶段。这种确定性保证了每次测试的基本流程可复现，为审计提供了可预测的时间线和产出物。
然而，在每个阶段内部，Shannon 采用了随机性的 LLM 驱动代理。这些代理基于 Shannon V1 模型 —— 一个专门为红队操作训练的 MoE Mistral Large 3 架构模型，使用 1,000 个 GPT-5 Pro 和 2,500 个 Opus 4.5 思考数据集进行安全专项训练。代理在给定阶段内自由探索，提出攻击假设、生成载荷、选择工具链。这种 "外层确定、内层随机" 的设计模式，既保证了流程的规范性，又保留了探索的创造性。
五阶段状态机的误报控制点
1. 侦察阶段：构建攻击面地图
侦察阶段的目标是建立完整的应用上下文。状态转移条件包括：是否识别了所有入口点、API 端点、认证机制？是否完成了技术栈指纹识别？这个阶段不直接产生漏洞报告，但为后续分析提供了基础数据。误报控制在这里体现为：避免因不完整的侦察而导致的后续误判。例如，如果未能识别某个 API 版本，可能导致对该端点漏洞状态的错误评估。
2. 扫描阶段：假设生成与静态分析
扫描阶段并行运行多个专门代理，每个代理针对特定漏洞类型（如注入、XSS、SSRF、身份验证绕过）进行代码级分析。关键的状态转移条件是：是否生成了假设性的可利用路径？这些路径必须包含从用户输入点到危险接收器的完整数据流分析。如果静态分析无法构建合理的攻击路径，该假设将被丢弃，避免了基于表面特征的误报。
3. 利用阶段：证明性验证
这是误报控制的核心环节。状态转移条件极其严格：是否成功执行了可验证的利用？是否观察到了预期的安全影响（如数据泄露、权限提升、命令执行）？Shannon 要求代理必须通过浏览器自动化、命令行工具或自定义脚本实际执行攻击，并验证结果。例如，对于 SQL 注入，必须实际提取数据库记录；对于身份验证绕过，必须成功访问受保护资源。如果利用尝试失败，无论静态分析多么有说服力，该漏洞都不会进入下一阶段。
4. 后利用阶段：影响评估
成功利用后，系统进入后利用阶段，评估漏洞的实际影响。状态转移条件包括：是否量化了数据泄露范围？是否验证了权限提升的持久性？这个阶段进一步过滤那些虽然技术上可被利用但实际风险有限的发现，避免了低价值警报。
5. 报告阶段：最终过滤与格式化
最终报告只包含通过所有前阶段验证的漏洞，每个漏洞都必须附带可复现的、可复制粘贴的概念验证。报告生成器会清理任何噪声或幻觉产物，确保输出符合渗透测试报告的专业标准。
确定性状态转移的条件设计
Shannon 的状态转移不依赖于 LLM 的文本判断，而是基于结构化、机器可验证的条件。这些条件包括：
- HTTP 响应特征：状态码、响应头、正文内容模式
- 数据库操作结果：查询执行成功 / 失败、返回行数变化、错误消息签名
- 文件系统操作：文件创建 / 修改 / 删除的成功确认
- 进程行为：新进程生成、网络连接建立、权限变更
- 会话状态：认证令牌的有效性、用户角色的实际变更
例如，从 "扫描" 到 "利用" 的状态转移，可能需要满足："针对端点 /api/user/{id} 的 IDOR 假设已生成" AND "已构造出可修改其他用户数据的 Payload" AND "通过 HTTP PATCH 请求测试返回 200 状态码"。只有这些具体条件全部满足，状态机才会推进。
共享状态：状态机的上下文存储器
Shannon 维护一个共享测试状态，作为状态机的全局上下文。这个状态包括：
- 目标清单：已识别的 URL、端点、参数
- 认证凭据：有效的会话令牌、API 密钥、用户账户
- 成功载荷库：已验证可用的攻击向量和对应参数
- 探索历史：已尝试的攻击路径及其结果
- 环境上下文：应用技术栈、框架版本、配置信息
这个共享状态确保了即使内层代理的探索是随机的，整个测试过程仍然保持上下文连贯性。状态机在每个决策点都会查询共享状态，避免重复探索或矛盾操作。
工程实践：可落地的参数与监控
关键配置参数
在部署类似架构时，以下参数需要精细调校：
- 阶段超时阈值：每个阶段的最大允许时间（侦察：30 分钟，扫描：45 分钟，利用：60 分钟，后利用：20 分钟，报告：10 分钟）
- 利用验证严格度：定义 "成功利用" 的具体标准（如：数据泄露≥10 条记录，权限提升持续≥5 分钟）
- 状态转移置信度：要求多少比例的子任务完成才能推进阶段（推荐≥85%）
- 资源使用限制：每个代理的最大 CPU / 内存占用，防止资源耗尽
监控指标清单
实施过程中应监控以下关键指标：
- 阶段完成率：各阶段成功完成的比例
- 状态转移时间：阶段间切换的平均耗时
- 利用验证成功率：假设性漏洞中通过实际验证的比例
- 误报过滤率：被状态机丢弃的假设数量占总假设的比例
- 上下文命中率：共享状态被有效查询和更新的频率
集成检查清单
将确定性状态机集成到现有安全流程时，需要验证：
- 是否建立了明确的阶段边界和交接标准？
- 状态转移条件是否完全基于机器可验证的证据？
- 共享状态是否被所有代理正确访问和更新？
- 报告生成是否只包含通过完整验证链的发现？
- 整个流程是否具备足够的可复现性？
局限性与未来方向
尽管 Shannon 的架构在误报控制方面取得了显著进展，但仍存在局限性。外层状态机的确定性依赖于内层代理提供足够质量的输入，如果 LLM 产生大量低质量假设，状态机可能 "空转"。此外，"零误报" 的承诺可能以漏报为代价 —— 某些实际存在但难以自动化验证的漏洞可能被过滤掉。
未来的改进方向包括：引入更细粒度的状态子机、实现动态状态转移条件调整、增强共享状态的智能索引能力。同时，将状态机的决策过程完全透明化、可审计化，将进一步提升这类系统的可信度。
结语
Shannon 通过构建确定性外层状态机与随机性内层代理的混合架构，为自主漏洞发现的误报控制问题提供了工程化的解决方案。其核心洞察在于：将创造性的漏洞探索与规范性的验证流程分离，让 LLM 负责前者，让确定性状态机负责后者。这种分离不仅降低了误报率，还使整个测试过程变得可预测、可审计、可集成。
对于安全团队而言，Shannon 的实践表明，完全消除误报或许不可能，但通过精心设计的状态机架构，可以将误报控制在可管理的范围内，让自动化安全测试真正成为开发流程中可靠的一环。
资料来源：
- KeygraphHQ/shannon GitHub 仓库（主要来源）
- Shannon AI 自动渗透测试平台技术文档
- 相关技术分析文章与社区讨论