Package URL
Eine Package URL (purl) ist eine standardisierte Zeichenkette, die ein Softwarepaket über Ökosystem, Namespace, Name und Version identifiziert, etwa pkg:npm/[email protected].
Zuletzt aktualisiert: 11. November 2026
Eine Package URL (purl, eine standardisierte Paketadresse) ist eine Kennung für ein Softwarepaket, die es so benennt, wie sein eigenes Ökosystem es tut: pkg:type/namespace/name@version?qualifiers#subpath. Seit Dezember 2025 ist sie ein Ecma-Standard, ECMA-427 (1. Ausgabe, Ecma TC54), und die Spezifikation wird unter package-url/purl-spec gepflegt.
Wie eine purl aufgebaut ist
Jede purl beginnt mit dem Schema pkg. Der Typ ist das Ökosystem oder der Paketmanager (npm, pypi, cargo, deb, maven und so weiter). Der Namespace ist eine optionale Gruppierung, etwa ein npm-Scope, eine Maven-Gruppe oder eine Linux-Distribution. Dann folgen Name und Version. Qualifier ergänzen Angaben, die das Ökosystem braucht, um das Paket exakt festzulegen, etwa die Architektur oder das Distributions-Release, und der Subpath verweist in ein Paket hinein.
pkg:npm/%40angular/[email protected]
pkg:pypi/[email protected]
pkg:cargo/[email protected]
pkg:deb/ubuntu/[email protected]+dfsg-1ubuntu2.1?arch=arm64&distro=nobleDie letzte sagt mehr als „cpio 2.15“: Es ist Ubuntus eigener Build für das Release Noble auf arm64. Das zählt, weil Distributionen Sicherheitskorrekturen in ihre eigenen Versionen zurückportieren. Dieselbe Upstream-Version kann also in einer Distribution verwundbar und in einer anderen behoben sein.
Warum der Schwachstellenabgleich davon abhängt
Advisory-Datenbanken, die nach Paketen organisiert sind, kennen eine Komponente über ihr Ökosystem und ihren Namen. Das OSV-Schema verlangt ecosystem und name für jedes betroffene Paket und nennt sein Feld purl „optional, aber empfohlen“; auch die Advisories von GitHub sind pro Ökosystem-Paket aufgeführt. Trägt eine SBOM-Komponente eine purl, kann ein Tool sie exakt mit diesen Advisories abgleichen. Ohne purl muss es aus einem Namen oder einer CPE raten, oder es findet gar nichts, und die Schwachstelle bleibt ungemeldet.
In einem Yocto-Build, den wir verglichen haben, führte die SBOM des Build-Systems Hunderte Rust-Crates nur als .crate-Dateien mit Download-Adresse und ohne pkg:cargo-purl. Diese Crates ließen sich daher nicht mit Rust-Advisories abgleichen (siehe Yocto-Builds). Neuere Yocto-Releases ergänzen Ökosystem-purls für Cargo- und Go-Quellen.
Package URL vs. CPE
| Package URL | CPE | |
|---|---|---|
| Wer den Namen festlegt | Das Ökosystem des Pakets | Das CPE-Wörterbuch der NVD |
| Identifiziert | Ein Paket in einer Registry oder Distribution | Ein Produkt, auch Hardware und Betriebssysteme |
| Format | pkg:type/namespace/name@version | cpe:2.3:part:vendor:product:version:... |
| Standard | ECMA-427 | NISTIR 7695 (CPE 2.3) |
| Genutzt von | OSV, GitHub-Advisories, SBOM-Tools | NVD, viele Scanner |
| Typischer Fehler | Fehlt bei vendortem oder von Hand gelistetem Code | Mehrdeutige Hersteller- und Produktnamen; keine CPE-Daten für viele neue CVEs |
Die Faustregel: Geben Sie jedem Paket mit Ökosystem eine purl und nutzen Sie eine CPE für alles ohne Ökosystem, etwa kommerzielle Software, Firmware und Hardware. Nicht passende Kennungen sind eine der Hauptursachen für falsche Befunde, siehe Schwachstellen-Rauschen reduzieren.
Package URLs in SBOMs
CycloneDX und SPDX führen beide eine purl pro Komponente. Die 2026 Minimum Elements der CISA verlangen für Komponentenkennungen gängige Kennungen „wie Common Platform Enumeration (CPE) und Package-URL (PURL)“, und die deutsche BSI TR-03183-2 fordert solche Kennungen für jede Komponente, sofern sie existieren. Eine fehlende purl ist ein Problem der Feldqualität, keine Lücke in der SBOM-Vollständigkeit: Die Komponente ist aufgeführt, aber keine Advisory-Datenbank kann sie nachschlagen.
CRACI zeichnet für jedes Paket, das ein Build lädt, eine Package URL auf, auch für jedes Rust-Crate in einem Yocto-Build, damit seine SBOMs mit Advisories abgeglichen werden können. Siehe Build-Time-SBOMs.