risk-prioritiser

风险优先级排序

使用攻击路径图和客户端提供的业务等级映射表，输出组织应优先修复的单一排序路径列表。挂载到云 Agent 任务 #7。

触发条件

在 attack-path-stitcher（任务 #6）完成后每日通过 Cron 触发。写入新的 validated/*.json 且 nvd.score >= 9.0 时，也会通过事件触发。

工作流

1. 加载输入。
   • artifacts/attack-paths.json — 任务 #6 生成的图。拆分为 confirmed_paths（RFP 级）和 inferred_paths（拓扑／供应链）。
   • business-tier-map.csv — 客户提供的资产 → 等级映射表。搜索顺序：{OUTPUT_DIR}/business-tier-map.csv → projects/rfp-3.3/schemas/business-tier-map.csv。
2. 为每个 confirmed_paths 条目评分。
   • feasibility = 路径上每条边的 feasibility 乘积。对于已确认路径，该值始终为 1.0。
   • technical_severity = max_cvss_along_path / 10。
   • business_impact = 目标节点的等级权重（按定义，crown_jewel = 1.0）。
   • entry_exposure = 若入口节点为 external: true，则为 1.0；否则为 0.5。
   • 最终得分 = feasibility × technical_severity × business_impact × entry_exposure。
3. **为每个不在已确认路径上的单资产已验证发现项评分。**使用相同公式；feasibility = 1.0，business_impact = 资产自身的等级权重，跳数 = 1。
4. 为每个 inferred_paths 条目评分，但无论数值评分如何，都将其所属分桶限制为 theoretical。推断路径绝不会进入 immediate／short_term／medium_term — RFP §3.3 要求路径必须“已确认”，而推断路径从定义上就缺乏证据。
5. **按得分降序排序。**稳定的平局排序规则：max CVSS 降序 → 跳数升序 → 发现项年龄降序（较新的排在前面）。
6. 归入路线图层级。
   • immediate（0-7 天）：已确认且得分 ≥ 0.6
   • short_term（7-30 天）：已确认且 0.3 ≤ 得分 < 0.6
   • medium_term（30-90 天）：已确认且 0.1 ≤ 得分 < 0.3
   • monitor：已确认且得分 < 0.1
   • theoretical（仅跟踪）：任何 path_class != "confirmed" 的路径。会显示在看板报告中，但不纳入修复 SLA 路线图。
7. 写入输出到 artifacts/attack-paths-ranked.json + attack-paths-ranked.md。每一行都包含 path_class，以便下游使用方筛选。

等级权重

等级	权重
crown_jewel	1.00
revenue	0.70
support	0.40
dev	0.20
unknown	0.30

unknown 的权重刻意设置得高于 support，以促使调查未映射资产 — 这些资产在被发现后往往会被证明属于高等级。

输出

{OUTPUT_DIR}/
  artifacts/
    attack-paths-ranked.json
    attack-paths-ranked.md

attack-paths-ranked.json 架构：

{
  "generated_at": "2026-05-13T03:30:00Z",
  "tier_weights_used": {"crown_jewel": 1.0, "revenue": 0.7, "support": 0.4, "dev": 0.2, "unknown": 0.3},
  "ranked": [
    {
      "rank": 1,
      "kind": "path",
      "path_class": "confirmed",
      "path_id": "asset05->asset42->asset99",
      "hops": ["asset05", "asset42", "asset99"],
      "feasibility": 1.0,
      "max_cvss": 9.8,
      "business_impact": 1.0,
      "entry_exposure": 1.0,
      "score": 0.98,
      "bucket": "immediate",
      "remediation_focus": "asset05"
    },
    {
      "rank": 2,
      "kind": "finding",
      "path_class": "confirmed",
      "finding_id": "finding-018",
      "asset": "asset42",
      "feasibility": 1.0,
      "max_cvss": 9.1,
      "business_impact": 0.7,
      "entry_exposure": 1.0,
      "score": 0.637,
      "bucket": "immediate"
    }
  ],
  "buckets": {"immediate": 4, "short_term": 11, "medium_term": 22, "monitor": 8, "theoretical": 14}
}

修复重点

对于每条已排序路径，选择一个 remediation_focus 资产 — 即修补后能以最低成本打断链条的资产：

• 如果任意边的 feasibility < 1.0 → 将该边的源资产作为重点。最薄弱的跳板是攻击者成本最低的一跳；加固该资产即可消除最容易的入口。
• 如果每条边的 feasibility 都为 1.0（完全确认的链）→ 将路径的入口资产（hops[0]）作为重点。修补外部可达的立足点即可打断所有下游跳转，而且在运营层面，这是修补范围最小的做法。

此规则可为每条路径确定一个唯一的资产 ID。先前的“边贡献公式”已弃用 — 在确认程度一致的链上，每条边的贡献都相同，无法提供有用的信号。

规则

1. 始终以 attack-paths.json 为依据。 不要重新推导可行性 / CVSS——这些已由上游任务验证。
2. business-tier-map.csv 为权威来源。 如果某项资产不在映射表中，则使用 unknown 层级权重，并在 JSON 输出顶部标记 unmapped_assets[]。
3. 输入稳定时，排名也稳定。 对相同输入重复运行，必须生成字节完全相同的输出。
4. 不新增发现项。 优先级排序绝不创建发现项，只会重新排序。
5. 分桶阈值由配置决定。 使用 --thresholds 参数时，可以覆盖 0.6/0.3/0.1 这些分界值，以适应修复周期不同的客户。默认值与 Transilience 报告中的“立即 / 短期 / 中期”标签相匹配。

实现

评分由 tools/risk-prioritise.py 确定性地实现（不委托给 LLM Agent），以满足规则 3（输入稳定时，排名也稳定）。该工具读取 artifacts/attack-paths.json，并写入两个输出文件。使用 --tier-weights / --thresholds JSON 参数覆盖层级权重或分桶阈值——这些参数会记录在输出中，以供审计。

参考资料

• reference/scoring-formula.md — 示例及边界情况行为。
• projects/rfp-3.3/schemas/business-tier-map.csv — 输入架构和示例行。
• tools/risk-prioritise.py — 确定性实现。