Understanding the NVD and CVSS v3.1 Scoring
The National Vulnerability Database (NVD) is the most widely referenced source for CVE details and severity scores. This article explains how the NVD works, what CPE matching means, and how CVSS v3.1 scoring is structured.
What Is the NVD?
The National Vulnerability Database is maintained by NIST (the National Institute of Standards and Technology). It is the U.S. government's repository of standards-based vulnerability data. The NVD does not discover vulnerabilities itself. Instead, it enriches CVE records published by CVE Numbering Authorities (CNAs) with additional analysis, including CVSS scores, CPE applicability statements, and references.
Every CVE published by a CNA eventually appears in the NVD, where analysts add structured data about which products are affected (using CPE URIs), how severe the vulnerability is (using CVSS), and what references are available (patches, advisories, exploits).
CPE Matching: How the NVD Identifies Affected Software
CPE (Common Platform Enumeration) is a structured naming scheme for software products. A CPE URI looks like:
cpe:2.3:a:openssl:openssl:3.0.2:*:*:*:*:*:*:*This URI encodes the vendor ("openssl"), the product name ("openssl"), and the version ("3.0.2"). NVD analysts attach CPE configurations to each CVE record, specifying which product versions are affected, sometimes with complex AND/OR logic for multi-product vulnerabilities.
The challenge with CPE matching is ambiguity. Product names in CPE are not always identical to package names in a distribution's package manager. The package "libxml2" in Debian might map to a different CPE product string than expected. This is why scanners that rely solely on CPE matching can produce false positives -- the product name mapping is imperfect.
ScanRook addresses this by using ecosystem-native matching via the OSV API as the primary enrichment source, then supplementing with NVD CPE matching for additional coverage. Findings from CPE-based matching are classified with lower confidence when the package coordinate does not match precisely.
CVSS v3.1: How Severity Scores Work
The Common Vulnerability Scoring System (CVSS) is a framework for rating the severity of vulnerabilities. Version 3.1 is the most widely used. A CVSS v3.1 base score ranges from 0.0 to 10.0 and is derived from eight metrics organized into two groups:
Exploitability Metrics
- Attack Vector (AV) -- Network, Adjacent, Local, or Physical
- Attack Complexity (AC) -- Low or High
- Privileges Required (PR) -- None, Low, or High
- User Interaction (UI) -- None or Required
Impact Metrics
- Confidentiality (C) -- None, Low, or High
- Integrity (I) -- None, Low, or High
- Availability (A) -- None, Low, or High
- Scope (S) -- Unchanged or Changed
These metrics combine into qualitative severity ratings: None (0.0), Low (0.1--3.9), Medium (4.0--6.9), High (7.0--8.9), and Critical (9.0--10.0). A CVSS score of 9.8 typically means the vulnerability is network-exploitable, requires no authentication, and allows full system compromise.
The Limitations of CVSS Alone
CVSS scores are useful for understanding the theoretical severity of a vulnerability, but they do not account for real-world exploit activity. A vulnerability with a CVSS score of 9.8 may never be exploited in the wild, while a 7.0-scored vulnerability might be actively weaponized. This is why modern vulnerability management increasingly supplements CVSS with exploit prediction data like EPSS and active exploitation catalogs like the CISA KEV.
ScanRook includes CVSS scores from the NVD in every finding, but also enriches findings with EPSS probability scores and CISA KEV status to give security teams better prioritization signals. Learn more in the enrichment documentation.
NVD API Rate Limits and Caching
The NVD API has rate limits that affect scanner performance. Without an API key, requests are limited to approximately 5 per 30-second window. With a free NVD API key, the limit increases to 50 per 30-second window. For scanners processing hundreds of packages, caching is essential to avoid hitting these limits on repeated scans.
ScanRook implements a multi-layer caching strategy: a local file cache for individual developer workstations, PostgreSQL for persistent team-wide caching, and Redis for high-throughput multi-worker deployments. This ensures that NVD data is fetched once and reused across scans, reducing both API pressure and scan latency.
How ScanRook Uses the NVD
In ScanRook's enrichment pipeline, the NVD is queried after OSV. For each package in the scan inventory, ScanRook first checks OSV for ecosystem-native matches. Then it queries the NVD using CPE product matching to find additional CVEs that may not yet appear in ecosystem-specific advisory databases. The results are deduplicated and merged into a single findings list, with CVSS scores attached to every finding that has NVD coverage.