Dependency-Track logo Dependency-Track

Components often belong to one or more ecosystems. These ecosystems typically have one or more sources of truth that provide additional data about the components. For example, Maven Central and the NPM repository provide information about Java and Node components respectively.

Dependency-Track has adopted an emerging spec called Package URL that provides a flexible way to represent metadata about components and their place in various ecosystems.

It’s highly recommended that every software component being tracked by the system have a valid Package URL.

Package URL (PURL)

Package URL was created to standardize how software package metadata is represented so that packages could universally be located regardless of what vendor, project, or ecosystem the packages belong. Package URL conforms to RFC-3986.

The syntax of Package URL is:

scheme:type/namespace/[email protected]?qualifiers#subpath

Examples:

pkg:maven/org.apache.commons/[email protected]

pkg:golang/google.golang.org/genproto#googleapis/api/annotations

pkg:gem/[email protected]?platform=java

pkg:npm/%40angular/[email protected]

pkg:nuget/[email protected]

pkg:pypi/[email protected]

Package URL and Dependency-Track

Dependency-Track uses Package URL in several ways:

Dependency-Track provides the ability to determine out-of-date components. It uses the Package URL of the component and maps it to a corresponding list of repositories that have been configured to support the components ecosystem.

Refer to Repositories for further information.

Package URL support in Bill-of-Materials

The CycloneDX BOM specification supports Package URL on a per-component basis. Users of the official CycloneDX implementations for various build systems will automatically have valid Package URLs for every component in the resulting BOM.

When importing SPDX BOM documents, Package URL identification cannot be automatically determined, although support for Package URL may be coming to the SPDX specification in a future release.

Common Platform Enumeration (CPE)

Like Package URL, the Common Platform Enumeration (CPE) specification is a structured naming scheme for applications, operating systems, and hardware.

The syntax of CPE is:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

Examples:

cpe:2.3:a:joomla:joomla\!:3.9.8:*:*:*:*:*:*:*

cpe:2.3:o:redhat:enterprise_linux_server_eus:7.7:*:*:*:*:*:*:*

cpe:2.3:h:intel:core_i7:870:*:*:*:*:*:*:*

CPE and Dependency-Track

Dependency-Track uses CPE with its internal analyzer. The internal analyzer relies on a dictionary of vulnerable software. This dictionary is automatically populated when NVD mirroring or VulnDB mirroring is performed. The internal analyzer is used by all components with valid CPEs, including application, operating system, and hardware components.

Components with a valid CPE defined, will use the internal analyzer (and optionally the VulnDB analyzer) to identify known vulnerabilities.