Package URL

Un package URL (purl, un indirizzo standard di pacchetto) è un identificatore di un pacchetto software che lo chiama come lo chiama il suo stesso ecosistema: pkg:type/namespace/name@version?qualifiers#subpath. È diventato uno standard Ecma, ECMA-427, nel dicembre 2025 (1ª edizione, Ecma TC54), e la specifica è mantenuta su package-url/purl-spec.

Come è costruito un purl

Ogni purl inizia con lo schema pkg. Il tipo è l'ecosistema o il gestore di pacchetti (npm, pypi, cargo, deb, maven e così via). Il namespace è un raggruppamento facoltativo, come uno scope npm, un gruppo Maven o una distribuzione Linux. Seguono il nome e la versione. I qualificatori aggiungono le informazioni di cui l'ecosistema ha bisogno per individuare il pacchetto esatto, come l'architettura o la release della distribuzione, e il subpath punta all'interno di un pacchetto.

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

L'ultimo dice più di «cpio 2.15»: è la build di Ubuntu stessa per la release Noble su arm64. È importante perché le distribuzioni riportano le correzioni di sicurezza nelle proprie versioni, quindi la stessa versione upstream può essere vulnerabile in una distribuzione e corretta in un'altra.

Perché il matching delle vulnerabilità ne dipende

I database di advisory organizzati per pacchetto conoscono un componente tramite il suo ecosistema e il suo nome. Lo schema OSV richiede ecosystem e name per ogni pacchetto interessato e definisce il campo purl «facoltativo ma consigliato»; anche gli advisory di GitHub sono elencati per pacchetto dell'ecosistema. Quando un componente della SBOM ha un purl, uno strumento può associarlo esattamente a quegli advisory. Senza purl deve tirare a indovinare da un nome o da un CPE, oppure non trova nulla, e la vulnerabilità non viene segnalata.

In una build Yocto che abbiamo confrontato, la SBOM del sistema di build elencava centinaia di crate Rust solo come file .crate con un indirizzo di download e senza purl pkg:cargo, per cui quei crate non potevano essere associati agli advisory Rust (veda build Yocto). Le release più recenti di Yocto aggiungono purl di ecosistema per le sorgenti Cargo e Go.

Package URL e CPE a confronto

	Package URL	CPE
Chi definisce il nome	L'ecosistema del pacchetto	Il dizionario CPE della NVD
Identifica	Un pacchetto in un registry o in una distribuzione	Un prodotto, compresi hardware e sistemi operativi
Formato	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Usato da	OSV, advisory GitHub, strumenti SBOM	NVD, molti scanner
Errore tipico	Manca per codice incorporato o elencato a mano	Nomi di fornitore e prodotto ambigui; nessun dato CPE per molte CVE recenti

La regola pratica: assegni un purl a ogni pacchetto che ha un ecosistema e usi un CPE per ciò che non ne ha, come software commerciale, firmware e hardware. Gli identificatori che non corrispondono sono una delle cause principali di risultati errati, veda ridurre il rumore delle vulnerabilità.

I package URL nelle SBOM

CycloneDX e SPDX riportano entrambi un purl per componente. I 2026 Minimum Elements della CISA chiedono che gli identificatori dei componenti usino identificatori comuni «come Common Platform Enumeration (CPE) e Package-URL (PURL)», e la tedesca BSI TR-03183-2 richiede tali identificatori per ogni componente, se esistono. Un purl mancante è un problema di qualità dei campi più che una lacuna nella completezza della SBOM: il componente è elencato, ma nessun database di advisory può cercarlo.

CRACI registra un package URL per ogni pacchetto che una build scarica, compreso ogni crate Rust di una build Yocto, così che le sue SBOM possano essere associate agli advisory. Veda SBOM in fase di build.