SBOM とVDR、VEX について

開発者やセキュリティエンジニアの間では SBOM の話題がもう当たり前となっている昨今ですが、さらに脆弱性情報を記載する「VDR」「VEX」に関しての話も少しずつ出てきています。ここでは SBOM と VDR／VEX の関係性について説明していきます。

VDR とは

VDR の定義

VDR(Vulnerability Disclosure Report：脆弱性開示レポート ) とは、製品やその依存関係に影響を与えるすべての脆弱性を記述し、その影響を分析したレポートになります。VDR の定義ですが、2022 年 5 月に発行された ;

NIST SP 800-161 Rev. 1「Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations（システムと組織のサイバーセキュリティサプライチェーンのリスク管理実践：組織のあらゆるレベルのサプライチェーン全体にわたるサイバーセキュリティリスクを特定／評価／軽減するためのガイダンス）」

の中では以下のように定義されています。

「企業は、該当する場合および適切な場合、SBOM にリストされているコンポーネントの適切かつ完全な脆弱性評価を実証するために、顧客に Vulnerability Disclosure Report( 脆弱性開示レポート :VDR) を提供することを検討できます。
VDR には、報告された脆弱性がコンポーネントまたは製品に与える影響を説明する調査結果と分析を含める必要があります。
VDR には、CVE に対処する計画に関する情報も含まれている必要があります。
企業は、顧客が利用できる安全なポータル内で VDR を公開し、VDR 署名と関連する VDR の日時を示すタイムスタンプを含む、信頼できる検証可能な秘密キーを使用して VDR に署名することを検討する必要があります。」

つまり、VDR は下記の様になっている必要があります。

製品や依存関係に影響を与える全ての脆弱性を含む
報告された脆弱性がコンポーネントまたは製品に与える影響の分析結果を含む
CVE に対処する計画に関する情報を含む
VDR 署名と関連する VDR の日時を示すタイムスタンプを含んだ信頼できる検証可能な秘密キーを使用して VDR に署名されている

VDR のサンプル

VDR のサンプルは公式のものが無い状態なため難しいですが、「Reliable Energy Analytics LLC」が出しているものが標準に則っていてわかりやすいと思われます。

こちらの GitHub でサンプルが公開されています。例えば

log4j のユースケース（Log4j_2-17-0-CORE-VulnerabilityDisclosureReport.xml）
製品に脆弱性が含まれていない場合のユースケース（whois_vdr.json）
等です。

この中で、「製品に脆弱性が含まれていない場合のユースケース」に関しては、報告する脆弱性がないため、VEX ではこのタイプのレポートは不可能です。この辺りが VDR と VEX との違いとなっています。

また、VDR は SBOM を必要としませんが、存在する場合はそれを補完できる様なものになっています。

VEX とは

VEX の定義

VEX(Vulnerability-Exploitability eXchange) は、米国電気通信情報局 (NTIA) で開発されたものになります。2022 年 4 月に CISA が発行した「Vulnerability Exploitability eXchange (VEX)-Use Case(PDF)」では、以下のように述べています。

「VEX はセキュリティ勧告の一種で、現在成熟した製品セキュリティチームによってすでに発行されているものと同様です。VEX モデルには、「従来の」セキュリティ勧告に比べていくつかの重要な改善点があります。まず、VEX ドキュメントは機械読み取り可能であり、既存および新規のセキュリティ管理ツールや、より広範な脆弱性追跡プラットフォームへの統合をサポートするように構築されています。第 2 に、VEX データはソフトウェア部品表 (SBOM) データのより効果的な使用をサポートできます。このドキュメントの最終的な目標は、開示、脆弱性の追跡、修復を含む、脆弱性エコシステム全体の自動化の強化をサポートすることです。」

つまり、VEX は以下のようなものになります。

セキュリティ勧告の一種
機械読み取り可能で、セキュリティ管理ツールや脆弱性追跡プラットフォームから使えるフォーマット
SBOM と一緒に用いられる

VEX は、Common Security Advisory Framework (CSAF) のプロファイルとして実装されています。CSAF は、OASIS Open CSAF Technical Committee によって開発された機械読み取り可能なセキュリティアドバイザリ標準です。

VEX の使用例

VEX はユーザ ( オペレーター／開発者／サービスプロバイダーなど ) に下記の様な追加情報を提供します。

製品に含まれたコンポーネントで発見された、コンポーネントに特定される脆弱性の影響を、製品が受けるかどうか
製品が影響を受ける場合には、修復が推奨されるアクションがあるかどうか

これはコンポーネントの脆弱性が、コンポーネント自体は脆弱性の影響を受けるとしても、下記のような理由で最終的に製品としては「悪用可能」で無いことが有るために、大事なものになります。

影響を受けるコードがコンパイラによってロードされない
ソフトウェアの他の場所で保護が存在する

VEX 上で表される「ステータス」

VEX では、前述の「コンポーネントの脆弱性による影響を製品がどう受けるのか」に関して、ステータスを下記のように分類しています。このステータスを含めた情報を、製品開発者がユーザに提供するような形になります。

