CVE, CWE and CPE Guide: How Vulnerabilities, Weaknesses and Products Are Identified

CVE is the global identifier for a specific publicly disclosed vulnerability, CWE is the catalogue of the underlying weakness types that cause vulnerabilities, and CPE is a structured name for the affected product. Put simply, CVE says "this flaw in this software", CWE says "what kind of mistake it is", and CPE says "which product and version". Almost every scanner, advisory, SBOM tool and patch dashboard depends on these three identifiers, and most of the confusion in vulnerability management comes from mixing them up or trusting the data behind them too much. This guide explains each one in plain language, how a CVE record is created and enriched, how CPE compares with Package URL (PURL), how CVSS, EPSS, KEV and CAPEC attach to them, and what changed with the NVD backlog. It is written for vulnerability analysts, developers and anyone who reads or builds vulnerability data feeds.

Key takeaways

• Three questions, three identifiers: CVE identifies a vulnerability instance, CWE classifies the weakness behind it, and CPE (or PURL) identifies the affected product.
• The CNA owns the record: CVE records are written by CVE Numbering Authorities in the CVE JSON 5 format, and others such as CISA add data in separate ADP containers without overwriting it.
• NVD is an enricher, not the source: since early 2024 NVD has not enriched every CVE, and from April 2026 it prioritises KEV, federally used and critical software, so many CVEs will have no NVD CPE or score.
• Product matching is the weak link: CPE names are often missing or inconsistent, and PURL is the better identifier for open source packages in SBOMs and dependency tools.
• Severity is not priority: CVSS describes severity, EPSS estimates likelihood of exploitation, and KEV records confirmed exploitation. Use them together.

What it is

The CVE ID pattern in the official schema is CVE-, a four-digit year, then a number of 4 to 19 digits. The schema notes that the year is the year the vulnerability was discovered or the year the ID was published, not the year of the bug itself, so a CVE-2025 ID can describe code written a decade earlier.

How it works

The CVE record lifecycle

1. Reservation: a researcher or vendor reports a flaw to the CNA whose scope covers the product (usually the vendor itself, an open source foundation or a national CERT). The CNA reserves an ID. The Log4Shell record, for example, shows the Apache CNA reserved CVE-2021-44228 on 26 November 2021.
2. Publication: once the issue is disclosed, the CNA publishes the record. The CNA container must include provider metadata, a description, the affected products and references, and can include problem types (CWE), metrics (CVSS v4.0, v3.1, v3.0, v2.0 or other), workarounds, solutions, exploits, a timeline and credits. Log4Shell was published on 10 December 2021.
3. Enrichment by ADPs: Authorized Data Publishers add their own containers. CISA's Vulnrichment programme adds SSVC decision points (Exploitation, Automatable, Technical Impact) and, where evidence allows, CWE and CVSS, and its documentation states it never overwrites the CNA's data. The current Log4Shell record carries both a "CVE" ADP container and a "CISA-ADP" container.
4. Downstream enrichment: NVD, vendors and scanners add CPE applicability, their own scores and references. These are copies with their own timing and quality, not part of the authoritative record unless added through the CVE Program.
5. Updates or rejection: records are updated as fixes and new versions appear. A record can move to the REJECTED state, for example when it was a duplicate or not a vulnerability; rejected IDs should be removed from tracking, not left as open findings.

The CVE JSON 5 product block

CVE 5.0 simplified product data. Each entry in affected can carry vendor, product, collectionURL and packageName (for package registries such as npm or PyPI), a list of cpes in CPE 2.2 or 2.3 format, modules, program files, platforms, a source repo, and a versions array with ranges and status values such as affected and unaffected. Later schema versions added packageURL; the schema says a PURL in this field must not include a version, because versions are expressed in the ranges. Records published by CNAs vary widely in how fully they fill these fields.

CWE: from bug to weakness class

CWE entries form a hierarchy. CWE-338 (Use of Cryptographically Weak PRNG), for example, is a child of CWE-330 (Use of Insufficiently Random Values). A CVE record's problemTypes lists one or more CWE IDs; Log4Shell lists CWE-502, CWE-400 and CWE-20. MITRE's annual CWE Top 25 ranks weaknesses by how often and how severely they appear in CVE records. The 2025 list, based on 39,080 CVE records, is led by:

The KEV column shows why frequency and danger differ: cross-site scripting tops the list on volume, while OS command injection and memory safety weaknesses dominate confirmed exploitation. See the CWE Top 25 Guide.

CPE and PURL: naming the product

CPE 2.3 is defined by NISTIR 7695 (August 2011). The formatted string has eleven attributes after the prefix: part (a application, o operating system, h hardware), vendor, product, version, update, edition, language, software edition, target software, target hardware and other, with * meaning any. NVD uses CPE match criteria and version ranges to say which configurations a CVE affects.

Package URL (PURL) takes a different approach for software packages: pkg:type/namespace/name@version?qualifiers#subpath, for example pkg:pypi/[email protected] or pkg:deb/debian/[email protected]?arch=i386&distro=jessie. Its core syntax is standardised as ECMA-427, it is the component identifier in CycloneDX and SPDX SBOMs and in OSV, and it was added to the CVE Record Format in v5.2.0.

