PURL（Package URL）とは
（OSS特定のキー）

PURLで何が分かるのか

PURLの強みは、単なる“名前”ではなく、どのエコシステムの、どの名前空間の、どの版数のパッケージか を表しやすいことです。

たとえば npm、Maven、PyPI などで同じような名前のパッケージがあっても、type や namespace を含めて表現できるため、照合の精度が上がります。

このためPURLは、SBOMそのものではありませんが、SBOMの中で使うと価値が出る識別子です。SPDX仕様でも、脆弱性情報の解決に役立つ外部参照として、CPEやSWIDなどと並んで PURLを含めることが推奨実務 とされています。

CPEとの違い

実務で混同しやすいのが CPE です。
CycloneDXの公式ガイドでは、OSSにはPURLを推奨し、プロプライエタリソフトや一部政府系/商用データベースに載る製品にはCPEが適する と整理しています。さらに、ハードウェア識別ではCPEが推奨される場面もあります。

つまり、ざっくり言うと次のような使い分けが現実的です。

サプライヤー実務でどこに出てくる？

PURLは、主に次の場面で登場します。

• SBOM作成： OSSコンポーネントを識別しやすくする
• CVE突合： どのOSSパッケージかを精度高く照合する
• OEM照会： 対象版数と根拠を整理する土台にする

ただし、CycloneDXも明記している通り、すべての脆弱性インテリジェンス源がすべての識別子をサポートするわけではありません。したがって、PURLだけで万能というより、SBOM・版数管理・必要に応じたCPE併用まで含めて考えるのが安全です。

よくある落とし穴

PURLは非常に便利ですが、“OSS特定のキー”であって、判断そのものを置き換えるものではない と理解しておくと運用が安定します。

• type や namespace が抜けていて、同名パッケージを取り違える
• version が曖昧で、対象版数が切れない
• PURLがあれば自動で完全一致すると過信してしまう
• 商用部品やハードウェアまでPURLだけで扱おうとして無理が出る

---

FAQ：PURLについて