CPE, NVD, SBOM, SCAP, 解説

CPEの問題点と、SBOM利用時の

The SBOM Forumの資料から、SBOMの直近の動向と、それにかかわるCPEの話をします。(今回はnon-GPTなblogです)

概要

The SBOM Forumから出ていた “A Proposal to Operationalize　Component Identification for Vulnerability Management”について、概要を説明しようかと思います。

これは、以下の点を理解するのに有効だと思うからです。

  • SBOMの普及で何が問題になっているのか
  • CPEって、実は結構ダメなものでは？という感覚を共有する(分かったうえで使うのが良い)

当該Proposalの概要

おおよそ以下のような話だと思ってよいと思います。

  • SBOM利用の大きな阻害原因は、naming problem（名前付け問題）
  • naming problemとは、普遍的に合意された名前が無い為、不確実性があることを意味している。これがCPEの現状。
  • とはいえ、SBOM対応しないとだめだよね、大統領令（EO14028等）などがあるし。
  • 対策は、CPEに代わる物でSBOM記載すればいいんじゃないですかね。
  • purl（Package-URL）を用いた記法がよさそうだ（ https://github.com/package-url/purl-spec ）。例えば pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c のように書く感じ。だけどソフトウェアしか記載できなさそう
  • ハードウェア等は GTIN（Global Trade Identification Number）やGMN（Global Model Number）を使えば良さそう。これは国際的非営利団体GS1によって開発された、全ての承認の識別基準で、米国/EU/日本の標準を含むスーパーセットなので、汎用性ありそう。
  • 結果として、purl/GTIN/GMNで、今のCPEの代わりをさせる必要がありそう。
  • SBOMへの表記の点では、SWIDが上記を扱えるようにスキーマに取り込まれたようだ。

CPEの問題点

確かに、CPEには問題点が多々ある。

  • CPEは、ハードウェア業界やソフトウェア業界に固有のものではなく、NVDの重要性によりセキュリティコミュニティによってのみ採用されている。
  • 脆弱性が登録されるまで、CPEは発行されないので、見つけられない
  • 新しいCPE名がNVDに入力されるときに、エラーチェックは行われない。
  • 製品またはサプライヤーの名前が変更された場合、CPE名も同様に変更される場合がある。
  • 様々な表記方法ができるものがあり、区別ができない。例えば、　Microsoft(tm)/Microsoft(tm) Inc./Microsoft(tm) Word/Microsoft Office(tm)、等。
  • 多くの場合、脆弱性はライブラリの1つのモジュールに発生するが、CPEはモジュールに基づいて割り当てられているわけではない為、CVEレポートを全部読まないと分からない。

その問題点を解決できるよう、purlを使おうぜ、という流れのようだ。

purlとは

purlには7つのコンポーネントを含められるようですが、必要なものは以下のコンポーネントのみのようです。

  • スキーム：常に”pkg”とする
  • タイプ：パッケージのエコシステムを示す。例えば maven, npm, nuget, gem など
  • 名前：パッケージエコシステム内の製品の名前

例えば、Maven内にfooというパッケージがあった場合、pkg:mave/foo とります。これはCPEで例えるなら cpe:2.3:a:<ベンダ名どうすんの？>:<fooのパッケージ名はfooでいいの？>:*:`:*:*:*:*:*:* 辺りになると思われます。エコシステム名ではなくベンダ名なので、確定し辛そう。

但し、purlではソフトウェアの記述だけなので、ハードウェア記述用に別の手法が必要になるようです。それで利用できるものが、GTINとGMNのようです。

GTINとは

GTINとは、Global Trade Item Number（グローバルトレードアイテムナンバー）の略称で、世界中で商品を識別するための番号の規格のようです。商品やサービスを一意に識別するための番号であり、バーコードやRFIDタグなどの自動認識技術と組み合わせて使用されることが多いようです。

概要は GS1 Japanのページが参考になりそうですね。

これは、ISO（国際標準化機構）がISO/IEC 15420で定義しているものであり、GTINを管理/発行する団体は GS1（Global Standards One）のようです。GTIN-13はJANコード標準タイプとして扱われています。

CPEの定義は前述のように、「ハードウェア業界やソフトウェア業界に固有のものではなく、NVDの重要性によりセキュリティコミュニティによってのみ採用されている」ことで不確実性が起きていますが、GTINではその部分が解消されると考えてよさそうです。

GMNとは

これもGS1が関連していて、GS1が提唱する識別体系 GDSN（GlobalData Synchronization Network）において使用されているものです。

これも、概要はGS1 Japanのページが参考になりそうです。

GMNは、商品やサービスの情報を、国際的に一意に識別するために使用されるため、CPEの用途としては合致していると思われます。

今後の展望とまとめ

前述のpurl/GTIN/GMNをNVDで取り込む、SBOMフォーマットに取り込む（SWIDはNVD管理下）が、進められたり、取り込み完了しています。

今後は、CVEにpurl/GTIN/GMNが記載されるか、purlをcpeに変換するもので「SBOMの情報と脆弱性情報を結びつける」という流れになっていくと思われます。

purl2cpeというものも、進んでいるようです。

SBOMの脆弱性情報のマッチングは現時点ではなかなか難しいので、それらが改善すると、広く利用される&米国連邦機関では強制されると思われます。今のうちからSBOMについて徐々に知見を貯めていくことをお勧めします。

以上、脆弱性対応勉強会の資料とするにはもっと細かく書かないといけないからめんどくさいのでblogに書いたよ、記事を終わりにします。そこそこ調べたし、資料をgoogle translateしまくった（合計3時間くらいは掛けた）ものを、こちらに簡易版として掲載しました。

内容についてはの正しさは、以下の言葉で締めくくらせて頂きます。

知らんけど。