CPE と PURL の基礎知識

CPE とは？

CPE とは？

CPE（Common Platform Enumeration / 共通プラットフォーム一覧） は、米国標準技術研究所（NIST）が管理するソフトウェアやハードウェア製品を一意に識別するための標準フォーマットです。 主に CVE（共通脆弱性識別子）と組み合わせて脆弱性管理に活用されます。

CPE のフォーマット

CPE には URI 形式 と FS（Formatted String）形式 の2種類ありますが、今回は NIST が運営するソフトウェアや IT 製品などの脆弱性情報を集めたデータベース「NVD」で使用される FS 形式について説明します。

記述方法

cpe:2.3:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>

パラメータ詳細

パラメータ	概要	例
cpe	CPE 識別子のプレフィックス（共通）	cpe
2.3	CPE のバージョン（現在は 2.3 が主流）	2.3
<part>	製品のカテゴリ（以下の3種類） - a : アプリケーション - o : オペレーティングシステム - h : ハードウェア	o
<vendor>	ベンダー名	microsoft
<product>	製品名	windows_10_22h2
<version>	バージョン番号	10.0.19041.3920
<update>	更新情報（通常、パッチやマイナーアップデートを示す）	*
<edition>	製品エディション	*
<language>	言語設定	*
<sw_edition>	ソフトウェアのエディション	*
<target_sw>	対象となるソフトウェア	*
<target_hw>	対象となるハードウェア	x86
<other>	その他の追加情報（特定のバージョンやビルド番号）	*

※ CPE の FS 形式では、すべての項目に一意の値が入力されていることは稀であり、「*（アスタリスク）」が使用されることが多くあります。このアスタリスクは、「未指定」であるか、「すべての値を含む」ことを示します。

具体例

パッケージ	CPE
Windows 10（22H2）	cpe:2.3:o:microsoft:windows_10_22h2:10.0.19041.3920:*:*:*:*:x86:*
Apache Tomcat 9.0	cpe:2.3:a:apache:tomcat:9.0.0:*:*:*:*:*:*:*
Cisco ルーター	cpe:2.3:h:cisco:ios:15.2:*:*:*:*:*:*:*

CPE の調べ方

CPE は、NVD で集中管理されているため、 NIST の Web サイト で検索して、簡単に調べることができます。 以下は、「Apache Tomcat 9.0」の CPE を調べた際の例です。

① 入力フォームに「tomcat 9」と入力し、「送信」をクリックします。

② 検索結果から該当するソフトウェアの CPE を取得します。

CPE のメリット・デメリット

CPE のメリット

1. ソフトウェアやハードウェアを標準化されたフォーマットで識別できる
2. 脆弱性データベース（NVD）と親和性がある

CPE のデメリット

1. 記述が複雑で、手動で作成・管理するのは困難
2. 実際の製品名・バージョンと CPE 表記が一致しないことがある

CPE は標準化された識別子として非常に有効ですが、手動での記述や管理は煩雑になりがちです。特に、実際の製品名とCPEの表記が異なる場合、対応関係の把握に苦労することも少なくありません。
CPE に対応している脆弱性管理ツールやソフトウェア資産管理ツールを活用することで、資産情報から CPE を自動生成したり、NVD などの脆弱性データベースと連携してリスクを自動検出することができます。

• CPE の仕様詳細はこちら
• NIST が管理する CPE のリストはこちらからダウンロード可能

PURL とは？

PURL とは？

PURL（Package URL） は、オープンソースソフトウェアのパッケージを一意に識別するためのフォーマットです。 PURL は、OSSコミュニティ全体で策定されています。
依存関係管理やソフトウェア・サプライチェーン・セキュリティの分野で活用されているほか、 Googleが公開するオープンソースソフトウェアに関する脆弱性データベースである OSV（Open Source Vulnerabilities） と組み合わせて脆弱性管理にも利用されます。
PURL はあくまでパッケージの識別子を「一貫した形式で書き表すためのルール」であり、各組織や各自が作成するものです。よって、CPE のように集中管理され「登録された全リスト」が存在するわけではありません。各言語エコシステム（npm、Maven、PyPIなど）や組織の事情に合わせて柔軟に記述できる反面、世界共通の識別子が存在しない点には注意が必要です。

PURL のフォーマット

PURL の各項目について説明します。

記述方法

<pkg>:<type>/<namespace>/<name>@<version>?<qualifiers>#<subpath>

パラメータ詳細

パラメータ	概要	必須	例
<pkg>	スキーム（共通）	◯	pkg
<type>	パッケージマネージャ、エコシステム	◯	rpm
<namespace>	パッケージのネームスペース、組織名やグループ名など		almalinux
<name>	パッケージ名	◯	curl
<version>	パッケージのバージョン		7.61.1-30.el8
<qualifiers>	追加の情報（OS、アーキテクチャなど）をキー=バリュー形式で指定		arch=x86_64 upstream=curl-7.61.1-30.el8.src.rpm distro=almalinux-8.8
<subpath>	パッケージ内の特定のパス		（未指定）

具体例

パッケージ	PURL
cURL	pkg:rpm/almalinux/curl@7.61.1-30.el8? arch=x86_64& upstream=curl-7.61.1-30.el8.src.rpm& distro=almalinux-8.8
Django	pkg:pypi/django@1.11.1

PURL のメリット・デメリット

PURL のメリット

1. OSS ソフトウェアを標準化されたフォーマットで識別できる
2. エコシステム（npm、Maven、PyPIなど）と親和性がある

PURL のデメリット

1. CPE のように「PURL を網羅する公式 DB」がないため、逆引きや正規化が難しい
2. CPEと異なり、ハードウェア製品の識別には利用できない

PURL は、OSS の識別に特化した柔軟なフォーマットであり、主要なエコシステムと高い親和性を持っています。その一方で、CPE のような中央リポジトリが存在しないため、PURL の逆引きや正規化が難しく、環境によって表記がバラつきやすいという課題もあります。 こうした点を補うには、SBOM（ソフトウェア部品表）対応ツールや脆弱性管理ツールの活用が効果的です。多くのツールでは、PURL をベースにパッケージ情報を自動で整理・管理し、既知の脆弱性情報と照合する機能が提供されています。ツールを導入することで、PURL を手間なく活用でき、OSS の管理効率とセキュリティ対応力の向上が期待できます。

• PURL の仕様詳細はこちら

まとめ

CPE と PURL の比較を以下に示します。

項目	CPE (Common Platform Enumeration)	PURL (Package URL)
策定団体	NIST	OSS コミュニティ
形式	FS 形式（":" 区切り） URI 形式	URI 形式（"/, @, ?, #" 区切り）
対象	ソフトウェア・ハードウェア全般	主に OSS パッケージ

CPE/PURL は、ソフトウェアを一意に識別し、脆弱性やソフトウェア管理の品質を向上させるために有力な規格です。ぜひ CPE と PURL を活用し、効果的な管理を実現しましょう。

また、当社製品である MIRACLE Vul Hammer では、2025年5月のアップデートで CPE/PURL の推論機能を実装しました。ご興味のあるかたは、まずは小規模な PoC を実施し、効果を検証してみてはいかがでしょうか。ぜひお問い合わせください！

関連リンク

SBOM 対応の脆弱性管理ツール「MIRACLE Vul Hammer」