Package URL
En package URL (purl) är en standardiserad sträng som identifierar ett programpaket via ekosystem, namnrymd, namn och version, till exempel pkg:npm/[email protected].
Senast uppdaterad: 11 november 2026
En package URL (purl, en standardiserad paketadress) är en identifierare för ett programpaket som namnger det på samma sätt som dess eget ekosystem gör: pkg:type/namespace/name@version?qualifiers#subpath. Den blev en Ecma-standard, ECMA-427, i december 2025 (1:a utgåvan, Ecma TC54), och specifikationen förvaltas på package-url/purl-spec.
Hur en purl är uppbyggd
Varje purl börjar med schemat pkg. Typen är ekosystemet eller pakethanteraren (npm, pypi, cargo, deb, maven och så vidare). Namnrymden är en valfri gruppering, till exempel ett npm-scope, en Maven-grupp eller en Linuxdistribution. Sedan kommer namnet och versionen. Kvalificerare lägger till uppgifter som ekosystemet behöver för att peka ut exakt rätt paket, till exempel arkitekturen eller distributionens release, och delsökvägen pekar in i ett paket.
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 sista säger mer än "cpio 2.15": det är Ubuntus eget bygge för releasen Noble på arm64. Det spelar roll eftersom distributioner backporterar säkerhetsrättningar till sina egna versioner, så samma uppströmsversion kan vara sårbar i en distribution och rättad i en annan.
Varför sårbarhetsmatchning hänger på den
Databaser med säkerhetsmeddelanden som är ordnade per paket känner igen en komponent på dess ekosystem och namn. OSV-schemat kräver ecosystem och name för varje berört paket och kallar fältet purl "valfritt men rekommenderat"; även GitHubs säkerhetsmeddelanden listas per ekosystempaket. När en SBOM-komponent har en purl kan ett verktyg matcha den exakt mot de meddelandena. Utan purl måste verktyget gissa utifrån ett namn eller en CPE, eller så matchar det ingenting, och sårbarheten rapporteras aldrig.
I ett Yocto-bygge som vi jämförde listade byggsystemets egen SBOM hundratals Rust-crates enbart som .crate-filer med en nedladdningsplats och utan pkg:cargo-purl, så de kunde inte matchas mot säkerhetsmeddelanden för Rust (se Yocto-byggen). Nyare Yocto-releaser lägger till ekosystem-purl:er för Cargo- och Go-källor.
Package URL och CPE
| Package URL | CPE | |
|---|---|---|
| Vem bestämmer namnet | Paketets ekosystem | NVD:s CPE-ordlista |
| Identifierar | Ett paket i ett register eller en distribution | En produkt, även hårdvara och operativsystem |
| Format | pkg:type/namespace/name@version | cpe:2.3:part:vendor:product:version:... |
| Standard | ECMA-427 | NISTIR 7695 (CPE 2.3) |
| Används av | OSV, GitHubs säkerhetsmeddelanden, SBOM-verktyg | NVD, många skannrar |
| Typiskt fel | Saknas för vendorad eller handlistad kod | Tvetydiga leverantörs- och produktnamn; inga CPE-data för många nya CVE:er |
Tumregeln: ge varje paket som har ett ekosystem en purl, och använd en CPE för det som saknar ekosystem, till exempel kommersiell programvara, firmware och hårdvara. Identifierare som inte stämmer är en av de vanligaste orsakerna till felaktiga fynd, se minska sårbarhetsbruset.
Package URL:er i SBOM:er
CycloneDX och SPDX har båda en purl per komponent. CISA:s 2026 Minimum Elements anger att komponentidentifierare ska använda vanliga identifierare "som Common Platform Enumeration (CPE) och Package-URL (PURL)", och tyska BSI TR-03183-2 kräver sådana identifierare för varje komponent där de finns. En saknad purl är ett problem med fältkvaliteten snarare än en lucka i SBOM-fullständigheten: komponenten finns med, men ingen databas med säkerhetsmeddelanden kan slå upp den.
CRACI registrerar en package URL för varje paket som ett bygge drar in, även varje Rust-crate i ett Yocto-bygge, så att dess SBOM:er kan matchas mot säkerhetsmeddelanden. Se SBOM:er från bygget.