CVEトリアージ&VEX実務 完全ガイド:
ノイズ削減・優先度付け・説明責任
自動車サプライヤーにとって、脆弱性対応で本当に難しいのは「CVEを知ること」ではありません。難しいのは、どれが自社製品に影響があるのかを見極め、限られた人員で優先順位を付け、OEMに納得される形で説明することです。
ISO/SAE 21434は車両のE/Eシステムをライフサイクル全体で扱うサイバーセキュリティ標準であり、開発から運用・保守までを対象にしています。つまり、自動車の脆弱性対応は「開発が終わったら終了」ではなく、出荷後まで継続する前提です。
この文脈で必要になるのが、CVEトリアージとVEXです。
- CVEトリアージ:入ってくる脆弱性情報を「対応必須」「要確認」「対応不要」に振り分ける実務。
- VEX:その脆弱性が自社製品の文脈で本当に悪用可能かどうかを機械可読または説明可能な形で示す考え方。
1. なぜCVSSだけで優先順位を決めてはいけないのか
多くの現場では、CVEを見た瞬間にまずCVSSを見ます。もちろんCVSSは重要です。NVDはCVEに対してCVSSなどの分析情報を付与し、CWEやCPEの適用性情報も提供しています。ですが、CVSSが表しているのは脆弱性そのものの深刻度であって、自社で今まさに優先対応すべきかを単独で決める指標ではありません。
ここで補うべきなのが、脅威側の情報です。
- EPSS:FIRSTが提供する指標で、今後30日以内に悪用活動が観測される確率を日次で推定します。FIRSTは「EPSSをリスクスコアとして扱ってはいけない、あくまでリスクの中の『脅威』側の入力だ」と説明しています。つまり、CVSSが高くてもEPSSが低いケースもありますし、逆にCVSSだけでは見落としそうでもEPSSが高いケースがあります。
- KEV:CISAのKnown Exploited Vulnerabilities Catalogは、実際に悪用されたことが確認されているCVEの一覧です。“高そう”ではなく、“もう使われている”という情報が取れるわけです。
結論として、サプライヤーの現場で優先順位を決めるときは、以下のように分けて見るべきです。
- CVSS = 深刻度
- EPSS = 近未来の悪用されやすさ
- KEV = すでに悪用されているか
CVSSだけで見ると、「深刻そうだが実際には自社では到達不能なもの」に引きずられ、逆に本当に急ぐべき案件を埋もれさせます。
2. トリアージの目的は「全部調べること」ではなく「先に切ること」
CVEトリアージの目的は、全アラートを完璧に分析することではありません。目的は、限られた時間で、対応すべきものを先に切り出すことです。
そのためには、最低でも次の3段階に分けるのが現実的です。
- 対応必須:影響があり、かつ悪用可能性も高い。修正・回避策・顧客説明を急ぐべき案件。
- 要確認:コンポーネント一致や周辺条件はあるが、実際の利用状況や到達性を追加確認する必要がある案件。
- 対応不要:自社製品に該当しない、またはVEXの観点で悪用不能と説明できる案件。
CISAのSSVC(Stakeholder-Specific Vulnerability Categorization)の考え方も参考になります。Tier N向けに簡略化するなら、MVPでは次の4軸で十分です。
- 自社製品に入っているか
- 外部から到達できるか
- 悪用状況はどうか(KEV / EPSS / 公開PoC)
- OEMや顧客に説明が必要か
3. トリアージの入口はSBOMと識別子で決まる
トリアージは、そもそも自社に入っているかどうかが分からないと始まりません。そのため、SBOMと識別子の整備は必須です。
CycloneDXは、既知脆弱性の識別に使う標準として、OSSにはPURLを推奨し、政府系や一部商用データベースに載るプロプライエタリ製品にはCPEが適すると説明しています。つまり、OSS中心の世界ではPURLの整備が効きやすく、OEM説明やNVD連携ではCPEの理解も必要になります。
逆に、SBOMの識別子が曖昧だと何が起きるか。
- バージョンが曖昧で全部ヒットする
- 実は別製品なのに誤マッチする
- OEM照会で「うちのどの製品に入っているのか」が説明できない
トリアージ改善は「分析力」だけではなく、SBOMの粒度と識別子整備の問題でもあります。
4. VEXは「対応不要」を雑に言わないための道具
VEXの本質は、「脆弱性がある」ことと「その脆弱性がこの製品で悪用可能である」ことを分ける点にあります。CycloneDXはVEXを、特定の文脈における exploitability(悪用可能性) を伝える仕組みだと説明しています。
CISAのVEX最小要件では、VEXの状態は以下の4つを基本としています。
not_affected(影響なし)affected(影響あり)fixed(修正済み)under_investigation(調査中)
さらに not_affected の場合は、単にそう言うだけでなく、justification(根拠)が必要です。自動車サプライヤーの現場では、次のように翻訳して使うとOEM説明に非常に相性が良いです。
→ そもそもそのライブラリや機能はこの製品に含まれていない
→ 同名コンポーネントはあるが、脆弱な実装部分は含まれていない
→ 脆弱コードは存在しても、この製品構成では呼ばれない(実行経路にない)
→ 攻撃者がそのコード経路を制御できない
→ 設定・制御・入力制限などの緩和策がすでに組み込まれている
この語彙を持っているだけで、「影響なし」の説明がかなり強くなります。OEMが欲しいのは“気合い”ではなく、再現可能な判断理由だからです。
5. サプライヤー向けの現実的なトリアージ手順
Tier2〜Tier4の兼務PSIRTでも回るように、手順を現実的に落とします。
- Step 1:CVEを収集する
最低限、NVDを入口にします。APIを使って日次で取り込むだけでも、手作業より格段に安定します。 - Step 2:SBOMと突合する
PURLまたはCPEで該当候補を絞ります。ここでは「完全一致しないから無関係」と切らず、候補を出すことが重要です。 - Step 3:脅威側で一次優先度を付ける
KEV掲載なら一段階上げる、EPSSが高いなら注視する、など。確率と実績を分けて見ます。 - Step 4:VEX観点で適用性を切る
ここで「affected / not affected / under investigation / fixed」を決めます。 - Step 5:対外説明用に整形する
CVE、対象製品、影響有無、根拠、対応方針、次回報告予定の形に落とします。
6. OEMに通る説明は「結論→根拠→対応方針」の順で書く
トリアージ結果を社内で決めても、OEM説明で崩れることがよくあります。理由は単純で、技術メモの順番で書いてしまうからです。
通りやすい順番は、1. 結論 → 2. 根拠 → 3. 対応方針 です。
影響なしの場合
根拠: 対象コンポーネントは存在するが、脆弱コードは実行経路に含まれない
方針: 現時点で改修不要。今後新情報が出た場合は再評価する
影響ありの場合
根拠: 該当バージョンが搭載され、外部到達性も確認
方針: 暫定緩和策を案内し、恒久対策版を予定日に提供
CISAがVEXを「いつ出すかは事業判断」としているのも重要です。最初から完璧な最終結論を出せない場合は、under_investigation で一度返し、期限付きで更新するのは十分に合理的です。
7. よくある失敗
- CVSS 9以上を全部緊急扱いする:深刻度と優先度を混同すると、現場が疲弊します。EPSSやKEVを併用して脅威側を見ることが必須です。
- SBOMなしでVEXだけやろうとする:何が入っているか分からない状態では説明が弱くなります。VEXはSBOMと切り離せません。
- 「影響なし」の理由を自由記述で毎回書く:人によって文言がぶれて監査証跡になりません。CISAのjustification語彙を社内用語に落として型化すべきです。
- 調査中(under investigation)を禁止する:すぐに結論が出ない案件もあります。「何が不明で、いつまでに確認するか」を出した方が信頼されます。
8. まとめ
CVEトリアージの本質は、すべての脆弱性を深く読むことではありません。自社で今すぐ動くべきものを先に切り出し、対応不要なものは理由付きで外し、判断中のものは期限付きで管理することです。
自動車サプライヤーの現場では、脆弱性管理の勝敗はツール名では決まりません。勝敗を分けるのは、「判断基準があるか」「その基準で証跡を残せるか」「OEMに説明できるか」です。CVEトリアージとVEXは、その3つをまとめて前に進めるための実務です。
毎日のCVEチェック、人力で消耗していませんか?
「NVDを毎日見てExcelと見比べるのが限界」「英語の技術文書が読めない」という方は、まずはオンライン無料相談をご活用ください。
Auto PSIRT Cloudなら、AIが自社製品への影響(VEXの判断根拠)を日本語で自動生成。そのままOEMへの回答書に出力できます。