Package URL

Package URL (purl, standardowy adres pakietu) to identyfikator pakietu oprogramowania, który nazywa go tak, jak robi to jego własny ekosystem: pkg:type/namespace/name@version?qualifiers#subpath. W grudniu 2025 roku stał się standardem Ecma, ECMA-427 (1. wydanie, Ecma TC54), a specyfikacja jest utrzymywana w repozytorium package-url/purl-spec.

Jak zbudowany jest purl

Każdy purl zaczyna się od schematu pkg. Typ to ekosystem lub menedżer pakietów (npm, pypi, cargo, deb, maven itd.). Przestrzeń nazw to opcjonalne grupowanie, np. scope npm, grupa Maven lub dystrybucja Linuksa. Następnie są nazwa i wersja. Kwalifikatory dodają informacje potrzebne ekosystemowi do wskazania dokładnego pakietu, np. architekturę lub wydanie dystrybucji, a podścieżka wskazuje miejsce wewnątrz pakietu.

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

Ostatni mówi więcej niż „cpio 2.15”: to własny build Ubuntu dla wydania Noble na arm64. Ma to znaczenie, ponieważ dystrybucje przenoszą poprawki bezpieczeństwa do własnych wersji, więc ta sama wersja upstream może być podatna w jednej dystrybucji i poprawiona w innej.

Dlaczego dopasowywanie podatności od niego zależy

Bazy biuletynów bezpieczeństwa zorganizowane według pakietów rozpoznają komponent po ekosystemie i nazwie. Schemat OSV wymaga pól ecosystem i name dla każdego objętego pakietu, a pole purl określa jako „opcjonalne, ale zalecane”; biuletyny GitHub również są prowadzone według pakietów ekosystemu. Gdy komponent SBOM ma purl, narzędzie może dokładnie dopasować go do tych biuletynów. Bez niego musi zgadywać na podstawie nazwy lub CPE albo nie dopasowuje niczego, a podatność pozostaje niezgłoszona.

W porównywanym przez nas buildzie Yocto własny SBOM systemu budowania wymieniał setki crate'ów Rusta tylko jako pliki .crate z adresem pobrania i bez purl pkg:cargo, więc tych crate'ów nie dało się dopasować do biuletynów dla Rusta (zob. buildy Yocto). Nowsze wydania Yocto dodają purl ekosystemu dla źródeł Cargo i Go.

Package URL a CPE

	Package URL	CPE
Kto ustala nazwę	Ekosystem pakietu	Słownik CPE prowadzony przez NVD
Identyfikuje	Pakiet w rejestrze lub dystrybucji	Produkt, także sprzęt i systemy operacyjne
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Używają go	OSV, biuletyny GitHub, narzędzia SBOM	NVD, wiele skanerów
Typowy problem	Brak dla kodu dołączonego do repozytorium lub wpisanego ręcznie	Niejednoznaczne nazwy dostawców i produktów; brak danych CPE dla wielu nowych CVE

Praktyczna zasada: każdemu pakietowi, który ma ekosystem, proszę nadać purl, a CPE stosować dla tego, co ekosystemu nie ma, np. oprogramowania komercyjnego, firmware'u i sprzętu. Niepasujące identyfikatory to jedna z głównych przyczyn błędnych znalezisk, zob. ograniczanie szumu podatności.

Package URL w SBOM

CycloneDX i SPDX zawierają purl dla każdego komponentu. 2026 Minimum Elements CISA wymagają, by identyfikatory komponentów korzystały z powszechnych identyfikatorów, „takich jak Common Platform Enumeration (CPE) i Package-URL (PURL)”, a niemiecka BSI TR-03183-2 wymaga takich identyfikatorów dla każdego komponentu, o ile istnieją. Brak purl to problem jakości pól, a nie luka w kompletności SBOM: komponent jest wymieniony, ale żadna baza biuletynów nie może go wyszukać.

CRACI rejestruje package URL dla każdego pakietu, który pobiera build, w tym dla każdego crate'a Rusta w buildzie Yocto, dzięki czemu jego SBOM można dopasować do biuletynów bezpieczeństwa. Zob. SBOM z czasu buildu.