VEX：Vulnerability Exploitability eXchangeドキュメントが伝えること

VEXとは

VEX（Vulnerability Exploitability eXchangeの略）は、製品が特定の既知の脆弱性の影響を受けるかどうかを示す機械可読なステートメントです。サプライヤーがこれを公開することで、製品の利用者は対応が必要な脆弱性とそうでない脆弱性を把握できます。多くの組織では、このサプライヤー側の作業は製品セキュリティインシデント対応チーム（PSIRT）が担います。

CISAのMinimum Requirements for VEX（2023年4月）は、VEXを特定のファイル形式から独立して定義しています。VEXドキュメントは1つ以上のVEXステートメントを格納するコンテナであり、各ステートメントは1つ以上の製品における1つの脆弱性について、1つのステータスを示します。VEXはSBOM、脆弱性データベース、セキュリティアドバイザリと組み合わせて使うよう設計されていますが、そのいずれも必須ではありません。

VEXが必要な理由：SBOMのノイズ

SBOMには、推移的依存関係を含め、製品内のすべてのコンポーネントが記載されます。スキャナーはそれらのコンポーネントをアドバイザリと照合し、見つかったすべてのバージョンのすべてのCVEを報告します。しかし、その検出結果の多くは該当しません。脆弱な関数が一度も呼び出されない、ビルドオプションによってコンパイル時に除外される、あるいは製品の構成が攻撃を防いでいる、といった場合です。VEXがなければ、顧客はそれぞれ独自にこれを判断するか、サプライヤーにサポートチケットで問い合わせるしかありません。

VEXは、その分析を全員のために一度で行える立場にある当事者、つまりサプライヤーに移します。顧客のスキャナーはVEXドキュメントを読み込み、サプライヤーが製品に影響しないとした検出結果を抑制します。

VEXは、いくつかある手段の1つです。脆弱性ノイズを減らす方法では、出荷物と一致するインベントリから始めて、それらを順に整理しています。

VEXの4つのステータス

すべてのVEXステートメントは、次の4つのステータスのいずれか1つを持ちます。

ステータス	意味	あわせて必要なもの
not_affected	修正も緩和策も不要です。脆弱性は記載された製品に影響しません。	根拠（justification）、または理由を説明する影響ステートメント
affected	脆弱性は記載された製品に影響し、作成者は対応を推奨しています。	アクションステートメント：利用者が取るべき対応
fixed	記載された製品バージョンには修正が含まれています。	追加の要件なし
under_investigation	作成者が調査中で、まだ判断していません。	追加の要件なし。変更されることが前提

not_affectedの根拠（justification）

not_affectedステートメントには理由が必要です。CISAの要件では、5つの根拠のいずれかを使用すべき（SHOULD）とされ、使用しない場合は自由記述の影響ステートメントを記載しなければなりません（MUST）。OpenVEXとCSAFも同じ5つを使用します。

• component_not_present：脆弱なコンポーネントが製品に含まれていない。
• vulnerable_code_not_present：コンポーネントは含まれているが、脆弱なコードは含まれていない。通常は、構成やビルド方法によるものです。
• vulnerable_code_not_in_execute_path：脆弱なコードは存在するが、製品がそれを呼び出すことはない。
• vulnerable_code_cannot_be_controlled_by_adversary：コードは存在し使用されているが、攻撃者がそれを制御して脆弱性を悪用することはできない。
• inline_mitigations_already_exist：利用者が無効化できない組み込みの保護機能が悪用を防いでいる。

根拠によって必要なエビデンスは異なります。component_not_presentには、製品に含まれるものの正確な記録が必要です。中間の3つは到達可能性分析や手動レビューなどのコード分析を必要とし、顧客から最も疑問を持たれやすい根拠です。

VEXステートメントの構成要素

CISAの最小要件には、次の要素が挙げられています。

