SBOM時代の「名前」の科学：
PURL、CPEからSWID、ハッシュまで、ソフトウェア識別子の完全ガイド

1. はじめに：なぜソフトウェアの「名前」がセキュリティの壁になるのか

現代のソフトウェア開発は、世界中からオープンソースソフトウェア（OSS）や商用ライブラリという「部品」を集めて組み立てる作業です。この部品リストが「SBOM（Software Bill of Materials）」ですが、SBOMを真に機能させるための最大の障壁が「部品の呼び名（識別子）の不統一」です。

例えば「Log4j」という部品に脆弱性が見つかったとき、自社のシステムが影響を受けるか自動でチェックするには、データベース上の「Log4j」と、自社のSBOMに書かれた「Log4j」が、システム上で100%一致している必要があります。表記の揺れは、致命的な見落とし（偽陰性）や無駄な警告（偽陽性）に直結します。

この「ソフトウェアのバベルの塔」状態を解決するために策定されたのが、様々な標準識別子です。本記事では、SBOM運用で必須となる主要な識別子とその役割分担について解説します。

2. 二大巨頭：PURLとCPEの役割分担

SBOMのガイドライン（CycloneDXなど）において、コンポーネントの特定に推奨されているのがPURLとCPEです。これらは対立するものではなく、「どこからソフトウェアを見ているか」という視点の違いです。

PURL (Package URL)：開発者とOSSのための「動的な住所」

PURLは、パッケージマネージャー（npm, PyPI, Mavenなど）のエコシステムに依存するOSSの世界で標準となっている識別形式です。

CPE (Common Platform Enumeration)：セキュリティと商用製品の「カタログ番号」

CPEは、米国のNIST（国立標準技術研究所）が提唱し、長年NVD（国家脆弱性データベース）で使われてきた伝統的な識別形式です。

3. さらに強固な管理へ：用途別の拡張識別子

PURLとCPEで「名前」の大部分はカバーできますが、エンタープライズの厳密な管理や、ゼロトラストセキュリティの世界では、さらに別の角度からの識別子がSBOMに組み込まれます。

SWIDタグ：エンタープライズの「インストール証明書」

SWID（Software Identification）は、IT資産管理やライセンス管理に特化した国際標準（ISO/IEC 19770-2）です。

• 役割: ソフトウェアがPCやサーバーに「インストールされた状態」を証明します。
• 用途: 企業内のエンドポイントに不正なソフトが入っていないか、ライセンス超過がないかを監査するITAM（IT資産管理）ツールで活用されます。米国政府はSBOMの構成要素としてSWIDの利用も強く推進しています。

暗号学的ハッシュ値（SHA-256等）：改ざんを許さない「デジタル指紋」

名前に依らない、ファイルそのものの数学的な証明です。

• 役割: ソフトウェアのバイナリやソースコードから算出される固有の文字列です。例: e3b0c442...
• 用途: PURLやCPEが完全に一致していても、悪意ある第三者が中に不正コードを仕込んでいれば（サプライチェーン攻撃）、ハッシュ値は変化します。SBOMにおいて、部品が「本物であり改ざんされていないこと（完全性）」を証明するための最終防衛線です。

SBOM内部の参照ID (bom-ref)：設計図を繋ぐ「ローカル整理番号」

外部と照合するための名前ではなく、SBOMファイルの中だけで使われる識別子です。

• 役割: 「部品Aは、部品Bを内包している」といった、ソフトウェアの複雑なツリー構造（依存関係）を記述するためのアンカー（目印）として機能します。

4. 各識別子のベストプラクティスと使い分け

これら複数の識別子は、どれか一つを選べば良いというものではありません。堅牢なSBOMでは、これらが併記されるべきです。以下の表に、それぞれの役割を整理します。

現場で推奨されるアプローチ

5. まとめ

SBOMの運用において、「部品をどう呼ぶか」は単なるフォーマットの問題ではなく、セキュリティ運用の自動化における要（かなめ）です。

開発に直結するPURL、脆弱性管理の歴史を背負うCPE、資産管理のSWID、そして完全性を担保するハッシュ値。これら異なる視点の識別子を適切に組み合わせることで、初めて「死角のないソフトウェアサプライチェーンの可視化」が実現します。
来るべきSBOMの義務化・標準化に向けて、組織内でこれらの識別子の意味と使い分けを共通認識としておくことが強く求められています。