Hotdry.
归档
security

Shannon自主漏洞发现工作流编排引擎：多阶段管道化设计与状态管理

解析Shannon如何利用Temporal构建自主AI渗透测试的编排引擎，涵盖5阶段管道化工作流、Git状态隔离、错误分类重试与可观测性设计。

自主 AI 安全测试工具的核心挑战不在于单点能力，而在于如何将 "侦察 - 分析 - 利用 - 报告" 这一复杂流程可靠地编排为可重复、可观测、可容错的自动化工作流。Shannon 作为开源的自主 AI 渗透测试框架，其工程实现为这一领域提供了值得参考的范式。

架构概览：五阶段管道化工作流

Shannon 将整个渗透测试流程抽象为五个明确的阶段，通过 Temporal 工作流引擎进行编排。这种分层设计既保证了阶段的顺序依赖，又最大化了并行效率。

阶段一：Pre-Reconnaissance
执行预侦察代理，完成环境初始化与基础信息收集。此阶段为串行执行，确保后续阶段拥有完整的上下文。

阶段二：Reconnaissance
运行侦察代理，结合源码分析与动态探测构建攻击面地图。该阶段整合 Nmap、Subfinder、WhatWeb 等工具，产出包含所有入口点、API 端点和认证机制的详细地图。

阶段三与四：Vulnerability Analysis + Exploitation（管道化并行）
这是架构设计的核心创新点。传统批处理模式会等待所有漏洞分析完成后再统一进入利用阶段，而 Shannon 采用 "管道化"(pipelined) 设计：

  • 五个独立的漏洞分析管道并行运行，分别覆盖 Injection、XSS、Authentication、SSRF、Authorization 五类 OWASP 漏洞
  • 每个管道内部采用 "vuln agent → queue check → conditional exploit" 的链式结构
  • 当某个漏洞类型的分析代理完成后，立即检查该类型的漏洞队列，若存在可利用点则立即启动对应的 exploit agent，无需等待其他漏洞类型分析完成

这种设计消除了阶段间的同步屏障，显著缩短了整体执行时间。代码实现上使用Promise.allSettled确保单个管道失败不会影响其他管道继续执行。

阶段五：Reporting
串行执行报告生成。首先聚合各利用代理产出的证据文件，然后运行报告代理添加执行摘要与清理，最后注入模型元数据完成最终报告。

编排引擎核心：Temporal 工作流与活动设计

Shannon 选择 Temporal 作为底层编排引擎，这一决策带来了持久化执行、自动重试、状态查询等企业级特性。

工作流定义与状态管理

工作流核心定义在pentestPipelineWorkflow函数中，维护一个可查询的PipelineState状态对象，包含：

interface PipelineState {
  status: 'running' | 'completed' | 'failed';
  currentPhase: string | null;
  currentAgent: string | null;
  completedAgents: string[];
  failedAgent: string | null;
  error: string | null;
  startTime: number;
  agentMetrics: Record<string, AgentMetrics>;
  summary: PipelineSummary | null;
}

通过setHandler(getProgress, ...)注册查询处理器，外部可通过 Temporal CLI 或 Web UI 实时获取工作流进度，包括当前阶段、已完成代理列表、各代理耗时与成本等指标。

活动 (Activity) 的精细化设计

每个代理执行被封装为独立的 Temporal Activity，具备以下工程特性：

心跳机制：每 2 秒发送一次心跳信号，防止长时间运行的 AI 代理调用被误判为死锁。生产环境配置 10 分钟心跳超时，测试环境 5 分钟。

Git 状态隔离：每次 Activity 执行前创建 Git checkpoint，成功后 commit，失败时 rollback。这确保了重试时工作区的干净状态，避免残留文件影响后续尝试。

错误分类与重试策略：

const PRODUCTION_RETRY = {
  initialInterval: '5 minutes',
  maximumInterval: '30 minutes',
  backoffCoefficient: 2,
  maximumAttempts: 50,
  nonRetryableErrorTypes: [
    'AuthenticationError', 'PermissionError', 'InvalidRequestError',
    'RequestTooLargeError', 'ConfigurationError', 'InvalidTargetError',
    'ExecutionLimitError',
  ],
};

系统将错误分为可重试 (计费错误、瞬态网络错误) 与不可重试 (认证失败、配置错误) 两类，避免在无法自愈的错误上浪费资源。输出验证错误单独限制为最多 3 次重试，因这类错误通常不会自行恢复。

防御性编程：针对 LLM API 的 spending cap 场景，系统在执行后校验 "回合数≤2 且成本为 $0" 的异常模式，结合正则匹配识别计费限制，主动触发重试而非返回虚假的成功结果。

并发控制与资源管理

Worker 配置maxConcurrentActivityTaskExecutions: 25，支持最多 25 个并发 Activity 执行。这一参数基于以下计算：5 个漏洞类型 × (1 个 vuln agent + 1 个 exploit agent) + 其他阶段 ≈ 12-15 个并发 Activity，预留余量支持多工作流并行。

每个 Activity 配置 2 小时执行超时，满足 LLM 代理长时间运行的需求。同时通过heartbeatTimeout确保卡死的 Activity 能被及时检测并重新调度。

可观测性与审计

Shannon 构建了完整的审计体系：

  • 工作流级日志：通过logPhaseTransition和logWorkflowComplete在活动边界记录阶段转换与完成摘要
  • 代理级日志：每个代理的每次尝试 (attempt) 都记录开始时间、提示词、执行结果、成本、耗时、Git checkpoint 哈希
  • 实时查询：通过 Temporal Query 机制，外部系统可实时拉取PipelineProgress获取工作流 ID、已耗时、当前阶段等运行时信息
  • Web UI：Temporal 自带的 Web UI (端口 8233) 提供可视化工作流执行轨迹、重试历史、状态变化时间线

工程实践建议

基于 Shannon 的实现，构建自主 AI 安全测试工作流时可参考以下参数与策略：

超时参数：

  • Activity 执行超时：2 小时 (生产) / 10 分钟 (测试)
  • 心跳超时：10 分钟 (生产) / 5 分钟 (测试)
  • 心跳间隔：2 秒 (必须小于心跳超时)

重试策略：

  • 初始间隔：5 分钟，最大间隔：30 分钟，退避系数：2
  • 最大尝试次数：50 次 (生产) / 5 次 (测试)
  • 输出验证错误单独限制 3 次

并发控制：

  • Worker 并发 Activity 数：≥ (漏洞类型数 × 2 + 3) × 预期并行工作流数
  • Shannon 配置 25 并发，支持约 5 个并行工作流

成本监控：

  • 单次完整运行成本约 $50 (Claude 4.5 Sonnet)，耗时 1-1.5 小时
  • 通过AgentMetrics实时追踪每个代理的 token 消耗与 API 成本
  • 设置 spending cap 检测机制，避免静默失败

状态隔离：

  • 每次 Activity 尝试前创建 Git checkpoint
  • 失败后 rollback，成功后 commit
  • 确保重试幂等性与工作区一致性

局限与注意事项

Shannon 的编排引擎设计针对白盒 (源码可用) Web 应用测试优化，当前版本明确排除了第三方库漏洞、配置错误等无法通过主动利用验证的问题类型。此外，LLM 可能产生幻觉，最终报告仍需人工验证其准确性与严重程度评估。

生产环境部署时需注意：Temporal 的持久化存储默认使用 SQLite (/home/temporal/temporal.db)，高吞吐量场景建议切换至 PostgreSQL 或 MySQL 后端。

参考来源

查看归档