“対応必須/要確認/対応不要”
判定ルールの作り方
（例付き：CVEトリアージを迷わせない型）
CVE対応がしんどくなる最大の理由は、脆弱性の数が多いことではありません。
本当に苦しいのは、毎回「どこまでやるべきか」の線引きが人によって変わることです。
- AさんはCVSSが高いから「全部対応必須」と言う
- Bさんは「閉域だから大丈夫」と言う
- Cさんは「まず上流回答待ち」と言って止まる
- 結果として、OEM回答の期限だけが近づき、現場が疲弊する
この状態を止めるには、“対応必須 / 要確認 / 対応不要” の判定ルールを先に決めることが必要です。
ポイントは、完璧なリスク評価を最初からやることではありません。
まずは、誰が見ても同じ方向へ仕分けできる「最低限のルール」を作ることです。
先に結論：判定は「3軸」で決めるとブレにくい
“対応必須 / 要確認 / 対応不要”を決める時、最初は次の3つの判断軸だけで十分です。
1. 対象版数・搭載有無
- そのコンポーネントは入っているか
- どの製品版数に入っているか
- その版数が影響範囲に入るか
2. 到達性・成立条件
- 外部インターフェースがあるか
- 既定状態で有効か
- 実行経路に乗るか
- 権限や設定条件が必要か
3. 優先度を上げる外部条件
- OEM/顧客の期限があるか
- KEVやEPSS等の悪用シグナルが強いか
- 出荷/安全/顧客影響が大きいか
この3軸があれば、かなりの案件を一次分類できます。
判定ルールの基本形
最初に運用へ入れるなら、ルールはこれくらい単純なもので十分です。
対応必須
次のどれかに当てはまる場合です。
- 対象版数に該当し、到達性がある
- 対象版数に該当し、OEM期限や悪用シグナルが強い
- 対策をしないと出荷、運用、安全に影響する
要確認
結論を出すのに必要な情報が足りない場合です。
- 搭載はありそうだが版数が未確定
- 外部インターフェースの有無が未確認
- 成立条件（設定/機能ON/OFF）がまだ確認できていない
- 上流ベンダーや設計部門の回答待ち
対応不要
次のいずれかが根拠付きで言える場合です。
- 非搭載
- 影響対象版数の範囲外
- 到達性が無い
- 実行経路に入らない
- 緩和済みで成立条件を満たさない
ここで大事なのは、「不要」と言う時ほど理由と前提条件を残すことです。
手順：兼務でも回る判定ルールの作り方（5ステップ）
1まず“何を見て判定するか”を固定する
判定ルールは文章で長く書くより、まず入力項目を固定した方が回ります。最低限、「対象製品」「対象版数」「コンポーネント名/版数」「到達性（Yes/No/不明）」「優先度を上げる条件」の5つを見れば十分です。
23軸のうち“不明”を許可する
判定ルールを厳しくしすぎると、全件が止まります。最初は Yes / No / 不明 の3値で良いです。
「不明」があれば「要確認」ステータスにし、ただし更新日を置いて結論を待って沈黙しないこと。これだけで、現場の詰まり方がかなり変わります。
3“対応不要”の理由コードを決める
不要判定は後で揉めやすいので、理由をコード化（固定）すると強くなります。たとえば次のようなコードです。
N2：影響範囲外
N3：到達性なし
N4：実行経路なし
N5：緩和済み
こうしておくと、監査やOEM回答でも「なぜ不要か」をブレずに揃えて書けます。
4判定のたびに“次回更新日”を入れる
「要確認」の案件で一番危険なのは、調査中のまま忘れ去られることです。だから判定ルールの中に、要確認なら次回更新日を必須入力にする 仕組みを組み込みます。
5VEXに変換できる形で残す
この3分類は、実務上は次のようにそのままVEXフォーマットへ寄せられます。
- 対応必須 →
affected - 要確認 →
under_investigation - 対応不要 →
not_affected
つまり、最初からVEXに乗せやすい粒度で判定しておくと、後工程（OEMへの報告やファイル生成）がかなり楽になります。
そのまま使える：判定メモの型
まずはこの形で、案件台帳（Excel）や社内チケットのフォーマットに残すだけでも十分です。
例付き：3つの典型パターン
例1：対応必須
- 製品版数：該当
- Bluetooth経由で到達可能
- 出荷状態で有効
- OEMからの回答期限あり
理由：対象版数該当 ＋ 到達性あり ＋ 期限あり
例2：要確認
- 部品は入っていそう
- ただし顧客別派生で版数が未確定
- 診断機能からの到達性の有無も未確認
理由：版数未確定 ＋ 成立条件未確認
対応：次回更新日を設定
例3：対応不要
- コンポーネントは搭載されている
- ただし対象機能では使われず、実行経路に入らない
- SBOMと設計資料で確認済み
理由コード：N4（実行経路なし）
自社製品の特性に合わせた「トリアージ判定の軸」や「対応不要の理由コード」を整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例
-
NG1：CVSSだけで決める
NVDの点数だけでは、自社製品への搭載有無や到達性が反映されていません。 -
NG2：「閉域だから不要」で終わる
境界、入口、前提条件（どういう設定なら閉域が担保されるか）を書かないと、OEM監査で突っ込まれた時に弱いです。 -
NG3：要確認に更新日が無い
「調査中」のまま放置され、結局期限切れの案件が積み上がっていきます。 -
NG4：不要判定の理由が人によって違う
理由をコード化（固定化）しないと、同じ案件でも説明のニュアンスが担当者ごとにぶれます。
FAQ：判定ルールの運用
A. 最初は十分です。細かくしすぎると運用が止まります。まずはこの3分類で大きく仕分けを回し、必要に応じて「対応必須」の中での優先度（High/Mediumなど）を細かくしていくアプローチが安全です。
A. 「版数確認待ち」「到達性確認待ち」「上流ベンダーの回答待ち」など、不明の理由を分けて記録してください。どこでボールが止まっているか（改善ポイント）が見えやすくなります。
A. 理由と前提条件です。「非搭載」「影響範囲外」「到達性なし」など、何に基づく不要判定か（理由コード）を必ず残してください。これがそのまま監査の防御力になります。
トリアージの判定を、そのままVEXやOEM回答へ。
社内で決めた「対応不要」の理由コードや「調査中」の次回更新日を、いちいちExcelから別システムへ転記していませんか？Auto PSIRT Cloudなら、トリアージの判定結果がそのままVEXデータやOEM提出用の回答書として出力され、業務の手間と転記ミスをゼロにします。