Not affected
この脆弱性に関して修正は必要ありません。
Affected
この脆弱性を修正または対処するために何らかのアクションが推奨されます。
Fixed
この製品バージョンに脆弱性の修正が含まれていることを表します。
Under Investigation
この製品バージョンが脆弱性の影響を受けるかどうかはまだ不明です。アップデートは今後のリリースで提供される予定です。

VEX のサンプル

VEX のサンプルに関しては、VEX の Use Case に関しては、2023 年 4 月に出された CISA の「Vulnerability Exploitability eXchange (VEX)-Use Case(PDF)」に詳しく載っています。

ここから VEX の書き方を見ていきます。例として、以下のようなケースを考えます。

ある企業が "hoge" 製品を持っていて hoge ver1.0 で Log4j のライブラリを使用している。
Log4Shell 脆弱性（CVE-2021-44228）が公開された為、その企業の PSIRT(Product SIRT) が「"hoge" 製品が影響を受けるため hoge ver1.1 に更新してください」とする場合

CSAF(json 形式 ) ではこのようになります (GitHub にユースケースとして公開されています )。
CycloneDX ではもっとシンプルに、下記のようになります ( こちらも GitHub にユースケースとして公開されています )。こちらは短いので次に書いておきます。

  {
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata" : {
    "timestamp" : "2022-03-03T00:00:00Z",
    "component" : {
      "name" : "hoge",
      "version": "1.0",
      "type" : "application",
      "bom-ref" : "product-hoge"
    }
  },
  "vulnerabilities": [
    {
      "id": "CVE-2021-44228",
      "source": {
        "name": "NVD",
        "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
      },
      "analysis": {
        "state": "exploitable",
        "response": ["will_not_fix", "update"],
        "detail": "This version of Product hoge is affected by the vulnerability. Customers are advised to upgrade to the latest release."
      },
      "affects": [
        {
          "ref": "product-hoge"
        }
      ]
    }
  ]
}

VDR と VEX の比較

VDR と VEX の比較表

OWASP のブログで、VDR と VEX の比較がわかりやすく整理されていますので、こちらを翻訳して転記します。

	VDR	VEX
範囲	製品と依存しているもの（コンポーネントとサービス）	製品、製品ファミリー、全ての組織
期待されるもの	製品、コンポーネント、サービスに影響を与える全ての脆弱性について説明	製品が影響を受けない範囲までの全ての脆弱性の記述を目的とした、ネガティブなセキュリティ勧告
脆弱性のタイプ	既知の脆弱性とこれまで知られていなかった脆弱性	既知の脆弱性
分析	( 存在する場合 ) 脆弱性の影響、ベンダーの対応、期待について説明します。	( 存在する場合 ) 脆弱性の影響、ベンダーの対応、期待について説明します。
発行サイクル	SBOM と並行して発行製品に影響を与える新しい脆弱性が発見された時や、分析の結果が更新された時に都度更新	SBOM と並行して発行 (CSAF を除く ) 新しい脆弱性が発見された時や、分析の結果が更新された時に都度更新
政府による定義	NIST SP 800-161 推奨事項	CISA（疑似の仕様）
制限事項	全体的な発言（組織の全体など）は許可されません	識別子を持たない脆弱性（知られていなかった脆弱性等）を記述することはできません。
フォーマット・標準	CycloneDX, SAG-PM VDR	CycloneDX, CSAF, OpenVEX ( 開発中 )
リスクの透明性	製品に関連するリスクと修正された重大度 (CVSS の時間／環境スコア、OWASP リスク評価など ) を伝達します。	リスクや変更された重大度は伝えません。
認証サポート	VDR は、ベンダーが製品の依存関係の脆弱性をチェックし、それを伝えたことを証明するものです。	VEX は、どの脆弱性が製品に影響を与えないか、また必要に応じて影響を与えるかを証明します。 VEX では、ベンダーが製品の依存関係の脆弱性を確認したり、脆弱性を伝達したりする必要がありません。
ツールの利用可能性	広く普及	限定的
結果	ユーザーは、製品に影響を与える脆弱性と影響を及ぼさない脆弱性を明確に理解しています。	ユーザーは、製品に影響を与える脆弱性と影響を及ぼさない脆弱性を明確に理解しています。

CycloneDX／OpenSSF の対応

CycloneDX では、VDR/VEX ともに古くから対応しており、GitHub にも tree の中に両方が存在します。

OpenSSF の方では、VDR/VEX についての情報がこちらの記事に纏まっています。

まとめ

先述の NIST SP 800-161 Rev. 1「Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations」では、次のように記載されています。
「企業は、VDR で開示されていない脆弱性が発生した場合に備えて、顧客向けに別の通知チャネルを確立することも検討する必要があります。」
つまり NIST はガイダンス上で、ベンダーが定期的に VDR を発行することを推奨していますが、同時に VEX 等 VDR 以外の通知も（念の為に）検討することを推奨しています。
この様な状態ですので、現時点では企業・ベンダー・セキュリティベンダー共に、VDR と VEXの両方の提供をサポートしておくのが無難かと思われます。