131% fler rapporterade CVE:er per dag 2026 än förra året.
← Tillbaka till ordlistan

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 URLCPE
Vem bestämmer namnetPaketets ekosystemNVD:s CPE-ordlista
IdentifierarEtt paket i ett register eller en distributionEn produkt, även hårdvara och operativsystem
Formatpkg:type/namespace/name@versioncpe:2.3:part:vendor:product:version:...
StandardECMA-427NISTIR 7695 (CPE 2.3)
Används avOSV, GitHubs säkerhetsmeddelanden, SBOM-verktygNVD, många skannrar
Typiskt felSaknas för vendorad eller handlistad kodTvetydiga 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.