VEXステータス（not_affected等）を実務で使う書き方
（OEM照会に通る判断の型）
VEXは、脆弱性がその製品の文脈で本当に悪用可能かを伝えるための考え方です。
CycloneDXは、VEXが一般的な脆弱性公開と違って「そのコンポーネントの脆弱性が、実際にその製品で成立するか」に焦点を当てると説明しており、これによって不要な対応を減らし、優先順位付けをしやすくするとしています。
自動車サプライヤー実務では、VEXは「英語の規格用語」ではなく、OEM照会に対して“対応不要／対応必要／調査中”を根拠付きで返すための型です。
ただし、ステータス名だけを並べても意味はありません。重要なのは、対象版数・理由・前提条件・証跡・次回更新日をセットで書くことです。
まず結論：VEXステータスは4つで十分
CISAの VEX minimum requirements では、VEXの基本ステータスは次の4つです。
実務で特に重要なのは、not_affected と under_investigation です。
理由は、サプライヤーが最も困るのが「影響なしをどう説明するか」と「まだ結論が出ないのに期限が来る」だからです。
not_affected の書き方
CISAは、not_affected を使う場合、justification（正当化理由） または impact statement によって、なぜ影響しないのかを説明すべきだとしています。
さらに代表的な justifications として、以下を挙げています。
- Component_not_present
- Vulnerable_code_not_present
- Vulnerable_code_not_in_execute_path
- Vulnerable_code_cannot_be_controlled_by_adversary
- Inline_mitigations_already_exist
サプライヤー実務では、これを日本語で次のように整理すると使いやすいです。
そもそもそのコンポーネントが入っていない。SBOMや構成表で示せる。
同名コンポーネントはあるが、該当コードが無い。バックポートや独自パッチがある場合に多い。
搭載はしているが、その機能を呼ばない。設定無効、別構成、未使用機能など。
外部から届かない、権限条件が厳しい、整備用ツールが必要 など。
設定・運用・アクセス制御で成立しない。ただし「直った」ではないので前提条件を書きます。
not_affected の型
affected の書き方
affected は、「影響あり」と言うだけでは弱いです。
実務では次の3点まで書けると強くなります。
- 対象版数： どこまで影響するかを明示
- 成立条件： 外部IF、認証、権限、設定など
- 次のアクション： 暫定対策、恒久対策、次回更新日
affected の型
under_investigation の書き方
CISAの “When to Issue VEX Information” では、いつVEXを出すかはサプライヤーにとってビジネス判断であり、最初に under_investigation を出して、その後 affected または not_affected に更新する運用が自然だと読めます。
under_investigation で最も重要なのは、次回更新日です。
これが無いと「調査中」ではなく「放置」に見えます。
under_investigation の型
fixed の書き方
fixed はシンプルですが、何で直ったか と どの版で直ったか が必要です。
fixed の型
実務での手順（5ステップ）
ここからは“やり方”です。VEXステータスを実務で使う時は、次の順で進めるとブレにくくなります。
対象版数を切る
まず製品名と製品版数を確定（暫定でも可）します。版数が無いVEXは、ほぼ使えません。
ステータスを4つから選ぶ
not_affected / affected / under_investigation / fixed のどれかに寄せます。曖昧なら under_investigation に置き、更新日を付けます。
理由を1つに寄せる
特に not_affected は、非搭載・到達性なし・影響範囲外など、理由を1つに寄せると説明が強くなります。
証跡を紐づける
SBOM、構成表、設定、試験、チケットの参照先IDを残します。
次回更新日を置く
調査中や暫定対策中の案件は、次回更新日を必ず入れます。
脆弱性トリアージの判断基準を、自社向けに整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（VEXが弱くなる書き方）
- ステータスだけ書いて理由が無い
→ 監査やOEM照会で追加質問が止まりません - not_affected を断定しすぎる
→ 前提条件を書かないと覆りやすい - under_investigation に更新日が無い
→ 放置に見えます - fixed なのにどの版で直ったか書いていない
→ 過去版との切り分けができません
FAQ：VEXの書き方・使い方
はい。実務では特に not_affected、affected、under_investigation が重要ですが、fixed も修正版リリース時には必要です。4つを使い分けることで、状態遷移が明確になります。
いいえ。調査中を素直に表明し、次回更新日を付けるのは健全な運用です。問題なのは、調査中のまま更新日も無く放置することです。
対象版数、理由（非搭載・到達性なし等）、前提条件、証跡をセットで書くのが安全です。justification（根拠）か impact statement（影響声明）が必要というCISAの考え方が参考になります。
VEX（影響判定）の記述も、AIで自動化しませんか？
Auto PSIRT Cloudなら、AIが自社のSBOM情報とCVEを突き合わせ、「影響あり/なし/調査中」の一次判定と、その根拠文（VEX）を自動生成。そのままOEM回答書に出力できます。