Package URL

Package URL (purl) je standardní identifikátor softwarového balíčku, který ho pojmenovává tak, jak to dělá jeho vlastní ekosystém: pkg:type/namespace/name@version?qualifiers#subpath. V prosinci 2025 se stal standardem Ecma, ECMA-427 (1. vydání, Ecma TC54), a specifikace se udržuje v repozitáři package-url/purl-spec.

Jak je purl sestaven

Každý purl začíná schématem pkg. Typ je ekosystém nebo správce balíčků (npm, pypi, cargo, deb, maven a další). Jmenný prostor je volitelné seskupení, například scope v npm, skupina v Mavenu nebo linuxová distribuce. Pak následují název a verze. Kvalifikátory přidávají údaje, které ekosystém potřebuje k určení přesného balíčku, například architekturu nebo vydání distribuce, a podcesta ukazuje dovnitř balíčku.

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

Poslední z nich říká víc než „cpio 2.15“: jde o vlastní build Ubuntu pro vydání Noble na arm64. To je důležité, protože distribuce backportují bezpečnostní opravy do vlastních verzí, takže stejná upstream verze může být v jedné distribuci zranitelná a v jiné opravená.

Proč na něm závisí párování zranitelností

Databáze bezpečnostních upozornění organizované podle balíčků poznají komponentu podle jejího ekosystému a názvu. Schéma OSV vyžaduje u každého dotčeného balíčku ecosystem a name a své pole purl označuje za „volitelné, ale doporučené“; bezpečnostní upozornění GitHubu jsou rovněž vedena podle balíčků ekosystému. Když komponenta v SBOM nese purl, nástroj ji může s těmito upozorněními spárovat přesně. Bez něj musí hádat podle názvu nebo CPE, nebo nespáruje nic a zranitelnost zůstane nenahlášena.

V buildu Yocto, který jsme porovnávali, uváděla vlastní SBOM build systému stovky crate v Rustu jen jako soubory .crate s umístěním ke stažení a bez purl pkg:cargo, takže tyto crate nebylo možné spárovat s bezpečnostními upozorněními pro Rust (viz buildy Yocto). Novější vydání Yocta přidávají purl ekosystému pro zdroje Cargo a Go.

Package URL vs CPE

	Package URL	CPE
Kdo určuje název	Ekosystém balíčku	Slovník CPE od NVD
Identifikuje	Balíček v registru nebo distribuci	Produkt, včetně hardwaru a operačních systémů
Formát	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Kdo ho používá	OSV, bezpečnostní upozornění GitHubu, nástroje SBOM	NVD, mnoho skenerů
Typické selhání	Chybí u přibaleného nebo ručně uvedeného kódu	Nejednoznačné názvy dodavatelů a produktů; u mnoha nových CVE chybí data CPE

Praktické pravidlo: každému balíčku, který má ekosystém, přidělte purl a pro to, co ekosystém nemá, například komerční software, firmware a hardware, použijte CPE. Nesprávně spárované identifikátory jsou jednou z hlavních příčin chybných nálezů, jak popisujeme v článku jak snížit šum zranitelností.

Package URL v SBOM

CycloneDX i SPDX nesou u každé komponenty purl. Dokument 2026 Minimum Elements od CISA uvádí, že identifikátory komponent by měly používat běžné identifikátory, „jako jsou Common Platform Enumeration (CPE) a Package-URL (PURL)“, a německá BSI TR-03183-2 takové identifikátory vyžaduje u každé komponenty, pro kterou existují. Chybějící purl je problém kvality pole, nikoli mezera v úplnosti SBOM: komponenta je uvedena, ale žádná databáze bezpečnostních upozornění ji nedokáže vyhledat.

CRACI zaznamenává package URL pro každý balíček, který build stáhne, včetně každé crate v Rustu v buildu Yocto, takže jeho SBOM lze spárovat s bezpečnostními upozorněními. Podívejte se na SBOM z doby buildu.