PURL (Package URL) とは

PURL(Package URL)は、OSS(オープンソースソフトウェア)製品のパッケージを一意に識別するためのフォーマットです。似たようなコンセプトのものとしてCPE(Common Platform Enumeration)がありますが、PURLはOSSコミュニティから出てきたもので、OSSのパッケージを表すために使われます。特に近年ではSBOMとの親和性も高いことから、よく名前を聞く様になっています。

以下では、PURLについて簡単にまとめます。

「未経験からでもホワイトハッカーになれる！」実践的セキュリティスクール「セキュ塾」

サイバーセキュリティ技術者育成コース（2025年10月生募集中）
ホワイトハッカー育成コース（2025年10月生募集中）
脅威インテリジェンス育成コース（受講生随時募集中）

PURL(Package URL)とは
PURLの仕様
PURLのサンプル
PURLのメリット・デメリット
参考情報
- 関連記事:

PURL(Package URL)とは

　PURL(Package URL: 以下PURL)は2017年にOpenSourceツールメンテナの「Philippe Ombredanne」氏によって作成された、異なるパッケージ管理システム間でソフトウェアパッケージを一意に識別するための標準化フォーマットです。元々はScanCode Toolkit（コードで使用されているオープンソースおよびサードパーティのコンポーネントを検索、検出しするツール）を使用する際に、パッケージを識別するための新しい方法が必要になったことからスタートしています。

　ある程度OSSを使用しているエンジニアであれば知っていると思いますが、特にOSSの世界では個別プログラムによくあるnpmやmaven, PyPIなどのパッケージや、deb, rpmなどのOSのパッケージなど、様々なパッケージ管理システムとフォーマットが存在します。

　PURLは、そのような異なるパッケージ管理システム間でソフトウェアパッケージ、コンポーネント、ライブラリを識別するために使用される標準化されたフォーマットです。このフォーマットにより、ソフトウェアプロジェクトにおける依存関係の追跡、分析、管理が容易になります。

さらにこのPURLは、特に近年ではソフトウェア部品表（SBOM）の作成時に役立つということから注目されています。

　FOSDEM 2018のサイトでは、PURLのコンセプトを紹介した動画が公開されています。

PURLの仕様

　PURL(Package URL: 以下PURL)の仕様はこちらのPURLのGitHubリポジトリで公開されています。

scheme:type/namespace/name@version?qualifiers#subpath

以下はそれぞれの構成要素の説明です。

scheme（必須）: これは定数値「pkg」を持つURLスキームです。
type （必須）: maven、npm、nuget、gem、pypi などのパッケージの「タイプ」またはパッケージの「プロトコル」が入ります。
namespace（オプション） : MavenグループID、Dockerイメージの所有者、GitHubユーザーや組織などの名前プレフィックスです。
name　（必須） : パッケージの名前が入ります。
version　（オプション） : パッケージのバージョンが入ります。
修飾子　（オプション）: OS、アーキテクチャ、ディストリビューションなどのパッケージの追加の修飾データになります。
subpath 　（オプション）: パッケージルートを基準としたパッケージ内の追加サブパスです。

PURLのサンプル

以下はPURLのサンプルになります（GitHubよりいくつかピックアップして転載しています）。

下記はRubyGemになります。

pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:gem/ruby-advisory-db-check@0.12.4ß

下記はgo-langになります。

pkg:golang/google.golang.org/genproto#googleapis/api/annotations

下記はmavenです。

pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?repository_url=repo.spring.io/release

下記はnpmパッケージです。

pkg:npm/%40angular/animation@12.3.1
pkg:npm/foobar@12.3.1

下記はPyPIです。

pkg:pypi/django@1.11.1

下記はRedHat/Fedora(RPM)パッケージの場合です。

pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
pkg:rpm/opensuse/curl@7.56.1-1.1.?arch=i386&distro=opensuse-tumbleweed

下記はdebian(deb)パッケージの場合です。

pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie

下記はDockerイメージです。

pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:docker/customer/dockerimage@sha256:244fd47e07d1004f0aed9c?repository_url=gcr.io

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

　PURLのメリットは、なんといってもOSSをパッケージ化した際の形式（npm, Maven, PyPI等）を問わない、共通の形式を提供している所です。これにより、異なるツール間での情報交換がスムーズになります。

　一方でデメリットとしては、やはり新しい形式ということでまだまだ浸透しきっていないという点と、特にCPEと比較するとあくまでもPURLは「OSS」がベースですので、ほぼOSSのソフトウェアのみしか対応していないという点です。CPEはハードウェアなども記載できるため、PURLはその点ではCPEに比べて劣っています。

　しかし、OSS＋SBOMの世界ではPURLが広まってきています。将来はわかりませんが、現段階ではCPEとPURLを併用して使用するケースが増えると思いますので、ぜひこの機会にPURLも学習してみてください。

「未経験からでもホワイトハッカーになれる！」実践的セキュリティスクール「セキュ塾」