Package URL

En package URL (purl, en standardisert pakkeadresse) er en identifikator for en programvarepakke som navngir den slik dens eget økosystem gjør: pkg:type/namespace/name@version?qualifiers#subpath. Den ble en Ecma-standard, ECMA-427, i desember 2025 (1. utgave, Ecma TC54), og spesifikasjonen vedlikeholdes på package-url/purl-spec.

Slik er en purl bygd opp

Hver purl begynner med skjemaet pkg. Typen er økosystemet eller pakkebehandleren (npm, pypi, cargo, deb, maven og så videre). Navnerommet er en valgfri gruppering, for eksempel et npm-scope, en Maven-gruppe eller en Linux-distribusjon. Deretter kommer navnet og versjonen. Kvalifikatorer legger til opplysninger økosystemet trenger for å peke ut nøyaktig riktig pakke, for eksempel arkitekturen eller distribusjonens utgivelse, og understien peker inn 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 siste sier mer enn «cpio 2.15»: det er Ubuntus eget bygg for utgivelsen Noble på arm64. Det betyr noe fordi distribusjoner tilbakefører sikkerhetsrettinger til sine egne versjoner, så samme upstream-versjon kan være sårbar i én distribusjon og rettet i en annen.

Hvorfor sårbarhetsmatching avhenger av den

Advisory-databaser som er organisert etter pakke, kjenner en komponent på økosystemet og navnet. OSV-skjemaet krever ecosystem og name for hver berørt pakke og kaller feltet purl «valgfritt, men anbefalt»; også GitHubs advisories er oppført per økosystempakke. Når en SBOM-komponent har en purl, kan et verktøy matche den nøyaktig mot disse advisoriene. Uten purl må det gjette ut fra et navn eller en CPE, eller så matcher det ingenting, og sårbarheten blir aldri rapportert.

I et Yocto-bygg vi sammenlignet, oppførte byggesystemets egen SBOM hundrevis av Rust-crates bare som .crate-filer med en nedlastingsadresse og uten pkg:cargo-purl, så disse crates kunne ikke matches mot Rust-advisories (se Yocto-bygg). Nyere Yocto-utgivelser legger til økosystem-purl-er for Cargo- og Go-kilder.

Package URL og CPE

	Package URL	CPE
Hvem bestemmer navnet	Pakkens økosystem	NVDs CPE-ordbok
Identifiserer	En pakke i et register eller en distribusjon	Et produkt, også maskinvare og operativsystemer
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Brukes av	OSV, GitHub-advisories, SBOM-verktøy	NVD, mange skannere
Typisk feil	Mangler for vendorert eller håndlistet kode	Tvetydige leverandør- og produktnavn; ingen CPE-data for mange nye CVE-er

Tommelfingerregelen: gi hver pakke som har et økosystem en purl, og bruk en CPE for det som ikke har det, for eksempel kommersiell programvare, fastvare og maskinvare. Identifikatorer som ikke stemmer, er en av hovedårsakene til feil funn, se reduser sårbarhetsstøyen.

Package URL-er i SBOM-er

CycloneDX og SPDX har begge en purl per komponent. CISAs 2026 Minimum Elements sier at komponentidentifikatorer skal bruke vanlige identifikatorer «som Common Platform Enumeration (CPE) og Package-URL (PURL)», og tyske BSI TR-03183-2 krever slike identifikatorer for hver komponent der de finnes. En manglende purl er et problem med feltkvaliteten heller enn et hull i SBOM-fullstendigheten: komponenten er oppført, men ingen advisory-database kan slå den opp.

CRACI registrerer en package URL for hver pakke et bygg henter inn, også for hver Rust-crate i et Yocto-bygg, slik at SBOM-ene kan matches mot advisories. Se SBOM-er fra byggetidspunktet.