Package URL

Package URL (purl) on ohjelmistopaketin standardoitu tunniste, joka nimeää paketin samalla tavalla kuin sen oma ekosysteemi: pkg:type/namespace/name@version?qualifiers#subpath. Siitä tuli Ecma-standardi, ECMA-427, joulukuussa 2025 (1. painos, Ecma TC54), ja määrittelyä ylläpidetään osoitteessa package-url/purl-spec.

Miten purl muodostuu

Jokainen purl alkaa skeemalla pkg. Tyyppi on ekosysteemi tai paketinhallintatyökalu (npm, pypi, cargo, deb, maven ja niin edelleen). Nimiavaruus on valinnainen ryhmittely, kuten npm-scope, Maven-ryhmä tai Linux-jakelu. Sen jälkeen tulevat nimi ja versio. Määreet lisäävät tietoja, joita ekosysteemi tarvitsee täsmälleen oikean paketin yksilöimiseen, kuten arkkitehtuurin tai jakelun julkaisun, ja alipolku osoittaa paketin sisälle.

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

Viimeinen kertoo enemmän kuin "cpio 2.15": se on Ubuntun oma buildi Noble-julkaisulle arm64-arkkitehtuurilla. Tällä on merkitystä, koska jakelut takaisinsiirtävät tietoturvakorjauksia omiin versioihinsa, joten sama upstream-versio voi olla haavoittuva yhdessä jakelussa ja korjattu toisessa.

Miksi haavoittuvuuksien täsmäytys riippuu siitä

Pakettikohtaisesti järjestetyt tietoturvatiedotetietokannat tuntevat komponentin sen ekosysteemin ja nimen perusteella. OSV-skeema edellyttää ecosystem- ja name-kentät jokaiselle haavoittuvalle paketille ja kutsuu purl-kenttäänsä "valinnaiseksi mutta suositelluksi"; myös GitHubin tietoturvatiedotteet listataan ekosysteemin paketeittain. Kun SBOM:n komponentilla on purl, työkalu voi täsmäyttää sen näihin tiedotteisiin tarkasti. Ilman sitä työkalun on arvattava nimen tai CPE:n perusteella, tai se ei täsmäytä mitään, ja haavoittuvuus jää raportoimatta.

Vertailemassamme Yocto-buildissa build-järjestelmän oma SBOM listasi satoja Rust-crateja pelkkinä .crate-tiedostoina, joilla oli latauspaikka mutta ei pkg:cargo-purlia, joten näitä crateja ei voitu täsmäyttää Rustin tietoturvatiedotteisiin (katso Yocto-buildit). Uudemmat Yocto-julkaisut lisäävät ekosysteemikohtaiset purlit Cargo- ja Go-lähteille.

Package URL vs. CPE

	Package URL	CPE
Kuka määrittää nimen	Paketin ekosysteemi	NVD:n CPE-sanakirja
Yksilöi	Paketin rekisterissä tai jakelussa	Tuotteen, myös laitteistot ja käyttöjärjestelmät
Muoto	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standardi	ECMA-427	NISTIR 7695 (CPE 2.3)
Käyttäjät	OSV, GitHubin tietoturvatiedotteet, SBOM-työkalut	NVD, monet skannerit
Tyypillinen ongelma	Puuttuu vendoroidulta tai käsin listatulta koodilta	Monitulkintaiset toimittaja- ja tuotenimet; ei CPE-tietoja monille uusille CVE:ille

Nyrkkisääntö: anna jokaiselle paketille, jolla on ekosysteemi, purl, ja käytä CPE:tä sille, jolla ekosysteemiä ei ole, kuten kaupallisille ohjelmistoille, laiteohjelmistoille ja laitteistolle. Toisiinsa sopimattomat tunnisteet ovat yksi tärkeimmistä virheellisten löydösten syistä, kuten kerrotaan sivulla haavoittuvuuskohinan vähentäminen.

Package URL:t SBOM:eissa

Sekä CycloneDX että SPDX sisältävät purlin komponenttia kohden. CISA:n 2026 Minimum Elements toteaa, että komponenttitunnisteissa tulisi käyttää yleisiä tunnisteita "kuten Common Platform Enumeration (CPE) ja Package-URL (PURL)", ja Saksan BSI TR-03183-2 edellyttää tällaisia tunnisteita jokaiselle komponentille, jolle niitä on. Puuttuva purl on pikemminkin kentän laatuongelma kuin aukko SBOM:n kattavuudessa: komponentti on listattu, mutta mikään tietoturvatiedotetietokanta ei pysty hakemaan sitä.

CRACI tallentaa package URL:n jokaiselle paketille, jonka buildi hakee, myös jokaiselle Yocto-buildin Rust-cratelle, joten sen SBOM:t voidaan täsmäyttää tietoturvatiedotteisiin. Katso buildin aikana tallennetut SBOM:t.