• ドキュメントのメタデータ：ドキュメントID、変更のたびに増えるバージョン、作成者（ツールではなく個人または組織）、初回発行日時と最終更新日時。
• 製品の詳細：1つ以上の製品識別子。理想的には、パッケージURL（purl）など、製品のSBOMと同じ識別子を使用します。ステートメントでは、脆弱性を含むサブコンポーネントを指定することもできます。
• 脆弱性の詳細：ステートメントごとに1つの脆弱性ID（通常はCVE）と、その説明または説明へのリンク。
• ステータスと、それに必要な根拠、影響ステートメント、アクションステートメント。
• ステートメントのメタデータ：ステートメント自体のID、バージョン、タイムスタンプ。

VEXドキュメントの例

次のOpenVEXドキュメントは、製品example-api 3.2.0が脆弱なバージョンのlog4j-coreを含んでいるものの、脆弱なクラスがビルド時に削除されるため、Log4Shellの影響は受けないことを示しています。

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

製品とそのサブコンポーネントはパッケージURLで識別されるため、スキャナーはそれらを製品のSBOM内のコンポーネントと照合できます。 CycloneDXやCSAFで同じステートメントを記述しても、構造は異なりますが同じ事実が伝えられます。

VEXの形式：OpenVEX、CycloneDX VEX、CSAF VEX

VEXは要件の集合であり、ファイル形式ではありません。CISAはVEXを記述できる3つの形式を挙げていますが、それらに互換性はありません。

	OpenVEX	CycloneDX VEX	CSAF VEX
概要	VEX専用の小さなJSON形式	CycloneDXドキュメントのvulnerabilitiesセクション	CSAFアドバイザリ標準のcsaf_vexプロファイル
標準	オープン仕様、v0.2.0	ECMA-424（CycloneDX 1.6以降）	OASIS Standard（CSAF 2.0、2022年）
ステータス	VEXの4つのステータス	独自の分析状態：not_affected、exploitable、in_triage、resolved、resolved_with_pedigree、false_positive	製品ステータスのリスト：known_not_affected、known_affected、fixed、under_investigation
根拠	CISAの5つの根拠	code_not_reachableやrequires_configurationなど独自の9種類	CISAの5つの根拠（フラグとして）
適したチーム	できるだけ小さなVEXファイルを求めるチーム	すでにCycloneDXのSBOMを出荷しているチーム	すでにCSAFセキュリティアドバイザリを公開しているチーム
Trivyでの読み込み	対応	対応（SBOMスキャン時）	対応
Grypeでの読み込み	対応	記載なし	対応

OpenVEXは最も軽量で、作成者、タイムスタンプ、バージョン、ステートメントのリストからなるドキュメントです。その仕様は、 VEXをステートメントの連続として扱い、各ステートメントが以前のものを上書きまたは補足します。

CycloneDX VEXは、CycloneDXがほかのすべてに使用するのと同じvulnerabilities構造を使用し、analysisオブジェクトに状態、根拠、updateやwill_not_fixなどのレスポンス値、自由記述の詳細を保持します。VEXデータはSBOM内に置くことも、BOM-LinkでSBOMを参照する別のCycloneDXドキュメントに置くこともできます。ただし、根拠の語彙はCISAのものとは異なるため、OpenVEXやCSAFとの相互変換にはマッピングが必要です。 SBOM側についてはCycloneDXとSPDXの比較をご覧ください。

CSAF VEXは、カテゴリがcsaf_vexの完全なCSAFドキュメントです。製品ツリー、CVEまたはその他のID、注記、そして製品ごとに影響ステートメント（影響を受けない場合）または修正方法（影響を受ける場合）が必要です。OpenVEXより重い形式ですが、すでにCSAFプロバイダーを通じてCSAFアドバイザリを配信している組織に適しています。

VEXとVDRの違い

