CPEとは
（突合の落とし穴が多い識別子）
CPEとは Common Platform Enumeration の略で、ハードウェア、OS、アプリケーションなどを 標準化された名前で表すための識別子 です。
NISTの用語集では、CPEを「ハードウェア、オペレーティングシステム、アプリケーションの命名法と辞書」と説明しており、NVDでも公式のCPE Dictionaryが運用されています。
サプライヤー実務でCPEが出てくるのは、主に CVEと製品を突合するとき です。
NVDのCPE API documentationでは、CPE 2.3の名前は13個のコロン区切り要素で構成され、CPE Match Stringは1つ以上のCPE Nameに対応し得る別概念として扱われています。つまりCPEは「製品をどう表すか」、CPE Match Stringは「脆弱性との対応付けをどう持つか」に近い役割です。
CPEが便利な理由
CPEの強みは、NVDのような脆弱性データベース側で 製品の名前を比較的一貫して扱える ことです。
NVDではCPE Dictionaryが継続的に更新されており、CPEを使うことで製品名の揺れをある程度吸収しながら検索・照合できます。CPEはもともとSCAP系の標準群の一部でもあり、セキュリティ自動化の文脈で長く使われてきました。
でも、なぜ“落とし穴が多い”のか
実務での問題は、CPEがそのまま“自社製品に該当する”ことを保証しない 点です。
NVDのCPE APIにはCPE NameとCPE Match Stringの区別があり、CycloneDXの公式ガイドでも、OSSではPURLを推奨し、CPEは主に政府系や一部商用データベースで管理されるプロプライエタリソフトやハードウェア向けに適すると説明しています。つまり、OSS中心の世界ではCPEが必ずしも第一選択ではなく、識別子の選び方自体が実務上の論点になります。
よくある落とし穴は次のようなものです。
- 製品名は似ていても、エディションや構成違いで別物
- ベンダー名や製品名の表記揺れで一致しない
- CPEに載っていても、自社の搭載版数や実装差分までは分からない
- CPEに無いからといって、非搭載とは言い切れない
つまり、CPEは “候補を絞る識別子” であって、最終判断そのものではありません。
SBOMや構成表、対象版数の確認とセットで使うのが安全です。
サプライヤー実務での使い方
現実的には、まずSBOMや簡易部品表で 自社が何を積んでいるか を押さえ、その後にCPEでNVD側の情報と突合する流れが安定します。
CycloneDXのガイドでも、すべての脅威インテリジェンス源が同じ識別子をサポートしているわけではないため、複数ソースの併用が必要だと説明されています。CPEだけに依存すると誤判定が増えやすいので、「CPE＝入口」「SBOM＝正本」 の考え方が実務向きです。
FAQ：CPEとは
CPEは、ハードウェアやOS、アプリケーションなどを標準化された名前で表す識別子です。NVDのような脆弱性データベースで製品を扱うために使われます。
違います。CPEは“識別子”で、SBOMは“構成表”です。SBOMの一部としてCPEを持つことはありますが、SBOM全体を置き換えるものではありません。
十分ではありません。CPEは候補の絞り込みに役立ちますが、最終的には自社の対象版数、構成、搭載有無、設定条件などの確認が必要です。
使える場合もありますが、CycloneDXの公式ガイドではOSSにはPURLを推奨しています。CPEはプロプライエタリソフトウェアやハードウェア側で使いやすいケースが多いです。
SBOMの識別子やCVE突合に悩んでいませんか？
CPEやPURLの使い分け、Excel部品表から自動運用への移行など、SBOM整備・提出運用をどこから始めるか整理したい方はご相談ください。