attack-path-stitcher

攻击路径串联器

验证运行任务（#3）会针对每项资产生成已确认的发现。真正的攻击者风险存在于攻击链中：资产 A 上的发现泄露凭据，使攻击者能够利用资产 B 上的发现，进而横向移动到资产 C。此技能用于构建这张图。

已挂载到 cloud-agent 任务 #6。

触发条件

每日 Cron（默认 UTC 时间 03:00）。验证运行任务批次完成后也可以重新运行。

工作流

1. 加载输入。
   • validated/*.json — 所有 engagement 中的每一项已确认发现。
   • artifacts/org-surface.json — 组织范围的攻击面图（资产、服务、网络区域、信任关系）。
   • findings/finding-NNN/evidence/raw-source.txt — 串联攻击路径时用于提取凭据 / 令牌。
2. 构建资产节点。 在 org-surface.json 中为每项资产创建一个节点，并添加以下属性：tier、services、network_zone、trust_relationships。
3. 构建边——每个检测到的横向移动对应一条边。七种检测器详见 reference/edge-detectors.md：
   • 凭据重用（在 A 上泄露的凭据被重用于 B 上的身份验证）
   • 共享密钥 / API 密钥（同一密钥出现在两项资产的证据中）
   • 信任区域传递式访问（位于区域 X 中的 A 可隐式访问区域 X 中的 B）
   • AD 路径跳转（kerberoast / DC sync / RBCD 攻击链）
   • 云 IAM 角色攻击链（从已攻陷的资产执行 assume-role）
   • SSRF → 内部资产访问（A 的 SSRF 可访问 B 的内部端点）
   • 供应链（根据 source-code-scanning SBOM，A 是 B 的依赖项）
4. 计算可达性闭包。 对每个 tier 为 crown_jewel 的节点，通过边反向执行 BFS，查找所有能够访问该节点的外部可访问节点，并将其标记为“入口点”。
5. 将图写入 artifacts/attack-paths.json，并生成供人工阅读的 DOT 文件 artifacts/attack-paths.dot（可用 Graphviz 渲染）。

实现通过 tools/chain-merger.py 运行，由它处理图的构建。此技能提供该工具所参照的规则；具体迭代由工具执行。

输出

{OUTPUT_DIR}/
  artifacts/
    attack-paths.json     # nodes, edges, entry_points, crown_jewel_paths
    attack-paths.dot      # Graphviz source
    attack-paths.md       # ranked list of distinct paths (human read)

attack-paths.json 架构：

{
  "generated_at": "2026-05-13T03:00:00Z",
  "nodes": [
    {"id": "asset42", "tier": "revenue", "services": ["http/443"], "zone": "dmz",
     "external": true, "findings": ["finding-012", "finding-018"], "max_cvss": 9.8}
  ],
  "edges": [
    {"src": "asset42", "dst": "asset77", "detector": "credential-reuse",
     "via_findings": ["finding-012", "finding-019"],
     "evidence": "credential (userpass) present in evidence of asset42 and asset77",
     "feasibility": 1.0}
  ],
  "entry_points": ["asset42", "asset05"],
  "confirmed_paths": [
    {"jewel": "asset99", "paths": [
      {"hops": ["asset42", "asset77", "asset99"],
       "edges": [{"src":"asset42","dst":"asset77","detector":"credential-reuse","feasibility":1.0,"via_findings":["finding-012"]},
                 {"src":"asset77","dst":"asset99","detector":"ssrf-reach","feasibility":1.0,"via_findings":["finding-024"]}],
       "feasibility": 1.0, "max_cvss": 9.8, "path_class": "confirmed"}
    ]}
  ],
  "inferred_paths": [
    {"jewel": "asset99", "paths": [
      {"hops": ["asset05", "asset99"], "edges": [...],
       "feasibility": 0.5, "max_cvss": 7.5, "path_class": "inferred"}
    ]}
  ],
  "truncation": {
    "edge_cap_hit": false, "depth_truncated_count": 0,
    "topn_dropped_count": 0, "max_depth": 8, "edge_cap": 50000
  }
}

对符合 RFP §3.3 要求至关重要：confirmed_paths 仅包含每条边的可行性均为 1.0，且每条边都至少引用一项已验证发现的路径。这些就是 RFP 要求的“已确认攻击路径”。inferred_paths 包含缺少 PoC 证据的拓扑 / 供应链跳转，供分析人员审核，但不会纳入 risk-prioritiser 的修复 SLA 分桶。

规则

1. 边必须有证据支持。 仅当至少一项发现的证据证实该枢纽时，才写入边。不得推测边。
2. 双向 ≠ 默认成立。 如果 A 可以到达 B，不要推断 B 也可以到达 A。每个方向都需要各自的证据。
3. 按 (src, dst, detector) 去重。 多项发现若支持同一跳，则合并为一条边，并在 via_findings 中列出全部发现。
4. 可行性 ∈ {1.0, 0.5, 0.25}。 可靠的 PoC 重跑 = 1.0；有条件（竞争、时序、特定用户）= 0.5；理论上成立（逻辑上可推导，但从未演示）= 0.25。
5. 限制路径枚举。 对每个 crown-jewel，分别为每类路径（已确认 + 推断）返回前 10 条，按 feasibility × max_cvss / hop_count 排序。完整图位于 attack-paths.json，供下游优先级排序使用。
6. 只读。 Stitcher 不会重新触发 PoC，也不会触碰 findings/。它只读取数据。
7. 限制图的大小。 边构建达到 50,000 条时停止；将路径搜索深度限制为 --max-depth（默认 8 跳）。在 JSON 中输出 truncation.edge_cap_hit、truncation.depth_truncated_count 和 truncation.topn_dropped_count，以便下游使用方检测未显式报告的路径丢失。
8. 已确认与推断的区分不可妥协。 仅当每条边的可行性均为 1.0，且每条边的 via_findings 均非空时，路径才会出现在 confirmed_paths 中。仅基于信任区、共享密钥和供应链的链路归入 inferred_paths。这种划分是确保 RFP-§3.3 中“已确认攻击路径”这一主张成立的约定。
9. 强制执行输入模式。 tools/chain-merger.py 会丢弃缺少 finding_id 或 asset，或其 verdict != "VALID" 的 validated/{id}.json 行，并在 stderr 中输出 WARN。上游验证器必须遵循 projects/rfp-3.2/task-03-validation-run.md 中的模式。

参考资料

• reference/edge-detectors.md — 7 条检测器规则及具体信号模式。
• projects/rfp-3.3/task-06-attack-path-stitcher.md — 云端 Agent 运行时约定。