在现代 AI 驱动的安全扫描工具中，误报率（False Positive Rate）始终是衡量系统实用性的核心指标。传统依赖概率模型的扫描器往往在追求覆盖度的同时牺牲了精度，导致安全团队不得不花费大量时间人工筛选结果。Shannon 作为一款自主 AI 渗透测试工具，其核心设计理念之一便是通过确定性状态机（Deterministic Finite State Machine，DFSM）模型，将漏洞发现过程转化为可验证、可追溯的状态转换序列，从而在算法层面实现对误报率的严格控制。本文将聚焦 Shannon 的工程实现细节，解析其状态机架构、状态转换规则与误报控制的核心机制。
状态机模型的基础架构
Shannon 的系统架构建立在 Temporal 工作流引擎之上，该引擎本身即为一个分布式状态机实现。与简单的规则匹配引擎不同，Shannon 将整个渗透测试流程建模为一个多阶段的状态转换网络，每个漏洞的发现与验证都遵循预定义的确定性路径。从宏观层面看，整个扫描流程被划分为四个核心状态：侦察（Reconnaissance）、漏洞分析（Vulnerability Analysis）、利用（Exploitation）和报告（Reporting）。这四个状态并非简单的线性排列，而是构成了一个有向图结构，其中漏洞分析状态会根据目标应用的特征分裂为多个并行的子状态（如 Injection 分析、XSS 分析、SSRF 分析等），每个子状态独立演进直至进入终态。
在具体实现中，Shannon 的状态机遵循事件溯源（Event Sourcing）模式。所有状态转换都被持久化为不可变的事件日志，系统可以通过重放历史事件来恢复任意时间点的状态。这种设计带来了两个关键优势：一是容错能力，当扫描过程因网络波动或目标应用崩溃而中断时，状态机可以从上一个检查点无缝恢复，无需从头开始；二是可审计性，每一步状态转换都附带完整的上下文信息，包括触发转换的输入参数、前序状态的执行结果、以及转换发生的精确时间戳。这些信息不仅便于调试，也为后续的误报分析提供了数据基础。
从技术栈角度看，Shannon 的状态机实现充分利用了 Temporal 提供的 "代码即工作流"（Code-as-Workflow）特性。开发者无需手动维护状态数据库或编写复杂的状态持久化逻辑，只需定义状态转换的规则和触发条件，底层引擎会自动处理状态的序列化、重试和并发控制。这种声明式的状态机建模方式降低了工程实现的复杂度，同时也确保了状态转换逻辑的一致性和可靠性。
状态转换规则与误报控制机制
误报产生的根源在于扫描器将某些无害的代码模式或运行时行为误判为安全漏洞。Shannon 通过设计精密的状态转换规则，从两个维度抑制误报的发生：一是确保只有满足严格条件的路径才能进入 "漏洞确认" 状态；二是为每个状态转换设置明确的验证门禁，只有通过验证的请求才能推进到下一状态。
在漏洞分析阶段，Shannon 采用数据流分析（Data Flow Analysis）技术追踪用户输入在程序中的传播路径。具体而言，系统会构建从输入源（Source）到危险 sinks（如数据库查询、命令执行、文件操作等）的完整调用链，并使用 ud 链（Use-Definition Chain）或 du 链（Definition-Use Chain）记录变量的定义点和使用点。只有当扫描器能够证明某一用户可控的变量未经有效的安全处理（如过滤、转义、参数化查询）便到达危险 sinks 时，才会触发从 "分析" 状态到 "利用尝试" 状态的转换。这一转换的判断逻辑是确定性的：给定相同的代码上下文和相同的输入参数，状态机必然得出相同的结论。
从 "利用尝试" 到 "漏洞确认" 状态的转换是 Shannon 误报控制链条中最关键的一环。系统遵循 "No Exploit, No Report" 策略，即如果无法通过实际的攻击 payload 证明漏洞的可利用性，就不允许进入最终报告阶段。这一策略通过一个显式的验证状态实现：当利用代理（Exploitation Agent）尝试执行攻击时，系统会等待目标应用的响应并分析其行为模式。只有当响应满足预定义的漏洞特征（如 SQL 注入导致的数据库错误消息、XSS 攻击导致的脚本执行、认证绕过导致的未授权访问等）时，状态机才会推进到 "确认" 状态；否则，流程将进入 "验证失败" 终态，该漏洞候选不会被纳入最终报告。
值得注意的是，Shannon 的状态机还实现了对不确定行为的处理机制。当利用尝试的结果既不符合漏洞特征，也不符合安全行为特征时（如目标应用返回了异常的错误页面或发生了超时），状态机不会简单地判定为成功或失败，而是将结果标记为 "不确定"，并触发重新尝试或升级分析策略。这种设计避免了因目标应用临时异常而导致的漏报，同时也防止了在信息不足时贸然给出结论。
工程化参数配置与监控要点
为了在生产环境中可靠运行，Shannon 的状态机系统暴露了多个可配置的工程参数，这些参数直接影响误报率和扫描效率的平衡。
首先是状态超时控制。每个状态都设置了最大执行时间，当状态执行超时时，状态机将自动触发回滚或跳过该分支。以侦察阶段为例，默认超时设置为 300 秒；如果目标应用响应缓慢，系统会优雅地终止当前分支并继续处理其他并行任务。这一参数需要根据目标应用的性能和扫描资源进行调优：过短的超时可能导致有效的扫描分支被误杀，而过长的超时则会拖慢整体扫描速度。
其次是并行度配置。Shannon 利用 Temporal 的并发执行能力，在漏洞分析阶段并行启动多个专门的代理（Agent），每个代理负责一类漏洞的检测。这种并行架构虽然提升了效率，但也带来了状态管理的复杂性。系统通过信号量机制限制同时活跃的代理数量，避免对目标应用造成过大压力或触发速率限制。用户可以通过环境变量配置代理池的大小，默认值为 CPU 核心数的两倍。
第三是重试策略与指数退避。对于暂时性失败（如网络超时、目标应用临时无响应），状态机支持配置自动重试次数和退避间隔。典型的配置为：初始重试间隔 1 秒，最大重试次数 3 次，退避系数 2.0。这种策略在大多数情况下能够应对临时性故障，同时避免因持续重试而消耗过多资源或对目标应用造成干扰。
在监控层面，Shannon 通过 Temporal Web UI 提供了状态机执行的可视化界面。安全团队可以实时观察每个工作流实例当前所处的状态、状态的持续时间、以及状态转换的历史轨迹。此外，系统还会生成结构化的状态转移日志，包含每次转换的输入参数、执行结果和耗时统计。这些数据不仅用于运维监控，也可以导出到外部的 SIEM 系统进行分析和告警。
状态机模型的局限性与演进方向
尽管确定性状态机模型显著降低了 Shannon 的误报率，但该方法也存在固有的局限性。首先是状态空间爆炸问题：当漏洞模式过于复杂或目标应用的代码结构高度嵌套时，完整的状态转换图可能变得难以管理。Shannon 通过限制单次分析的代码范围和采用分治策略来缓解这一问题，但对于超大规模代码库，仍可能出现状态数量超出内存限制的情况。
其次是模型假设的局限性。确定性状态机的核心假设是漏洞可以通过预定义的模式进行建模，但现实中存在大量 "逻辑漏洞"（Logical Vulnerabilities），如业务逻辑错误、权限校验缺失、状态管理不当等。这类漏洞往往没有明确的代码特征，难以用传统的状态机模式进行描述。Shannon 对此的应对策略是在状态机之外引入专门的逻辑分析模块，但其效果仍依赖于 LLM 对业务语义的理解能力。
从演进方向看，Shannon 团队正在探索将状态机与图神经网络（Graph Neural Network）结合的可能性。通过将代码的抽象语法树（AST）和控制流图（CFG）编码为图结构，并使用 GNN 学习漏洞模式的向量表示，系统可以在保持状态机可解释性的同时，提升对复杂漏洞的检测能力。此外，自适应状态机也是研究方向之一，即根据扫描历史动态调整状态转换的阈值和权重，在不同类型的应用中采用差异化的检测策略。
结论
Shannon 通过确定性状态机模型为 AI 驱动的安全扫描提供了一种可验证、可追溯的误报控制方案。该系统不仅实现了从侦察到验证的完整自动化流程，更重要的是通过精密的状态转换规则和验证门禁，确保只有真正可利用的漏洞才会被纳入最终报告。虽然该模型在应对复杂漏洞和逻辑漏洞方面仍面临挑战，但其工程化的参数配置和监控机制为安全团队提供了足够的灵活性和可见性。随着状态机理论与深度学习技术的进一步融合，我们有理由相信，基于确定性状态机的安全扫描工具将在误报控制方面达到新的高度，真正实现 "高精度、零噪声" 的安全评估体验。
资料来源：Shannon GitHub 仓库（https://github.com/KeygraphHQ/shannon）、确定性有限状态机在安全扫描中的应用原理研究。