VEX — 「該当する」と「危ない」を分ける | Aid-On

SBOMを出し、脆弱性データベースと突き合わせると、警告が大量に出る。数百件になることも珍しくない。そしてそのほとんどは、実際には影響しない。使っていない関数の脆弱性、到達できない経路の脆弱性、既に別の手当てで塞がっている脆弱性。これを一件ずつ人が調べ直す状態を終わらせるための形式が、VEX(Vulnerability Exploitability eXchange)だ。

「該当する」と「危ない」の隙間#

照合が出すのは、あくまで版の一致だ。手元にlog4j-core 2.14.1が入っていて、その版にCVE-2021-44228が該当する。ここまでは機械が判定できる。

判定できないのはその先になる。その脆弱性のあるコードを、自分は実際に呼んでいるのか。 呼んでいたとして、攻撃者が入力を制御できる経路にあるのか。

答えは製品ごとに違う。同じライブラリを積んでいても、使い方が違えば結論は変わる。だからこの判断は、その製品を作った人にしかできない。

VEXは、その判断を機械可読な形で外に出す仕組みだ。

四つの状態#

VEXの中心は単純だ。ある製品とある脆弱性の組に対して、状態を一つ付ける。

not_affected — 影響しない
affected — 影響する
fixed — 修正済み
under_investigation — 調査中

under_investigationがあるのが実務的だ。公表直後は結論が出ていない。何も言わないより、調べていると言うほうが受け取る側は動きやすい。

そしてnot_affectedと言うときは、理由を添える。ここがVEXの肝になる。

理由を分類する#

「影響しません」だけでは、受け取った側が信じる根拠を持てない。VEXは理由を決められた区分から選ばせる。

component_not_present — その部品自体が入っていない
vulnerable_code_not_present — 部品は入っているが、問題のコードは含まれない
vulnerable_code_not_in_execute_path — 含まれるが、実行経路に乗らない
vulnerable_code_cannot_be_controlled_by_adversary — 経路に乗るが、攻撃者が制御できない
inline_mitigations_already_exist — 既に別の手当てで塞いである

区分になっていることに意味がある。自由記述だと読み手が毎回解釈することになるが、決まった値なら機械が処理できる。「影響しない」と主張する製品を、理由の種類ごとに絞り込める。

inline_mitigations_already_existだけは注意がいる。手当てが外れれば影響するようになるので、その手当て自体を管理下に置いておく必要がある。

三つの書き方#

形式は一つに定まっていない。用途の違う三つが並立している。

CSAFはOASISの標準で、そのなかにVEXのプロファイルがある。もともとはベンダーがセキュリティ勧告を配るための形式で、VEXはその一部として位置づけられる。重厚なぶん、表現力がある。

OpenVEXはOpenSSFの仕様で、必要最小限に絞ってある。一つの文書に一つの主張、という単純さを保っている。生成も解釈も軽い。

CycloneDXはSBOMの形式そのものにVEXを持てる。部品表と影響有無を同じ文書に置けるので、扱いが一体になる。

どれを選ぶかは、誰に渡すかで決まる。既にCSAFで勧告を配っているならCSAF、SBOMと一緒に配るならCycloneDX、自動化の部品として軽く扱いたいならOpenVEXが向く。

実際の中身#

OpenVEXの文書は、驚くほど短い。一つの主張は、対象と脆弱性と状態と理由だけで書ける。

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "author": "Example Corp",
  "timestamp": "2026-09-06T09:00:00Z",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [{ "@id": "pkg:maven/com.example/app@1.4.0" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

製品の指定にpurlを使っているのが要点だ。SBOMと同じ識別子なので、部品表とVEXが同じ名前で突き合わさる。ここが揃っていないと、人手で対応表を作る羽目になる。

timestampも効く。いつ時点の判断かが分かるので、その後に状況が変わったかを追える。

誰が書き、誰が読むか#

VEXは、上流から下流へ流れる。

製品を作った側が書く。ライブラリの作者、アプリケーションの開発会社、機器のベンダー。自分の製品について、その脆弱性が効くかどうかを宣言する。

受け取った側が読む。照合で出た警告に対して、供給元のVEXがあれば「調べ済み」として扱える。なければ自分で調べる。

この流れが成立すると、同じ調査が組織の数だけ繰り返されなくなる。 一社が一度判断すれば、下流の全員がその結果を使える。VEXが解こうとしているのは、技術の問題ではなく、この重複の問題だ。

警告が減るとは限らない#

VEXを導入する動機は「警告を減らしたい」であることが多い。ただ、減り方には偏りがある。

減るのは、供給元が整備している範囲だけだ。 大手のベンダー製品やよく使われるOSSは、VEXが出てくる可能性がある。小さな依存や社内製のものは出てこない。

そして依存の数でいえば、後者のほうが圧倒的に多い。全体の警告数が劇的に減る、という期待は外れる。

効くのはむしろ質のほうになる。手を付けるべきものが、手を付けなくていいものに埋もれなくなる。 数が減らなくても、順序が付けば動ける。

自社が供給する側なら、話は逆になる。VEXを出すことで、顧客からの問い合わせが減る。「御社の製品にこの脆弱性は影響しますか」という質問に、毎回個別に答えなくてよくなる。

過信しないための注意#

VEXは主張であって、証明ではない。 書いたのは供給元で、その内容を第三者が検証しているわけではない。誰の主張かを見て、信用の度合いを決める必要がある。

古くなる。 製品の版が変われば、実行経路も変わる。以前not_affectedだったものが、次の版では該当することがある。VEXは製品の版に紐づくものとして扱う。

ないことは、安全を意味しない。 供給元がVEXを出していないのは、影響しないからではなく、単に出していないからだ。空白をnot_affectedと読み替えてはいけない。

全件は出てこない。 現実には、VEXを整備しているのは一部の供給元に限られる。届かない分は、結局こちらで判断することになる。

状態の意味を取り違えない。 fixedは修正済みの版があるという意味であって、こちらが更新したという意味ではない。更新して初めて、自分にとっての解決になる。

どこから手を付けるか#

自社で扱うなら、受け取る側と出す側で始め方が違う。

受け取る側は、まず供給元がVEXを出しているかを確かめるところから始まる。出ていれば取り込み、出ていなければ従来どおり自分で判断する。取り込みに対応した照合ツールも増えてきた。

出す側は、全部を書こうとしないほうがいい。現実的なのは、問い合わせが多い脆弱性から順に書くやり方になる。同じ質問が三度来たなら、それは書くべき一件だ。

書式は最初から凝らなくていい。OpenVEXなら数行で始められるので、運用に乗せてから形式を検討しても遅くない。続かない仕組みを作るより、粗くても回るほうが価値が出る。

まとめ#

SBOMが「何を持っているか」、脆弱性データベースが「何が壊れているか」、VEXが「それは自分に効くか」。三つで一組になる。

前の二つは機械が処理できるが、三つ目だけは人の判断が要る。VEXがやったのは判断の自動化ではない。人が下した判断を、機械が運べる形に変えたことのほうだ。

判断そのものは減らない。同じ判断を何度も繰り返すことが減る。警告の数が増え続ける以上、効いてくるのはこちらの効率になる。

VEX — 「該当する」と「危ない」を分ける