影響評価のやり方
（脅威・ECU・ソフト改変の切り分け）
OEMからの調査依頼（CVE影響有無）で詰まるのは、技術そのものより 「影響評価の切り分けができていない」 ことです。
よくある“事故パターン”はこの3つ。
- 脅威（攻撃シナリオ）が曖昧で、「結局どこから攻撃される想定？」と聞き返される
- ECUが特定できず、「どのユニットが影響？」で追加質問が止まらない
- ソフト改変（版数・パッチ）が曖昧で、「どの製品版まで影響？」を確定できない
結論、影響評価は 脅威・ECU・ソフト改変を分けて考えると、OEMが納得する形に落としやすくなります。ここでは兼務でも回る“型”として手順化します。
先に結論：影響評価は「3つの切り分け」で8割決まる
影響評価の答え（affected / not_affected / 調査中）を作る前に、まずこの3点を分離して整理します。
ソフト改変の切り分け
＝どの版が対象か
SBOM/構成表で「対象製品×対象版数×搭載コンポーネント版数」を確定する
ECUの切り分け
＝どこに入っているか
対象コンポーネントが “どのECU/どの機能ブロック” に載っているかを特定する
脅威の切り分け
＝攻撃が成立するか
到達性（入口）・前提条件（権限/設定/機能ON/OFF）を明確化する
この順番で整理すると、結論がブレません。
手順：影響評価を“回答できる形”に落とす（5ステップ）
案件化（SLAと更新日を先に置く）
期限がある/ないに関わらず、まずチケット化します。
- 受付日 ／ 通知元（OEM・NVD・取引先等）
- 相手期限（あれば）
- 一次回答期限（自社SLA）
- 次回更新日（調査中でも必須）
- 証跡（通知原本、メール、文書ID）
影響評価で一番まずいのは「沈黙→期限超過」です。
結論が出なくても、更新日を宣言できれば運用は崩れません。
ソフト改変の切り分け（対象版数を“暫定→確定”する）
影響評価の土台は「どの版が対象か」です。ここが弱いと必ず追加質問が来ます。
- 対象コンポーネント（OSS/商用/自社）名と“影響版範囲”を把握
- SBOM/構成表（Excelでも可）で 搭載の有無を確認
- 製品版数ごとに「搭載コンポーネント版数」を確定
- バックポート/独自パッチがある場合は、“上流版数”だけで断定しない（根拠を残す）
対象製品：A / B
対象製品版数：v1.2.0〜v1.3.5（暫定→確定）
根拠：SBOM行ID、ビルド記録、構成表ID
ECUの切り分け（「どのECUのどの機能か」を言えるように）
同じコンポーネントでも、載っているECUが違えば到達性も影響も変わります。
- 搭載ECU（またはモジュール/機能ブロック）を特定
- そのECUの外部IF（通信、診断、更新、クラウド連携など）を列挙
- 影響範囲（対象車種/顧客/構成）を暫定で切る
ECU：ゲートウェイECU／IVI／メータ 等
搭載箇所：通信スタック／更新モジュール 等
影響範囲：全車種/特定顧客/特定構成（暫定でも可）
脅威の切り分け（到達性と前提条件を“言葉”で固定）
ここはCVSSの点数より、成立条件（攻撃が届くか） を明文化する方が効きます。
チェックするのは次の3つだけでOKです。
- 入口（到達性）： 外部IFから当該機能に到達できるか
- 前提条件： 特権が必要か／機能が有効か／特定設定が必要か
- 成立した場合の影響： 安全・出荷・機能停止・データなど（範囲はECU切り分けと連動）
脅威シナリオ：外部IF○○経由で当該機能に到達し得る／到達しない
前提条件：機能がON、特定設定、認証要否 等
結論（VEX）に落とす
上の3つが埋まると、結論はほぼ機械的に決まります。
- not_affected： 非搭載、または到達性なし（前提条件を明記）
- affected： 搭載 ＋ 到達性あり（暫定対策/恒久対策と更新日へ）
- under_investigation（調査中）： 搭載/到達性/版数が未確定（次回更新日必須）
OEM回答の“型”に整形する（追加質問を減らす）
OEMが欲しいのは、結論＋根拠＋次のアクションです。最低限、これだけ書けば通りやすいです。
- 結論（affected / not_affected / 調査中）
- 対象製品・対象版数（暫定/確定を明記）
- ECU/搭載箇所
- 脅威シナリオ（到達性）と前提条件
- 次回更新日（SLA）
- 証跡参照先（SBOM/構成/チケットID）
今の運用で「脆弱性の影響判定・対応」がスムーズにできるか整理しましょう。まずはご相談ください。
【無料】オンライン相談を予約する影響評価でよくある落とし穴（これだけ避ける）
- ECUが書けない： 影響範囲が曖昧になり、監査・照会で必ず詰む
- 対象版数が書けない： 一番手戻りが大きい（毎回聞かれる）
- 影響なしを断定しすぎる： 前提条件（機能無効、外部IFなし等）がないと設定変更等で覆る
- 調査中に更新日がない： 単なる放置に見える（SLA評価が落ちる）
FAQ：影響評価のやり方について
トリアージは「優先度と次アクションの仕分け」、影響評価は「対象版数・ECU・到達性を整理して結論（VEX）を作る」作業です。影響評価は“脅威・ECU・ソフト改変”の切り分けが鍵になります。
まずは“暫定”で構いません。搭載箇所（モジュール名）まででも良いので書き、次回更新日に「ECU確定」を置きます。沈黙しないことが最優先です。
上流版数だけで断定せず、構成表・ビルド記録・差分チケットなどの根拠を残します。「上流は脆弱だが当社は対策済み」の主張は、証跡がないと崩れます。
「非搭載」または「到達性なし」のどちらかに寄せ、前提条件（外部IFなし、機能無効など）と証跡参照先をセットで書くのがコツです。
攻撃手順の詳細は不要なことが多いです。代わりに、対象版数・ECU・到達性（入口と前提）・次回更新日・証跡参照先を短く整理すると通りやすくなります。
影響評価から回答書作成まで、AIで自動化しませんか？
Auto PSIRT Cloudなら、自社のSBOMデータとCVE情報を突合し、AIが到達性や影響範囲を推測。OEMへの提出用レポート（結論・根拠・次回更新日）までを自動で生成します。