　本記事では、以下のProposal paper
A Proposal to Operationalize Component Identification for Vulnerability Management
を参考に、IT製品を識別するための識別子とそこに潜む製品の命名問題について解説します。
　少し、英語が難しく、自分の解釈違いがあるかもしれないため、原文を読んで、私の間違いを見つけた方は教えていただけると助かります。
　現在、ソフトウェアやハードウェア製品を一意に識別するための識別子がいくつか提案されています。これら製品の識別は脆弱性検知に広く利用されています。例えば、識別子の一つであるCPEは、NVD (National Vulnerability Database)という最も広く利用されている脆弱性情報データベース内の脆弱性識別子CVEと結びつていおり、使用する製品とそれが持つ脆弱性とをマッチングさせるために利用されています。基本的に製品とそれが持つ脆弱性をマッチングさせるためには、ある製品を一意に特定することが重要となります。
　しかし、一般的に任意のソフトウェアコンポーネント、製品に対して普遍的な標準的な名前または識別子は存在しません。そのため、IT製品を一意に識別し特定することは難しいと言われています。
　そこで、本記事では、IT製品の識別子の一つであるCPEを利用する場合に起こる、製品の命名課題を解説します。命名問題を解決するための識別子の要件提案、現在、OSSの脆弱性検知スキャナーが取っている対策を紹介します。

CPE

CPE(Common Platform Enumeration)とは、アプリケーション、オペレーティングシステム、ハードウェアデバイスなどのIT製品を標準化された方法で記述・識別するためのスキーマ（仕様）です。CPEに命名規則、マッチング方法の仕様が定式化されています。

CPEはwell-formed CPE name (WFN)という命名方法を使います。WFNとはIT製品を以下の構成要素で命名する方法です。

part
vendor
product
version
update
edition
language
sw_edition
target_sw
target_hw
other
例えば、Microsoft Internet Explorer 8.0.6001 BetaというIT製品をWFNで表現すると、

wfn:[part="a",vendor="microsoft",product="internet_explorer",
version="8\.0\.6001",update="beta"]

となります。
CPEはURI（CPEバージョン2.2で定義）とフォーマット文字列 (the formatted string)（CPEバージョン2.3で定義）、2つの形式をサポートしています。この2形式はIT製品のWFNから生成されます。この変換プロセスは、WFNからURIまたはフォーマット文字列へのバインディングと呼ばれています。Microsoft Internet Explorer 8.0.6001 Betaの場合、WFNから、URI、フォーマット文字列へそれぞれ以下のようにバインディングされます：

ver2.2 URI

cpe:/a:microsoft:internet_explorer:8.0.6001:beta

ver2.3 the formatted string

cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*

一般的にみなさんがCPEと呼ぶ場合、このWFNからURI、フォーマット文字列へバインディングされた識別子をCPEと呼んでいます。
NVDでは、上記のどちらかのCPEの形式に対して、脆弱性識別子が割り当てられています。また、SBOM作成時に、上のCPEのURIまたはフォーマット文字列形式どちらかを、記述することできます。
CPEについて詳細に知りたい方は以下の文献で説明されているので参考にしてください。

製品の命名問題とCPEの課題について

前述したとおり、IT製品とそれに紐づく脆弱性を調べるためにはCPEという識別子を利用しています。しかし、CPEを運用していくうえで、CPEの命名についていくつか課題があります。
以下は、NVD が唯一の識別子としてCPEに依存していることから生じる6つの課題です。

1 必ずしもすべての製品にCPEが作成されるわけではない

NVDにおいて、脆弱性は「CVE-2022-12345」のようにCVE番号という脆弱性識別子で識別されます。CVEがその製品に適用されると判断されたとき、ソフトウェア製品に対してCPEが作成されます。しかし、ソフトウェアサプライヤが必ずしも自社製品に適用されるCVEを全て特定し、全ての製品に対してCPEを作成するわけではありません。

つまり、ある製品に
脆弱性が確認されていないケース
と
サプライヤが脆弱性を報告できず、CPEが作られていないケース
どちらの場合も、その製品に脆弱性はなかったという結果になるということです。

その結果、脆弱性検索を実行者はどちらのケースに当てはまるかわからず、実際にはサプライヤーが脆弱性を報告したことがないにもかかわらず、製品に脆弱性がないと信じてしまう可能性があるという問題があります。¹

2. NVDに新しく登録されるCPE名に対して、エラーチェックが行われない

