Package URL

En package URL (purl, en standardiseret pakkeadresse) er en identifikator for en softwarepakke, der navngiver den, som dens eget økosystem gør: pkg:type/namespace/name@version?qualifiers#subpath. Den blev en Ecma-standard, ECMA-427, i december 2025 (1. udgave, Ecma TC54), og specifikationen vedligeholdes på package-url/purl-spec.

Hvordan en purl er opbygget

Enhver purl begynder med skemaet pkg. Typen er økosystemet eller pakkehåndteringen (npm, pypi, cargo, deb, maven og så videre). Navnerummet er en valgfri gruppering, for eksempel et npm-scope, en Maven-gruppe eller en Linux-distribution. Derefter kommer navnet og versionen. Kvalifikatorer tilføjer oplysninger, som økosystemet har brug for til at udpege den præcise pakke, for eksempel arkitekturen eller distributionens release, og understien peger ind i en pakke.

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

Den sidste siger mere end "cpio 2.15": det er Ubuntus eget build til releasen Noble på arm64. Det betyder noget, fordi distributioner backporterer sikkerhedsrettelser til deres egne versioner, så den samme upstream-version kan være sårbar i én distribution og rettet i en anden.

Hvorfor sårbarhedsmatchning afhænger af den

Advisory-databaser, der er organiseret efter pakke, kender en komponent på dens økosystem og navn. OSV-skemaet kræver ecosystem og name for hver berørt pakke og kalder sit felt purl "valgfrit, men anbefalet"; også GitHubs advisories er opført pr. økosystempakke. Når en SBOM-komponent har en purl, kan et værktøj matche den præcist mod disse advisories. Uden en purl må det gætte ud fra et navn eller en CPE, eller det matcher ingenting, og sårbarheden bliver aldrig rapporteret.

I et Yocto-build, som vi sammenlignede, angav byggesystemets egen SBOM hundredvis af Rust-crates kun som .crate-filer med en downloadplacering og uden pkg:cargo-purl, så de crates kunne ikke matches mod Rust-advisories (se Yocto-builds). Nyere Yocto-releases tilføjer økosystem-purls for Cargo- og Go-kilder.

Package URL vs. CPE

	Package URL	CPE
Hvem bestemmer navnet	Pakkens økosystem	NVD's CPE-ordbog
Identificerer	En pakke i et register eller en distribution	Et produkt, inklusive hardware og operativsystemer
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Bruges af	OSV, GitHub-advisories, SBOM-værktøjer	NVD, mange scannere
Typisk fejl	Mangler for vendoret eller håndlistet kode	Tvetydige leverandør- og produktnavne; ingen CPE-data for mange nye CVE'er

Tommelfingerreglen: giv hver pakke med et økosystem en purl, og brug en CPE til det, der ikke har et, for eksempel kommerciel software, firmware og hardware. Identifikatorer, der ikke passer sammen, er en af hovedårsagerne til forkerte fund, se mindsk sårbarhedsstøjen.

Package URLs i SBOM'er

CycloneDX og SPDX har begge en purl pr. komponent. CISA's 2026 Minimum Elements siger, at komponentidentifikatorer skal bruge almindelige identifikatorer "som Common Platform Enumeration (CPE) og Package-URL (PURL)", og den tyske BSI TR-03183-2 kræver sådanne identifikatorer for hver komponent, hvor de findes. En manglende purl er et problem med feltkvaliteten snarere end et hul i SBOM-fuldstændigheden: komponenten er med, men ingen advisory-database kan slå den op.

CRACI registrerer en package URL for hver pakke, et build henter, også for hver Rust-crate i et Yocto-build, så dets SBOM'er kan matches mod advisories. Se build-time SBOM'er.