CPE

Common Platform Enumeration (CPE) is a structured naming scheme for IT products in cybersecurity: applications, operating systems and hardware. Version 2.3 is specified by NIST in NISTIR 7695 (August 2011). The National Vulnerability Database (NVD) uses CPE names to say which products a CVE affects, and keeps the official CPE dictionary.

The CPE 2.3 format

A CPE 2.3 name has 11 attributes after the prefix cpe:2.3: part, vendor, product, version, update, edition, language, sw_edition, target_sw, target_hw and other. The part is a for an application, o for an operating system and h for hardware. A * means any value and a - means not applicable.

cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*
cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:node.js:*:*
cpe:2.3:h:raspberrypi:raspberry_pi_4_model_b:-:*:*:*:*:*:*:*

The first is the example from the specification. The second is the npm library lodash, with node.js as the target software. The third is a piece of hardware. All three are in the NVD dictionary.

How CPE matching works, and where it goes wrong

An NVD record lists the CPEs a CVE applies to, often with version ranges. A scanner turns each component in an SBOM into a CPE guess and compares. Three things go wrong:

• Ambiguous names. The dictionary's vendor and product are not always what the package is called in its ecosystem. The xz library is cpe:2.3:a:tukaani:xz, while Debian ships it as the package xz-utils. A guess built from the package name hits the wrong product or none.
• Over-broad ranges. An applicability statement can cover versions or platforms that are not affected, for example every version of a product when only one build configuration was. Every component that matches becomes a finding to triage.
• Missing data. NIST says that "starting in early 2024, the NVD developed a significant backlog of unenriched CVEs". Since April 15, 2026 it enriches CVEs by priority (CISA KEV entries, software used by the federal government and EO 14028 critical software first) and labels the rest "Lowest Priority - not scheduled for immediate enrichment" (NIST). CVE Numbering Authorities can supply affected products, including CPEs, in the CVE record, and NVD has added that CNA- and ADP-supplied affected data to its records since June 2026, but coverage varies by CNA. The Yocto Project's 5.2 release notes put the effect plainly: with CPE-based checks, "some vulnerabilities are just not reported".

Matching the wrong product is one source of false positives; see how to reduce vulnerability noise.

CPE vs Package URL

	Package URL	CPE
Who defines the name	The package's ecosystem	NVD's CPE dictionary
Identifies	A package in a registry or distribution	A product, including hardware and operating systems
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Used by	OSV, GitHub advisories, SBOM tools	NVD, many scanners
Typical failure	Missing for vendored or hand-listed code	Ambiguous vendor and product names; no CPE data for many new CVEs

Use a package URL wherever a package ecosystem exists, a CPE for commercial products, firmware and hardware, and both where a requirement asks for both. CISA's 2026 Minimum Elements name CPE and Package-URL as common identifiers, and BSI TR-03183-2 requires identifiers such as these for each component where they exist.

CPEs in SBOMs

CycloneDX has a cpe field on each component, and SPDX carries CPEs as external identifiers. If you are a supplier, put in the CPE that NVD actually uses for your product (look it up in the dictionary) rather than inventing one: an invented CPE matches nothing. Identifiers are one part of SBOM field quality; whether anything is missing from the list is a separate question, SBOM completeness.

CRACI identifies every package a build pulls in by its package URL. See build-time SBOMs.