VEXとは何か：
「対応不要」を言語化するための考え方

VEXが必要になる理由

「CVEが存在する」ことと、「その脆弱性が自社製品で成立する」ことは同じではありません。

CycloneDXも、VEXは特定の文脈で exploitability を伝えるものだと明記しており、これによって組織は remediation の優先順位を付けやすくなり、不要な対応を減らせるとしています。
つまり、VEXが無いと、現場は「全部危険そう」に見える通知に引っ張られ、逆に本当に優先すべき案件を見失いやすくなります。

サプライヤー実務でVEXが特に効くのは、「対応不要（not affected）」を言語化したい時 です。

CISAのVEX minimum requirements では、VEXのステータスとして not_affected / affected / fixed / under_investigation の4つが示されており、特に not_affected では、justification が無い場合は impact statement が必要、justifcation がある場合はそれに基づいて説明すべきと整理されています。
つまり「影響なしです」とだけ返すのではなく、なぜ影響しないのか を構造化して示す必要があります。

VEXの4つの基本ステータス

VEXでまず押さえるべき状態は4つです。CISAの minimum requirements に沿うと、意味は次のように理解できます。

この4つのうち、実務で特に重要なのは not_affected と under_investigation です。

なぜなら、サプライヤーは「すぐには断定できないが、期限は守らなければならない」ケースが多いからです。CISAの “When to Issue VEX Information” でも、最初に under_investigation を出し、調査が終わった時点で affected か not_affected に更新するやり方が一般的だと説明されています。
またVEXは、状況が変わればステータスを更新し、タイムスタンプで現在の状態を再確認できる点も重要です。

「対応不要」をどう言語化するか

CISAの minimum requirements では、not_affected の justification（正当化の理由）として代表的に次のような考え方が示されています。

• Component_not_present そもそもその部品が製品に入っていない
• Vulnerable_code_not_present 同名部品はあるが、脆弱なコード部分が含まれていない
• Vulnerable_code_not_in_execute_path 脆弱コードはあるが、この製品の実行経路（呼び出し）に乗らない
• Vulnerable_code_cannot_be_controlled_by_adversary 攻撃者がそのコードの実行を外部から制御・到達できない
• Inline_mitigations_already_exist 既に緩和策（設定無効化など）が製品に組み込まれている

実務上は、これをそのまま英語で出す必要はありません。むしろ日本語で、「対象版数／前提条件／根拠」をセットにして書く方が通りやすいです。

たとえば、
「対象製品 v2.3.1 は当該ライブラリを搭載していない」
「対象ECUは外部IFを持たず、当該機能は出荷設定で無効」
「成立条件として必要な入力経路が通常運用では存在しない」
といった表現に落とすと、OEM照会でも監査でも説明しやすくなります。

VEXは“文書フォーマット”より“運用の型”

VEXという言葉を聞くと、ファイル形式（JSON等）や標準仕様を先に連想しがちですが、立ち上げ段階で重要なのは フォーマットより運用の型 です。

CISAも、VEXをいつ出すかは多くのサプライヤーにとって business decision だとしており、重要なのは「いつ、誰が、どのステータスで、どの理由を付けるか」を決めておくことだと読めます。

そのため、最初に必要なのは次の3点です。

これだけで、VEXは“運用できる考え方”になります。

よくある誤解

---

FAQ：VEXとは