SBOMとVEX：コンポーネントと脆弱性の影響
Sytance · 更新日
SBOMは製品に含まれるソフトウェアコンポーネントを特定します。Vulnerability Exploitability eXchange（VEX）は、特定の脆弱性がその製品に影響するかどうかを伝えます。評価は、製品バージョン、その構成、コンポーネントの使用方法によって異なります。
コンポーネントのインベントリ、照合、影響
インベントリには、コンポーネントが存在するかどうかを記録します。脆弱性の照合結果は、アドバイザリーがそのコンポーネントまたはバージョンを示していることを表します。その後の影響分析では、実際の製品ビルドと使用状況において、脆弱なコードが存在し、悪用可能かを確認します。
CycloneDXは、特定の製品に対する評価を伝えるためにVEXを使用します。たとえば、コンポーネントが存在していても、ビルド時に脆弱なオプション機能が除外されていることがあります。この区別を示すには、ビルド情報と分析が必要です。
OpenVEXの4つのステータス
OpenVEXは4つのステータスを定義しています。各ステータスは、ステートメントで特定された製品バージョンと脆弱性に適用されます。
| OpenVEXステータス | 意味 |
|---|---|
| under_investigation | 影響を引き続き評価中 |
| affected | 特定された製品は影響を受ける |
| fixed | 特定されたバージョンには修正が含まれる |
| not_affected | 特定された製品は影響を受けない |
ゲートウェイのオプションデコーダー
オプションのデコーダーを含むパーサーライブラリを搭載した、架空のゲートウェイを考えてみます。ある脆弱性がそのデコーダーに影響するとします。まず、出荷イメージに含まれるライブラリのビルドを特定し、デコーダーがコンパイルされているか確認します。
ビルド設定とバイナリ分析によって脆弱なデコーダーが存在しないと確認できれば、その根拠としてvulnerable_code_not_presentを示すnot_affectedステートメントを裏付けられます。このステートメントが適用されるのは、そのビルドです。
コードが存在するものの実行されるか不明な場合は、エントリーポイントと実行経路を確認している間、評価をunder_investigationのままにしてください。製品が影響を受け、後のリリースに修正が含まれる場合、以前のリリースは引き続き影響を受けます。後のリリースには、別のステートメントを作成します。
not_affectedステータスの根拠
OpenVEXでは、not_affectedステートメントに正当化理由または影響ステートメントを含める必要があります。機械可読な正当化理由によって、コンポーネントの欠落、脆弱なコードの欠落、実行経路外のコード、攻撃者による制御の制限、組み込みの緩和策を区別します。
理由ごとに異なる条件があります。ネットワーク制限を設けても、脆弱なコードがなくなるわけではありません。組み込みの緩和策という理由について、OpenVEXは、悪用を防止し、ユーザーが無効化または再設定できない保護を規定しています。
コードパスに基づいて結論を出す場合は、影響を受ける機能、確認した経路、構成上の制限を特定してください。それらの条件が変わった場合は評価を見直します。顧客が管理する設定に結論が依存するなら、その依存関係を明確に伝えてください。
サプライヤーのVEXステートメントの利用
サプライヤーのVEXステートメントは、アラートの絞り込みや優先度の変更に役立つ場合があります。使用前に、情報源が信頼でき、製品バージョンが一致することを確認してください。公開時刻、改訂履歴、適用構成、推奨される対応も確認します。
信頼できるベンダーの判断と自社分析が一致しない場合は、両方の記録を保持して相違を解消してください。製品ファミリー全体を対象とする包括的なステートメントは、コンポーネントやオプションが異なるカスタムビルドに適用できない場合があります。
VEXステートメントの公開後もSBOMは有用です。新たなアドバイザリーによって調査が必要な事項が変わり、製品の改訂によって以前の結論が無効になる場合があります。インベントリの更新と影響評価は、別々の履歴を保持しながら関連付けてください。