Package URL (PURL)

A Package URL (PURL) is a standardised string format for uniquely identifying software packages. It encodes the package type (ecosystem), namespace, name, version, and optional qualifiers and subpath in a consistent URL-like syntax. The format is: pkg:type/namespace/name@version?qualifiers#subpath. Examples: pkg:npm/%40angular/[email protected] identifies the Angular core npm package version 14.0.0; pkg:pypi/[email protected] identifies the Python requests library; pkg:docker/library/[email protected] identifies a specific Docker image. PURL was developed by the SPDX and CycloneDX communities to solve the cross-ecosystem component identification problem and has been adopted as the standard identifier in both SBOM formats.

The CRA's Annex VII SBOM requirement is only as useful as the accuracy of component identification. A common failure mode in SBOMs is identifying components by name alone - 'requests 2.31.0' - without specifying the ecosystem (is this the Python pip package, or a Java Maven package with the same name?). PURL solves this by including the ecosystem type in the identifier. This precision enables:

• Accurate CVE correlation: Vulnerability databases correlate CVEs to packages using PURL. An SBOM with PURL identifiers can be automatically matched against vulnerability feeds to identify which CVEs affect the product.
• Cross-tool interoperability: PURL is supported by NVD, OSV, Dependency-Track, and all major vulnerability management tools, enabling consistent results across platforms.
• Reachability analysis: Tools that assess whether a vulnerable code path is actually invoked in the product require precise component identification - PURL provides this.

CPE (Common Platform Enumeration) is another identifier system used in NVD CVE records to identify affected products and components. CPE uses a different format: cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*. Key differences:

• Coverage: CPE covers hardware, operating systems, and applications broadly. PURL specialises in software packages within specific ecosystems.
• Precision: PURL is generally more precise for package-level identification within software ecosystems. CPE has known precision issues at the package level.
• Adoption: PURL has overtaken CPE as the preferred identifier in modern SBOM tooling. However, NVD CVE records still use CPE extensively, so understanding both is necessary for vulnerability correlation.

Best practice for CRA SBOMs is to include both PURL and CPE identifiers where available, maximising compatibility with different vulnerability correlation tools and databases.

PURL generation is typically handled automatically by SBOM generation tools - manufacturers should not need to construct PURLs manually. Key considerations:

• Verify ecosystem type: Ensure the SBOM generator correctly identifies the package ecosystem (npm vs PyPI vs Maven) - misidentification is the most common PURL error.
• Include version exactly: The PURL version must exactly match the package version string as it appears in the package registry, including build metadata where applicable.
• Validate against known records: After generating an SBOM with PURLs, validate a sample of PURLs against the OSV database (osv.dev) to confirm they resolve correctly to known vulnerability records.
• Handle private/internal packages: For internal packages not in public registries, use a custom PURL type or namespace to distinguish them from public packages. Internal packages with no CVE exposure need not be excluded from the SBOM - their inclusion demonstrates completeness.