Package URL

Une package URL (purl, une adresse standard de paquet) est un identifiant de paquet logiciel qui le nomme comme le fait son propre écosystème : pkg:type/namespace/name@version?qualifiers#subpath. Elle est devenue une norme Ecma, ECMA-427, en décembre 2025 (1re édition, Ecma TC54), et la spécification est maintenue sur package-url/purl-spec.

Comment une purl est construite

Toute purl commence par le schéma pkg. Le type est l'écosystème ou le gestionnaire de paquets (npm, pypi, cargo, deb, maven, etc.). L'espace de noms est un regroupement facultatif, comme un scope npm, un groupe Maven ou une distribution Linux. Viennent ensuite le nom et la version. Les qualificateurs ajoutent les informations dont l'écosystème a besoin pour désigner le paquet exact, comme l'architecture ou la version de la distribution, et le sous-chemin pointe à l'intérieur d'un paquet.

pkg:npm/%40angular/[email protected]
pkg:pypi/[email protected]
pkg:cargo/[email protected]
pkg:deb/ubuntu/[email protected]+dfsg-1ubuntu2.1?arch=arm64&distro=noble

La dernière dit plus que « cpio 2.15 » : c'est le build d'Ubuntu lui-même pour la version Noble sur arm64. C'est important, car les distributions rétroportent les correctifs de sécurité dans leurs propres versions : une même version amont peut être vulnérable dans une distribution et corrigée dans une autre.

Pourquoi la détection des vulnérabilités en dépend

Les bases d'avis de sécurité organisées par paquet connaissent un composant par son écosystème et son nom. Le schéma OSV exige ecosystem et name pour chaque paquet concerné et qualifie son champ purl de « facultatif mais recommandé » ; les avis de GitHub sont eux aussi répertoriés par paquet d'écosystème. Lorsqu'un composant de SBOM porte une purl, un outil peut le rapprocher exactement de ces avis. Sans purl, il doit deviner à partir d'un nom ou d'un CPE, ou ne trouve rien, et la vulnérabilité n'est pas signalée.

Dans un build Yocto que nous avons comparé, la SBOM du système de build listait des centaines de crates Rust uniquement sous forme de fichiers .crate avec une adresse de téléchargement, sans purl pkg:cargo : ces crates ne pouvaient donc pas être rapprochées des avis Rust (voir builds Yocto). Les versions plus récentes de Yocto ajoutent des purl d'écosystème pour les sources Cargo et Go.

Package URL et CPE

	Package URL	CPE
Qui définit le nom	L'écosystème du paquet	Le dictionnaire CPE de la NVD
Identifie	Un paquet dans un registre ou une distribution	Un produit, y compris le matériel et les systèmes d'exploitation
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Norme	ECMA-427	NISTIR 7695 (CPE 2.3)
Utilisé par	OSV, avis GitHub, outils SBOM	NVD, de nombreux scanners
Échec typique	Absente pour le code vendorisé ou listé à la main	Noms de fournisseur et de produit ambigus ; pas de données CPE pour beaucoup de CVE récentes

La règle empirique : donnez une purl à chaque paquet qui a un écosystème, et utilisez un CPE pour ce qui n'en a pas, comme les logiciels commerciaux, les firmwares et le matériel. Les identifiants mal appariés sont l'une des principales causes de résultats erronés, voir réduire le bruit des vulnérabilités.

Les package URL dans les SBOM

CycloneDX et SPDX portent tous deux une purl par composant. Les 2026 Minimum Elements de la CISA demandent que les identifiants de composant utilisent des identifiants courants « tels que Common Platform Enumeration (CPE) et Package-URL (PURL) », et la BSI TR-03183-2 allemande exige de tels identifiants pour chaque composant lorsqu'ils existent. Une purl manquante est un problème de qualité des champs plutôt qu'une lacune de complétude de la SBOM : le composant est listé, mais aucune base d'avis ne peut le retrouver.

CRACI enregistre une package URL pour chaque paquet qu'un build récupère, y compris chaque crate Rust d'un build Yocto, afin que ses SBOM puissent être rapprochées des avis de sécurité. Voir SBOM au moment du build.