脆弱性開示レポート（VDR）は、製品に実際に影響する脆弱性を、その分析と修正方法とともに記載します。NIST SP 800-161はサプライチェーンのプラクティスとしてVDRを推奨しており、CycloneDXは両方に対応しています。CycloneDXのサンプルの説明によると、違いは次のとおりです。

• VDRは、どの脆弱性が製品に影響するかを示します。自社コードで見つかり、他の場所で公開されたことのない脆弱性も対象にできます。
• VEXは主に否定のステートメントです。どの既知の脆弱性が製品に影響しないか、そしてその理由を示します。対象は既知の脆弱性のみです。

多くのサプライヤーは両方を公開しています。VDRは「何を修正する必要があるか」に、VEXは「何を無視してよいか」に答えます。

スキャナーによるVEXの活用

VEXドキュメントが作業を減らすのは、顧客のツールがそれを読み込む場合だけです。広く使われている2つのオープンソーススキャナーが対応しています。

• Trivyは--vexオプション（実験的機能）を通じて、ローカルファイル、VEXリポジトリ、OCIアテステーション、またはSBOM内の参照からVEXを取り込みます。 OpenVEX、SBOMスキャン時のCycloneDX VEX、CSAF VEXを読み込み、not_affectedとされた脆弱性を報告しなくなります。
• Grypeは--vexを通じてOpenVEXとCSAF VEXを取り込みます。not_affectedとfixedの一致は無視リストに移され、--show-suppressedで表示できます。オプションでaffectedとunder_investigationのステートメントを結果に追加することもできます。

照合は識別子に依存します。VEXがSBOMとは異なる識別子で製品を指定している場合、スキャナーは両者を結び付けられず、検出結果は残ります。

VEXを公開するのは誰か

VEXは通常、サプライヤー、つまり製品を出荷するベンダー、オープンソースディストリビューション、デバイスメーカーから提供されます。サプライヤー内部ではPSIRTのタスクであり、アドバイザリや修正を生み出すのと同じ脆弱性管理ライフサイクルの一部です。たとえばRed Hatは、 CSAFフィードの専用ディレクトリで、アドバイザリと並べてCSAF VEXドキュメントを公開しています。PSIRTエンジニアの日々の業務については、PSIRTの役割をご覧ください。

顧客も自らの用途でVEXを作成し、サプライヤーの製品に関するトリアージの判断を記録して、スキャナーが同じ指摘を繰り返さないようにします。 EUのCyber Resilience Actなどの規制は、出荷するコンポーネントの脆弱性に対処することをメーカーに求めており、 VEXはそのうちどれが該当するかを利用者に伝える手段の1つです。

VEXを最新に保つ

• ステータスは変わります。ステートメントは通常under_investigationから始まり、not_affectedになるか、affectedを経てfixedになります。変更のたびに公開してください。 CISAは毎回バージョンを上げることを求めています。
• 新しいリリースには新しいステートメントが必要です。3.2.0に対するnot_affectedの判断は、 3.3.0については何も示しません。コンポーネント、そのバージョン、ビルド構成が変わるたびに再確認してください。
• VEXはSBOMと分けて管理します。SBOMはリリースを記述するもので、変わりません。VEXはリリース後も変わり続けるため、独立したドキュメントとして公開すればSBOMを再発行せずに済みます。
• ツールが参照する場所に公開します。SBOMの隣、コンテナイメージのアテステーション、アドバイザリフィードなどに公開し、その場所を開示ポリシーに明記してください。協調的脆弱性開示もご覧ください。

VEXの限界

• 主張であって証明ではありません。not_affectedステートメントは作成者による評価です。CISAは作成者の身元をドキュメントに暗号的に結び付けることを推奨していますが、多くの利用者は依然として、サプライヤーを信頼しているからVEXを信頼しています。
• 記載がないことに意味はありません。VEXにはデフォルトのステータスはありません。ステートメントのない脆弱性は、影響なしではなく不明です。
• 形式間は1対1で対応しません。CycloneDXはOpenVEXやCSAFとは異なる状態と根拠を使用するため、変換すると詳細が失われます。
• 品質はインベントリ次第です。コンポーネントが含まれていないと言うには、推移的依存関係や、ビルドがパッケージマネージャー以外でダウンロードしたものも含め、製品の中身を正確に把握している必要があります。

