risk-prioritiser

リスク優先順位付け

攻撃経路グラフとクライアント提供のビジネス階層マップを取り込み、組織が最初に修正すべき経路を順位付けした単一のリストを出力します。cloud-agent のタスク #7 に組み込まれています。

トリガー

attack-path-stitcher（タスク #6）の完了後、毎日 Cron で実行します。また、nvd.score >= 9.0 を満たす新しい validated/*.json が書き込まれたときにも、イベントによって実行されます。

ワークフロー

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 の積です。confirmed paths の場合、常に 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. confirmed path 上にない、アセット単体の検証済み所見をそれぞれスコアリングします。同じ計算式を使用し、feasibility = 1.0、business_impact = アセット自体の階層ウェイト、ホップ数 = 1 とします。
4. 各 inferred_paths エントリをスコアリングしますが、数値スコアにかかわらず、バケットの配置を theoretical に制限します。推論された経路が immediate／short_term／medium_term に到達することはありません。RFP §3.3 では「confirmed」が要件とされており、推論された経路は構造上、証拠が不足しているためです。
5. 降順で並べ替えます。 同点の場合は、max CVSS の降順 → ホップ数の昇順 → 所見の経過時間の降順（新しいものを先）で安定して並べます。
6. ロードマップの階層に分類します。
   • immediate（0～7 日）：confirmed かつスコア ≥ 0.6
   • short_term（7～30 日）：confirmed かつ 0.3 ≤ スコア < 0.6
   • medium_term（30～90 日）：confirmed かつ 0.1 ≤ スコア < 0.3
   • monitor：confirmed かつスコア < 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}
}

修正の重点

順位付けされた各経路について、修正パッチのコストが最も低く、チェーンを断ち切るアセットを 1 つ remediation_focus として選択します。

• いずれかのエッジの feasibility が 1.0 未満の場合 → そのエッジのソースアセットを重点対象にします。最も弱いピボットは攻撃者にとって最も低コストのホップです。ここを強化すれば、最も容易な侵入経路を排除できます。
• すべてのエッジの feasibility が 1.0 の場合（完全に確認されたチェーン）→ 経路のエントリアセット（hops[0]）を重点対象にします。外部から到達可能な足がかりにパッチを適用すれば、下流のすべてのホップを断ち切ることができ、運用上、最も低コストで修正できます。

このルールにより、経路ごとに決定論的なアセット ID が 1 つ得られます。以前の「エッジ寄与度の計算式」は非推奨になりました。均一に確認済みのチェーンでは、すべてのエッジの寄与度が同じになり、有用な判断材料が得られないためです。

ルール

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 レポートの「Immediate／Short-term／Medium-term」のラベルに対応しています。

実装

スコアリングは tools/risk-prioritise.py によって決定論的に実装されています（LLM エージェントには委任されません）。これはルール 3（同じ入力には同じ順位を付ける）を満たすためです。このツールは artifacts/attack-paths.json を読み込み、2 つの出力ファイルを書き込みます。--tier-weights／--thresholds の JSON 引数でティアの重みやバケットのしきい値を変更できます。監査用に、変更内容は出力に記録されます。

参考資料

• reference/scoring-formula.md — 計算例とエッジケースの動作。
• projects/rfp-3.3/schemas/business-tier-map.csv — 入力スキーマと行の例。
• tools/risk-prioritise.py — 決定論的な実装。