NVDに新しく登録されるCPE名に対して、エラーチェックは行われません。そのため、ある製品に対して最初に作成されたCPE名が命名仕様に正しく従わず登録された場合、後に命名仕様に従った正しいCPEで同じ製品を検索したとしても、マッチするCVEを知ることはできません。
つまり、CPEによる脆弱性検索時、脆弱性が検出されなかった場合、本当に脆弱性がないのか、脆弱性があるのにCPEが誤って登録されているから検出できないのかを判別することができないのです。
また、検索を行うユーザーがCPEの名前を間違えた場合も同様にして、脆弱性が見つからなかった原因が自分のCPEの入力ミスであるかを判別することができません。

そこで、NVDに依存する多くの組織がこのような問題を回避するために、機械学習やファジーロジック (CPEの厳密に一致させるのでなく、少し幅を持たせてマッチングさせること)などの高度な検索技術を利用しています。

3　CPEが変更されてしまう

合併や買収によって、開発当初から、製品名またはサプライヤー名が変更された場合その製品のCPE名も変更されることがあります。CPEには、製品名、サプライヤ名が含まれています。したがって、元の製品のユーザは、その製品の現在の名称だけでなく、現在のサプライヤの名称も知らなければ、その製品で特定された新たな脆弱性について知ることができないかもしれないということです。

4 製品名とサプライヤ名について、様々な表記法があり区別ができない

Microsoft(™)」と「Microsoft(™)Inc.」、「Microsoft(™)Word」と「Microsoft Office(™)Word」など、異なる方法で記述ができるサプライヤや製品が存在し、これらを区別することができないという問題もあります。

5. NVD内で一つの製品に対して複数のCPEが登録される

一つの製品に複数のCPE名がNVDに登録されていることがあります。このため、どのCPEが正しいかを判断するのは難しくなります。最悪の場合、複数あるCPEがすべて間違っている場合もあります。
また、複数あるCPEそれぞれに異なるCVEが対応している場合は、ある製品に対するCVEを全て特定することは極めて難しいです。

6. CPEはモジュール単位で作成されない

多くの場合、脆弱性はパッケージ内の1つのモジュールに現れます。しかし、CPE名は個々のモジュールに基づいて割り当てられているわけではないので、ユーザはCVEレポートの全文を読まない限り、どのモジュールに脆弱性があるのか分かりません。
また、パッケージ単位で脆弱性を見てしまうと、脆弱性発見後、その脆弱性が使用していないモジュールの脆弱性に対して、脆弱性を修正することになります。ユーザーは実際には影響を受けていないにもかかわらず、対策を行うため、余計に工数をかけてしまう可能性があります。

新しい識別子の提案

文献ではソフトウェアやハードウェアのコンポーネントを命名するための識別子の要件について提案されています：

正しい製品にほぼ常に一致すること
誤った製品にほとんど一致しないこと
既にNVDに存在している識別子を必要としないこと
NVDに既存の識別子を利用すれば、前述した問題が生じるため
以下のa,b,c、三つのケースの一つが起きた場合に、製品に該当する脆弱性がなかったと解釈される結果は出さない。ユーザーが誤解しないように、正確な情報や適切なエラーメッセージを提供する必要がある。
a. ユーザーが間違った識別子を検索バーに入力してしまう
b. 仕様通りではない (Off-spec) 識別子が識別子発行時に割り当てられる場合
c. 製品名やサプライヤーが変更され、元の製品の識別子が現在のCPE名と一致しない場合
ライブラリ内の脆弱なモジュールを特定できること
ライブラリ全体ではなく、特定の脆弱なモジュールを識別できるようにし、そのモジュールがインストールされていない場合、ユーザーは不要なパッチ適用や対策を避けられるようにする。
サプライヤーや製品名の変更を考慮した識別子の扱い
サプライヤーや製品名が変更された場合でも、それぞれ別の識別子を許容し、CVEの報告先も別々にする。

命名問題に対する各種脆弱性検知ツールが取っている対策

これら、CPEを使った脆弱性検知の難しさを受け、各種ツールでは対策が取られています。

Trivy

Trivyでは、CPEを使わず、ベンダーが出している脆弱性情報源を使いマッチングを行っています。

Grype

GrypeもCPEに問題意識を持っており、言語パッケージに関する脆弱性検知にはCPEを使用していません。現在、リポジトリのソースコードを見る限り、CPEを利用しているのはAlpineのapkパッケージに対する脆弱性を検知するために利用しているぽいです。ちなみに、ここで、取っている手法は前述したCPEファジーマッチングと呼ばれる手法です。製品のコンポーネント情報を採取するときに、複数のCPEを生成し、NVD内に登録されているCPEとマッチする確率をあげています。

参考文献

Proposal paper

A Proposal to Operationalize Component Identification for Vulnerability Management

CPEの解説

CPEとCVEのマッチングに関する研究

そもそも、脆弱性ってだれが見つけて、どのように登録されていくのか疑問に思っていたのですが、調べてもよくわかりませんでした。 ↩

CPE