VEXは正確なSBOMから始まる

すべてのVEXステートメントはコンポーネントを指しており、最も主張を裏付けやすい根拠であるcomponent_not_presentは、インベントリが完全である場合にのみ成り立ちます。事後にロックファイルをスキャンして生成したSBOMには、出荷されない開発用の依存関係が含まれたり、ビルドが別の方法で取得したパッケージが漏れたりすることがあります。

CRACIはGitHub Actionsのビルドを自社のランナーで実行し、推移的依存関係、キャッシュから復元されたパッケージ、どのロックファイルにも載らない依存関係を含め、各ジョブが実際に取得したパッケージを記録します。各SBOMには完全性の状態が付き、 CycloneDXまたはSPDXでエクスポートできます。監視対象のSBOMは継続的に再評価され、ビルド履歴から脆弱な依存関係を含んでいた過去のビルドがわかります。 CRACIはVEXにも対応しています。SBOM生成と脆弱性トラッキングをご覧ください。

VEXに関するよくあるご質問

VEXは何の略ですか？

VEXはVulnerability Exploitability eXchangeの略です。製品が特定の既知の脆弱性の影響を受けるかどうかを示す機械可読なステートメントで、報告された脆弱性のうちどれに対応が必要かを利用者が把握できるよう公開されます。

SBOMとVEXの違いは何ですか？

SBOMは製品に含まれるコンポーネントを列挙します。VEXは、ある脆弱性についてその製品が影響を受けるかどうかを示します。SBOMはリリース後にほとんど変わりませんが、VEXステートメントはサプライヤーの調査や修正に応じて変わります。そのため、VEXは通常、SBOMに組み込むのではなく、製品を参照する別のドキュメントとして公開されます。

VEXの4つのステータスとは何ですか？

not_affected、affected、fixed、under_investigationの4つです。not_affectedステートメントには根拠または影響ステートメントが必要で、affectedステートメントには利用者が取るべき対応を示すアクションステートメントが必要です。

どのVEX形式を使うべきですか？

利用者とそのツールが読み込める形式を使用してください。OpenVEXは最も小さく、TrivyとGrypeで使えます。CycloneDX VEXは、すでにCycloneDXのSBOMを出荷しているチームに適しています。CSAF VEXは、すでにCSAFセキュリティアドバイザリを公開している組織に適しており、産業用ソフトウェアやエンタープライズソフトウェアでは一般的です。多くのサプライヤーは、最終的に形式間で変換しています。

VEXはセキュリティアドバイザリと同じですか？

いいえ。セキュリティアドバイザリは、脆弱性の内容、影響を受ける対象、修正方法を主に人に向けて説明するものです。VEXは、製品と脆弱性ごとの限定的な機械可読のステータスで、主にツール向けです。両者はしばしばセットで扱われます。CSAF標準には、セキュリティアドバイザリのプロファイルとVEXのプロファイルの両方があります。

VEXドキュメントは誰が作成しますか？

通常は製品のサプライヤーで、多くの場合はその製品セキュリティインシデント対応チーム（PSIRT）です。製品のビルド方法や構成を把握しているためです。CISAの最小要件では第三者がVEXを作成することも認められており、すべてのドキュメントに作成者を明記する必要があります。

脆弱性スキャナーはVEXを読み込みますか？

いくつかのスキャナーが対応しています。Trivyは--vexオプションでOpenVEX、CycloneDX、CSAF VEXを受け付け、not_affectedとされた検出結果を除外します。Grypeは--vexでOpenVEXとCSAF VEXを受け付け、not_affectedとfixedの検出結果を無視リストに移します。