SBOMと脆弱性管理のつなぎ方
（識別子/CPE/PURLの落とし穴を整理）
SBOMを作ったのに、CVE対応がまったく楽にならない。
この失敗は珍しくありません。原因の多くは、SBOMそのものではなく、SBOMと脆弱性情報をつなぐ“識別子”の設計が弱いことにあります。
CISAはSBOMをソフトウェア部品の入れ子状インベントリ、いわば“ingredients list”として位置づけていますが、SBOMが価値を持つのは、脆弱性管理やリスク管理の運用に組み込まれた時です。
実務で特に重要なのが PURL と CPE です。
CycloneDXの公式ガイドでは、既知脆弱性の識別において OSSにはPURLを推奨し、プロプライエタリソフトウェアやハードウェアにはCPEが適する場合があると整理しています。
一方で、すべての脅威インテリジェンス源が同じ識別子をサポートするわけではないため、複数ソースの併用が必要だとも明記されています。
先に結論：SBOMを脆弱性管理につなぐ時の基本方針
最初に結論を置きます。SBOMと脆弱性管理をつなぐ時は、次の3つを守ると大きく外しません。
-
1
OSSは PURL を優先する
-
2
NVD照合や一部製品識別には CPE を使う
-
3
識別子は“候補抽出”であり、最終判断は対象版数・構成・到達性で行う
この3つを外すと、誤検知が増えるか、逆に見逃しが増えます。特にNVDは CPE 2.3 を製品識別に使っており、アナリストは CVE に CPE match strings を付与しますが、これはあくまで照合の入口です。
まず整理：PURLとCPEは役割が違う
PURLとは
PURL（Package URL）は、ソフトウェアパッケージをエコシステム横断で識別するための標準化された方法です。公式仕様では、type, namespace, name, version, qualifiers, subpath などの要素で構成されると説明されています。
パッケージマネージャやOSSエコシステムに近く、“このOSSパッケージのこの版数” を表すのに向いています。
CPEとは
CPE（Common Platform Enumeration）は、NVDが使う製品識別の中心的な仕組みです。NVDのProductsページでは、NVDは CPE 2.3 を使って製品を一意に扱い、CVEs には CPE match strings を付与していると説明しています。
つまりCPEは、NVDやその周辺で“どの製品が影響対象か”を扱う時の言語です。
この2つは競合ではなく、見る世界が違うと理解するのが実務向きです。
パッケージ中心で見るなら PURL
NVD中心で見るなら CPE
という使い分けです。
なぜ識別子で詰まるのか
SBOMと脆弱性管理がつながらない理由は、次のような“ズレ”が起きるからです。
1. 名前のズレ
SBOM側では openssl、脆弱性情報側では製品名やベンダ名込みで別表現、ということが起きます。PURLはエコシステムと版数まで含めやすい一方、CPEはNVD側の製品識別に寄っています。名前が同じでも前提が違うため、片方だけで突合しようとすると精度が落ちます。
2. 版数のズレ
CVE対応で本当に重要なのは、どの製品版数に、どのコンポーネント版数が入っているかです。識別子があっても、製品版数との紐付けが弱いと、照合結果をそのまま使えません。CISAのSBOM関連資料も、SBOMは構成要素を把握し、脆弱性評価に使うための基盤だと位置づけています。
3. “辞書に無い＝存在しない”という誤解
NVDのCPEに存在しないからといって、自社製品や部品に影響がないとは限りません。逆にCPEがあるからといって、そのまま自社製品に一致するとも限りません。NVDのドキュメントでも、CPE Name と CPE Match String は別概念として扱われています。
実務で一番多い落とし穴
-
落とし穴1CPEを“正解”だと思う CPEは有力な手掛かりですが、最終判断ではありません。CPEは 候補抽出 のために使い、その後に自社のSBOM、構成表、対象版数で確認する流れが必要です。
-
落とし穴2PURLだけで全部解決しようとする CycloneDXが推奨している通り、OSSにはPURLが強いですが、すべての脅威インテリジェンス源がPURLを十分サポートしているわけではありません。NVD側で見るならCPEの理解も必要です。
-
落とし穴3識別子と製品版数がつながっていない SBOMに PURL や CPE が入っていても、どの製品版数のSBOMか が曖昧だと、OEM照会で「で、どの版に入っていますか？」で止まります。これは識別子の問題というより、運用の問題です。
兼務でも破綻しない：つなぎ方の手順（5ステップ）
製品版数を先に固定する
まず、製品名と製品版数を切ります。識別子より先にここが曖昧だと、後工程が全部ブレます。
SBOMの最小項目を整える
最低限、次を持ちます。
- 製品名 ／ 製品バージョン
- コンポーネント名 ／ コンポーネントバージョン
- 種別（OSS/商用/自社）
- 搭載箇所 ／ 備考（根拠）
OSSにはPURLを付ける
OSSコンポーネントは、可能ならPURLを付けます。これで、パッケージベースの脆弱性情報との接続がしやすくなります。
必要に応じてCPEを併用する
NVDベースで突合したい場合や、プロプライエタリ製品・ハードウェア識別が必要な場合は、CPEを併用します。ただし、CPEは候補抽出と割り切ります。
最後は人が“文脈”で判断する
識別子は便利ですが、最終的には以下の文脈を見て affected / not_affected / under_investigation に落とします。
- 対象版数
- 到達性
- 前提条件
- 実行経路
これがPSIRTやVEX運用の本体です。
そのまま使える：識別子整理メモの最小テンプレ（TSV）
社内でまず持つなら、この程度で十分です。下の枠内をコピーしてExcelに貼り付けてください。
自社のSBOMを、脆弱性管理（CVE突合）にどう繋げるか運用設計を整理したい方はご相談ください。
【無料】オンライン相談を予約するFAQ：識別子と脆弱性管理の接続について
OSSはPURL、NVD照合や商用/ハードウェアはCPEという使い分けが基本です。CycloneDX等でも複数ソースの併用が想定されています。
CPEはあくまで「候補抽出」として使います。表記ゆれや版数のズレがあるため、最後は自社の構成表や設計情報と照合して判断します。
自動でできるのは「候補出し」までです。最終的にその脆弱性が悪用可能か（到達性や実行経路）の判断は、VEXの観点を用いて人間が行うか、あらかじめ属性（外部IFなし等）を付与しておく必要があります。
識別子の揺れや突合を、システムで吸収しませんか？
Auto PSIRT Cloudなら、Excelの部品表を取り込むだけで、AIが表記ゆれや識別子を推測・補完し、NVD等のデータベースと自動で突合を行います。