CPE: Common Platform Enumeration
CPE is a standardized naming scheme for software products, operating systems, and hardware. It gives every piece of software a unique, machine-readable identifier — so vulnerability databases can say exactly which products are affected by a CVE.
What is CPE?
A universal naming standard for IT products.
When a vulnerability researcher publishes a CVE, they need to specify which software versions are affected. Without a standard format, every database would describe "OpenSSL 3.0.7" differently — some as openssl/3.0.7, others as OpenSSL:3.0.7, others as plain text.
CPE solves this by giving every product a structured identifier. The National Vulnerability Database (NVD) and Open Source Vulnerabilities (OSV) both use CPE as a common language for linking software versions to CVEs. When ScanRook finds a package in a scanned artifact, it constructs the package's CPE string and uses it to search for matching advisories.
NIST maintains the CPE Dictionary — an authoritative list of CPE names for known products. If a product is in the dictionary, its CPE is standardized and any NVD advisory that references it will use the same identifier.
CPE 2.3 Format
A colon-delimited string with 13 fields that uniquely identifies a product.
CPE 2.3 (the current version) uses a structured URI format with 13 colon-separated fields. The format always begins with cpe:2.3: followed by 11 attribute fields.
Field meanings:
- Part — What type of thing is this?
a= application,o= operating system,h= hardware. - Vendor — The organization or person that created the product (e.g.
openssl,microsoft,apache). - Product — The product name (e.g.
openssl,windows_10,httpd). - Version — The specific version string (e.g.
3.0.7,22h2). - * (wildcard) — Matches any value. Most fields other than part/vendor/product/version are set to
*for general-purpose matching.
CPE-to-CVE Lookup
How CPE strings connect software packages to vulnerability advisories.
When a vulnerability researcher publishes a CVE, the NVD record includes a list of affected CPE configurations — the specific product versions known to be vulnerable. For example, CVE-2022-0778 (OpenSSL infinite loop) lists:
cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* (versions < 1.0.2zd)
cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* (versions >= 3.0.0, < 3.0.2)To check if a package is vulnerable, a scanner:
- Extracts the package name and version from the artifact (e.g.
openssl 3.0.7). - Constructs the CPE string:
cpe:2.3:a:openssl:openssl:3.0.7:*:*:*:*:*:*:*. - Queries NVD's CPE match API: "Which CVEs affect this CPE?"
- NVD returns matching CVEs with their severity, CVSS scores, and fix versions.
OSV works similarly but uses ecosystem-specific package names (e.g. PyPI/requests, npm/lodash) rather than CPE strings for most ecosystems, then cross-references NVD CPE data for enrichment.
Interactive CPE Parser
Paste any CPE 2.3 string to see it broken into its 11 component fields.
Try editing the string below. Change openssl to any vendor you know, or change the version number. A * means "any value" — most fields are wildcarded in practice.
- Part= application
aa = application, o = operating system, h = hardware- Vendor
opensslThe organization or person that created the product- Product
opensslThe product name- Version
3.0.7The version string (e.g. 3.0.7)- Update
*An update or patch level (e.g. sp1, * = any)- Edition
*Legacy edition field from CPE 2.2- Language
*The language of the product (e.g. en, * = any)- SW Edition
*Software edition or market-specific variant- Target SW
*Target software environment (e.g. linux, windows)- Target HW
*Target hardware architecture (e.g. x86, arm)- Other
*Additional vendor-defined attributes
How ScanRook Does It
From package inventory to CPE match to CVE finding.
When ScanRook scans a container image or binary, it goes through these steps to turn detected packages into CVE findings:
ScanRook reads the container's package manager databases (RPM db, APK installed, DPKG status) and lockfiles (package-lock.json, Cargo.lock, go.sum) to build a list of installed packages with their exact versions.
All packages are sent to the OSV API in a single batch request. OSV returns matching advisories using ecosystem-native identifiers (e.g. npm/lodash, PyPI/requests, RPM/openssl). This is the fastest and broadest enrichment pass.
For packages not fully covered by OSV, or to add CVSS scores, ScanRook constructs CPE strings and queries the NVD CPE match API. NVD returns CVEs with CVSS v3.1 vectors, CWE classifications, and affected version ranges.
For RHEL-based images, ScanRook adds a third enrichment pass using Red Hat CSAF and OVAL data to surface CVEs marked 'Will not fix', 'Fix deferred', or 'Affected' — including ones NVD and OSV may not cover.
Results from all sources are merged by CVE ID and package. Duplicate findings are collapsed into a single entry that combines all evidence, takes the highest CVSS score, and flags EPSS probability and KEV status.
The CPE match step (step 3) is what bridges the gap between an installed package and the NVD's vulnerability index. Without accurate CPE construction, entire product families of CVEs would be missed. ScanRook's CPE construction logic normalizes vendor and product names against the NVD CPE dictionary to maximize match accuracy.