部品の一覧から、製品への影響へ進む
あるライブラリの脆弱性が公表され、自社の製品のSBOMにも同じライブラリ名があったとします。これは調査対象を絞る重要な情報です。しかし、名前だけで全製品の悪用可能性や対応方法が決まるわけではありません。版が対象か、問題のコードが含まれるか、製品内でどう使われるかなど、次の確認が必要です。
SBOMの基礎では部品と依存関係の一覧を扱っています。本記事はその後の影響情報をどう読むかに絞ります。脆弱性への影響状態を伝えるVEX（Vulnerability Exploitability eXchange）は、部品一覧を置き換えるものではなく、判断に必要な別の情報を提供します。
SBOMの役割を確認したい方はSBOMの基礎へ、脆弱性の優先順位を決めたい方はCVSS・KEVによるトリアージへ進めます。本記事では、VEXの記述が手元の製品に適用できるかという読み方に絞ります。
SBOM
- どの部品・どの版を含むか
- 部品どうしの依存関係
- 製品と部品を照合する入口
VEX
- 対象製品と特定の脆弱性
- その関係についての状態
- 影響の根拠や対応の説明
部品の一致を見つけた後も、製品・版・条件を合わせて確認します。
OpenVEXの四つの状態を、同じ「安全」にまとめない
OpenVEX仕様では、not_affected、affected、fixed、under_investigationという状態が定義されています。形式によってフィールド名や表現は異なるため、別のVEX形式へ文字列をそのまま当てはめるのでなく、使っている仕様を確認してください。
not_affectedは、その記述が対象とする製品が当該脆弱性の影響を受けないという説明です。fixedは、対象の製品版に修正が含まれるという説明。under_investigationは影響がまだ分からない状態です。調査中を影響なしへ読み替えないことが大切です。
| OpenVEXの状態 | 何を伝えるか | 次に読む情報 |
|---|---|---|
| affected | 対象製品が影響を受ける | 対応・緩和についての説明 |
| not_affected | 対象製品は当該脆弱性の影響を受けない | 理由や影響説明・対象の条件 |
| fixed | 対象の製品版に修正が含まれる | 修正版の識別情報・自社の導入状況 |
| under_investigation | 影響の有無を調査中 | 発行時点・追加情報の予定と確認先 |
自作ケース：同じ部品でも製品版と構成が違う
架空の製品「記録サービスA」の版1.4に、ライブラリQの版2.1が含まれているとします。Qに脆弱性が公表され、SBOMで一致を見つけました。供給者は「記録サービスA・版1.4・構成Sは、問題となるコードを含まないため影響なし」とする説明を出したとします。これは技術を理解するための自作例で、実在のCVEや製品ではありません。
自社の導入物も本当に版1.4・構成Sかを照合します。名前が同じでも、自社で機能を追加した構成Tなら、元の説明がそのまま適用されるとは限りません。また、同じ供給者の別製品Bにも自動で広げられません。まず説明の対象と手元の資産を一致させる必要があります。
ここで供給者が修正版1.5を出してfixedと知らせたとしても、手元の1.4が自動で更新されたわけではありません。修正が提供されたこと、導入を済ませたこと、必要な動作確認を済ませたことは、それぞれ記録で確認します。
- 1
製品を照合
製品識別子と導入資産を合わせる
- 2
版・構成を照合
1.4・構成Sの説明かを確認する
- 3
状態と根拠を読む
影響なしの理由と制約を確認する
- 4
自社の扱いを記録
必要な対応・再確認の条件を残す
対象が合わない説明だけで、調査を完了しません。
構成S/T、版、製品名はすべて学習用の架空例です。
not_affectedには、理由と適用範囲が重要
OpenVEXの仕様では、not_affectedを伝える記述に、理由のラベルまたは影響を受けないことを説明する文を伴わせる要件が説明されています。例えば部品が含まれない、脆弱なコードが含まれない、問題のコードが実行経路にない、といった理由を区別します。形式に適合するだけでなく、その説明が自社の対象と一致するかを確かめます。
「普段使っていない機能だから影響なしだろう」という利用者の推測と、対象範囲を特定した影響説明は同じではありません。機能の有効化や設定変更で前提が変わるなら、再確認が必要です。ここで影響なしとされるのは当該の脆弱性についてであり、製品のほかの脆弱性まで否定する説明ではありません。
VEXを読めば全調査を自動で省ける、と考えるのも避けます。発行元を確認できるか、対象の識別に曖昧さがないか、根拠が自社の構成に当てはまるかという確認が、利用判断に残ります。署名がある場合も、その意味や信頼する発行者の確認は別に必要です。
調査中の記録を残し、更新情報を追う
under_investigationの情報を受け取ったら、何が不明かを記録します。発行日時、対象製品、対象の脆弱性、供給者への確認先、次に情報を確認する予定を残すと、未確認を放置したまま完了扱いするのを防げます。自社で必要な暫定対応は、露出や業務影響、変更のリスクを踏まえて判断します。
古い影響なしの説明が、後から影響ありへ変わることも考えられます。最新の情報と、自社がいつ何を根拠に判断したかを対応させます。製品の版や構成が変わったときも、以前の説明を使い続けてよいか見直します。ファイルを受け取ることだけで、脆弱性管理が完了するわけではありません。
CVSS・KEVとVEXは、違う問いに答える
CVSSは脆弱性の技術的な深刻度を評価する枠組み、KEVは実際に悪用された脆弱性の情報を調べる材料です。VEXは、特定の製品と脆弱性の関係を伝えます。どれか一つで全体の対応順位が決まるのではなく、自社資産と照合した情報を合わせて判断します。
脆弱性対応の優先順位では、技術的な点数・悪用・公開範囲・業務影響を比較します。本記事と合わせると、「点数が高い」「部品がある」「自社で影響が確認された」という別の情報を整理できます。サイバー管理士の準備にはサイバーセキュリティ学習ガイドから関連テーマへ進めます。
復習では、対象がずれた説明を見抜く
「版1.5がfixedだから、現在運用中の版1.4も修正済み」「構成Sがnot_affectedだから、独自に変更した構成Tも影響なし」「under_investigationだから悪用されない」といった説明は、いずれも与えられた情報より強い結論です。版・構成・状態・確認時点のどこが変わったかを一つずつ指摘してみてください。
反対に、SBOMに部品名が載っただけで全製品の停止が必要と決めるのも早計です。対象を識別し、根拠を読み、自社の対応と確認結果を記録する流れが重要です。用語を覚えるだけでなく、状態を更新するために何の情報が足りないかを説明できるようにします。