Decision guidance: match open source dependencies by PURL from your SBOM and use CPE for infrastructure, operating systems and commercial products. Large estates usually need both, plus a normalisation layer that maps internal asset records to each. A small organisation can rely on its scanner's matching but should spot-check that critical products actually appear in it. See the SBOM Guide.

Why it matters

• Shared language: a CVE ID lets a vendor advisory, a scanner finding, a KEV entry and a ticket refer to the same thing. CISA's KEV catalogue (1,756 entries in the 23 October 2026 catalogue version used for this guide) is keyed by CVE ID and also records CWE IDs.
• Coverage depends on enrichment: NIST states that from early 2024 the NVD built a significant backlog of unenriched CVEs, with submissions up 32% in 2024. In April 2025 it marked unenriched CVEs published before 2018 as Deferred. On 15 April 2026 it announced risk-based operations: CVE submissions rose 263% from 2020 to 2025, NVD enriched nearly 42,000 CVEs in 2025, and enrichment now prioritises KEV CVEs (with a goal of one business day), software used by the federal government and critical software under EO 14028. Other CVEs are labelled lowest priority, backlogged CVEs published before 1 March 2026 moved to "Not Scheduled", and NVD no longer routinely adds its own score where the CNA has provided one. Tools that depend only on NVD CPE data will miss matches for many new CVEs.
• Prioritisation needs more than severity: CVSS (in the record's metrics) describes how bad a flaw is; EPSS from FIRST publishes, every day for every CVE, a probability that it will be exploited in the next 30 days; KEV confirms exploitation; SSVC turns these into a decision. See the CVSS v4 Guide, the SSVC Guide and the Vulnerability Prioritisation Guide.
• Prevention uses CWE: grouping findings by CWE shows which mistakes your teams repeat, which feeds secure coding training, SAST rule selection and design reviews.

Putting it to work

1. Ingest the source of truth: consume CVE records directly (the CVEProject cvelistV5 repository or CVE Services) as well as NVD, so CNA-supplied CVSS, CWE and product data is available even when NVD has not enriched a record.
2. Add exploitation signals: join KEV and EPSS by CVE ID, and read CISA ADP SSVC values where present.
3. Fix asset identity: generate SBOMs with PURLs for applications and keep CPE-mapped inventories for platforms; measure how many assets have a usable identifier.
4. Pilot and compare: run the enriched pipeline alongside the existing scanner for a month and compare findings on a sample of recent CVEs before switching dashboards; keep the old feed available to roll back.
5. Feed CWE back to engineering: report top CWEs per product team each quarter.

What to measure

• Percentage of assets with a valid PURL or CPE identifier.
• Percentage of new CVEs affecting your estate that were matched without NVD CPE data (via CNA data or PURL).
• Median time from KEV addition to detection of affected assets.
• Share of open findings with a CWE assigned, and the top five CWEs by team.
• Number of open findings tied to REJECTED CVE IDs (should be zero).

Common misconceptions

• "No CVE means no vulnerability": many flaws, especially in SaaS services and misconfigurations, never receive a CVE, and some CNAs do not issue CVEs for issues fixed server-side. Vendor advisories still matter.
• "NVD is the CVE database": the CVE Program publishes the records; NVD is one enricher, and its 2026 prioritisation means a CVE can sit with no NVD CPE or score indefinitely.
• "The CVSS base score is the risk": it ignores exploitation and your environment. Combine with EPSS, KEV and asset context.
• "A CPE match means affected": CPE applicability is often broad (all versions of a product) or incomplete, which produces false positives and false negatives. Check the version ranges in the CNA record and the vendor advisory.
• "CWE is a severity rating": CWE says what kind of weakness it is, not how serious a specific instance is. CWE-79 ranks first in the Top 25 but has few KEV entries.
• "The CVE year is the disclosure year of the bug": it is the discovery or publication year of the ID, not when the code was written.

Related concepts

For the full process around these identifiers see the Vulnerability Management Guide, the How to Read a CVE Advisory Guide and the CVE Programme and NVD Backlog Guide.

Practitioner checklist

• Ingest CVE records from the CVE Program as well as NVD, and read both CNA and ADP containers.
• Do not rely on NVD CPE data alone for matching new CVEs; use CNA product data and PURLs.
• Generate SBOMs with PURLs for every built application and keep them with the release.
• Map platforms and commercial products in the asset inventory to CPE names and review gaps.
• Join KEV, EPSS and SSVC by CVE ID before prioritising; do not sort by CVSS alone.
• Close or suppress findings tied to REJECTED CVE IDs automatically.
• Report the top CWEs per team quarterly and use them to tune SAST rules and training.
• Track the vendor advisory, not only the CVE, for products where CVE coverage is thin.

Standards and references

• CVE Program: CVE JSON Record Format (cve-schema)
• NIST: National Vulnerability Database news and operations updates
• MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses
• NIST: IR 7695, Common Platform Enumeration Naming Specification Version 2.3
• Package URL: purl specification (ECMA-427)
• CISA: Vulnrichment, CISA ADP enrichment of CVE records
• FIRST: Exploit Prediction Scoring System
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Vulnerability Management Guide · Risk-Based Vulnerability Management Guide · Vulnerability Scanning Guide · SBOM Guide · Zero-Day and Exploited Vulnerabilities Guide