はじめに

Vulnerability Exploitability eXchange (VEX) とは、米国商務省国家電気通信情報庁 (NTIA) によって開発が進められたセキュリティアドバイザリの形式のひとつです。VEX の目的は、ソフトウェア製品の開発者がコンポーネントに存在する脆弱性について、機械処理可能な定型的な形式でユーザに提供することにあります。VEX が提供されるソフトウェア製品を利用することにより、そのソフトウェア製品のユーザは開発者が影響無しと判断した脆弱性を知ることができます。このエントリでは VEX が必要とされる背景や VEX の特徴・利点についてお伝えします。

背景

検出される脆弱性が多い

現在、様々な場面で言及されている Software Bill of Materials (SBOM、ソフトウェア部品表) ですが、SBOM を脆弱性管理に活用した場合、従来の方法と比較して検出される脆弱性は増加することが予想されます。

ソフトウェア製品や OS パッケージを対象とする従来の脆弱性管理は、ソフトウェア製品そのものの脆弱性や OS パッケージに含まれる脆弱性を検出することができました。しかしソフトウェア製品で利用しているサードパーティコンポーネントに含まれる脆弱性については、サードパーティコンポーネントの利用状況自体が明確にされていなかったため、脆弱性の存在を特定することが難しい状況にありました。これに対して SBOM を利用する脆弱性管理では、ソフトウェア製品に含まれるコンポーネントが全て記載された SBOM を用いるため、これらのコンポーネントのリストと脆弱性データベースを突き合わせることで、 理論上はそのソフトウェア製品に含まれる既知の脆弱性を全て検出できることになります。

従来の脆弱性管理であっても脆弱性はそれなりの数が検出され、早急に対処の必要な脆弱性の見極めやパッチ適用にかかるリソースは常に不足気味でしたが、 SBOM を利用するすることで、その傾向は加速することがお分かりいただけるかと思います。

全ての脆弱性が悪用可能とは限らない

ソフトウェア製品に含まれるコンポーネントの脆弱性は、そのソフトウェア製品で必ず悪用可能かと言われれば、そうではありません。 ここでの悪用可能とは、攻撃者によって悪用できる状態を指します。 脆弱性の回避方法が適用されていたり、攻撃者が脆弱性を悪用するためのパラメータを操作できなかったり、そもそも脆弱性の存在するコードを利用していないなど、何らかの理由によって攻撃者がその脆弱性を悪用できない場合は、悪用可能であるとは言えません。

ここで、コンポーネントに含まれる脆弱性が悪用可能であったり悪用不可能であったりする具体的な例を見てみましょう。 まず、コンポーネントAとコンポーネントBを含むソフトウェア製品X (下図、左) があるとします。コンポーネントBに存在する脆弱性は、関数Eを呼び出したときにのみ影響し、関数Fには影響しないことが公表されています。 コンポーネントAのコードは、コンポーネントBの関数Eを呼び出しており、最終的な製品であるソフトウェア製品Xもその脆弱性の影響を受ける、つまり悪用可能な状態であると言えます。 一方、ソフトウェア製品Y (下図、右) は、コンポーネントBを利用していることでは同じですが、脆弱性の影響を受けない関数Fのみを呼び出しているため、脆弱性の影響を受けず、悪用は不可能となっています。

このように、コンポーネントに脆弱性が存在したとしてもその脆弱性が悪用可能であるとは限りません。悪用可能かどうかは実装方法によるところが大きいのですが、ソフトウェア製品の実装方法はそのソフトウェア製品の開発者のみが把握していることが多く、通常、ソフトウェア製品のユーザが悪用可能性を特定することは困難です。

VEX の目的と特徴

目的と利点

VEX の目的は、ソフトウェア製品の開発者がコンポーネントに存在する脆弱性について、機械処理可能な定型的な形式でユーザに提供することにあります。 ソフトウェア製品で VEX が提供されている場合、SBOM を利用して検出される脆弱性について、開発者による影響有無の判断を確認できるようになります。この点を少し詳しくご説明します。

脆弱性データベースの脆弱性情報と SBOM をマッチングさせることでソフトウェア製品に含まれる脆弱性の一覧が出力されますが、この「検出された脆弱性一覧」には悪用が不可能で影響を受けない脆弱性も含まれています。検出された脆弱性一覧に VEX を組み合わせることで、開発者によって確認された実際に影響のある脆弱性の一覧が得られます。

ソフトウェア製品のユーザの立場では、サードパーティコンポーネントに含まれる脆弱性の影響を明確に判断することができるようになります。

一方、ソフトウェア製品の開発者としては、サードパーティコンポーネントにある脆弱性の把握と、その脆弱性によって影響を受けるかどうかの判断が必要となってくることになります。手間がかかるようになりますが、サードパーティコンポーネントに潜む脆弱性の把握は必須事項ともいえます。VEX を用いることで脆弱性に対する影響を定型的に記述し SBOM を用いた脆弱性の検出から除外することが期待できます。

構成要素

VEX ドキュメントの主要構成要素は、製品情報、脆弱性情報、および製品ステータスです。 なおドキュメントのメタデータも含めることが求められていますが、VEX の理解を容易にするため、メタデータなどの要素は下図に含めていません。

各要素の内容は次の表のようになっています。なお内容の説明は米国のサイバーセキュリティ・インフラセキュリティ庁 (CISA) が発行した Minimum Requirements for Vulnerability Exploitability eXchange (VEX) に基づいています。

機械処理可能

公式サイトやメーリングリストなどで公開される脆弱性情報は、記述の形式が統一されていないことが多く、ユーザは基本的に目視で内容を確認しなければなりません。 例えば、Apache Struts 2 は Apache Log4j の CVE-2021-44228 (Log4Shell) の影響を受けることが公表されていますが、その形式はこのようなものでした。

VEX は、機械的に処理できる形式のため、脆弱性の影響を受けるかどうかの判定の自動化や他のシステムとの連携を可能にしています。

実装と公開について

VEX は CSAF のプロファイル の一つとして実装されている他、 CycloneDX でも実装されています。 VEX ドキュメントは、SBOM ドキュメントに埋め込むことも、SBOM ドキュメントとは分離した独立のドキュメントとして SBOM ドキュメントにリンクさせることも可能です。 VEX ドキュメントはソフトウェア製品の提供者によって公開されると想定されていますが、サードパーティが作成することもできます。

まとめ

このように、VEX が提供されるソフトウェア製品を利用することで、そのソフトウェア製品のユーザは開発者が影響無しと判断した脆弱性を知ることができるようになります。 SBOM を効果的に活用する上で役立つアドバイザリ形式だと考えます。

更新履歴

• 2023年05月29日

  • 新規公開

参照

1. "Vulnerability-Exploitability eXchange (VEX) - An Overview," National Telecommunications and Information Administration, Sep 27, 2021.
2. "Framing," NTIA Software Supply Chain Transparency, Jan 13, 2021.
3. "Sharing and Exchanging SBOMs," National Telecommunications and Information Administration, Jul 6, 2020.
4. "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)," Cybersecurity and Infrastructure Security Agency, Apr 21, 2023.
5. 「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理⼿法等検討タスクフォースの検討の⽅向性」, 経済産業省, 2022年11月28日
6. "Vulnerability Exploitability eXchange (VEX)," CycloneDX, (確認日:2023年5月29日)
7. "Common Security Advisory Framework Version 2.0," OASIS OPEN, Nov 18, 2022