In depth
The Common Platform Enumeration (CPE) is the structured naming scheme NIST uses to uniquely identify a hardware or software product so that CVE records can be deterministically matched against deployed inventory. A CPE 2.3 identifier is a colon-delimited URI of the form cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other — for example, cpe:2.3:a:nginx:nginx:1.24.0:*:*:*:*:*:*:* identifies version 1.24.0 of the nginx web server.
The official CPE Dictionary is maintained by NIST and contains over 300,000 entries. New entries are added when an NVD analyst processes a CVE that affects a previously unenumerated product, or when a vendor proactively contributes their product taxonomy. CPE underpins almost every automated CVE-to-asset matching pipeline: the SCA tool reads the project's SBOM, maps each component to its CPE, queries the NVD for matching CVEs, and emits the actionable subset.
CPE has well-known limitations. The naming taxonomy was designed before the explosion of cloud-native software and does not capture concepts like container images, Helm charts, or SaaS-tenant versions cleanly. Vendor-name inconsistencies (Cisco vs. cisco_systems, RedHat vs. red_hat) plague the dictionary. Version-range expression is awkward — NVD analysts work around this with versionStartIncluding / versionEndExcluding fields, but matching still produces both false positives (CVE listed against "nginx 1.x" matches all 1.x versions including patched ones) and false negatives (vendors rename products between major versions).
The modern complement to CPE is PURL (Package URL), a more lightweight identifier popular in the open-source ecosystem (pkg:npm/express@4.18.2). CSAF documents typically include both CPE and PURL for each affected product so consumers can match using whichever identifier their tooling supports. For practitioners, the right model is to generate an SBOM that includes both CPE and PURL, and run cross-referenced matching against NVD and OSV.dev. See VAPT services.
The official CPE Dictionary is maintained by NIST and contains over 300,000 entries. New entries are added when an NVD analyst processes a CVE that affects a previously unenumerated product, or when a vendor proactively contributes their product taxonomy. CPE underpins almost every automated CVE-to-asset matching pipeline: the SCA tool reads the project's SBOM, maps each component to its CPE, queries the NVD for matching CVEs, and emits the actionable subset.
CPE has well-known limitations. The naming taxonomy was designed before the explosion of cloud-native software and does not capture concepts like container images, Helm charts, or SaaS-tenant versions cleanly. Vendor-name inconsistencies (Cisco vs. cisco_systems, RedHat vs. red_hat) plague the dictionary. Version-range expression is awkward — NVD analysts work around this with versionStartIncluding / versionEndExcluding fields, but matching still produces both false positives (CVE listed against "nginx 1.x" matches all 1.x versions including patched ones) and false negatives (vendors rename products between major versions).
The modern complement to CPE is PURL (Package URL), a more lightweight identifier popular in the open-source ecosystem (pkg:npm/express@4.18.2). CSAF documents typically include both CPE and PURL for each affected product so consumers can match using whichever identifier their tooling supports. For practitioners, the right model is to generate an SBOM that includes both CPE and PURL, and run cross-referenced matching against NVD and OSV.dev. See VAPT services.