On May 26th, the US Department of Commerce’s Office of the Inspector General (OIG) released their audit evaluation, “Evaluation of NIST’s Management of the National Vulnerability Database”.
The National Vulnerability Database, or NVD, has been central to the entire software industry in tracking and enriching software vulnerabilities (“Common Vulnerabilities and Exposures” or CVEs) and providing data that scanners, security platforms, and compliance programs rely on to identify and prioritize risk.
If your organization relies on vulnerability scanners, CVSS scores, or automated remediation workflows, the findings in the OIG report matter. Between NIST's growing enrichment backlog and their decision to enrich significantly fewer vulnerabilities, there’s a lot here for people involved in vulnerability management to know. Security teams need to understand what is changing and where vulnerability data will come from going forward.
I’ll dig into the background, talk through where we are today, explain the practical impact on vulnerability management programs, and help lay out what you need to be thinking about. I’ll also dig into how Minimus is addressing the concerns raised by the backlog of CVE enrichment.
While a CVE report has a lot of information in it, there are three, machine-readable values that somebody has to “enrich” the report with.
The first value is the one that most people are probably familiar with, the Common Vulnerability Scoring System or CVSS score. This is a measure from 0 to 10 of the potential severity of a CVE, with 10 being the highest possible score. These are broken into severity bands (Critical: 9.0-10.0, High: 7.0-8.9, Medium: 4.0-6.9, Low: 0.1-3.9, and None: 0) making it easier to speak about vulnerabilities by broad categories of severity. For example, an organization might have a policy like “Critical CVEs on sensitive systems must be patched or mitigated within 14 days of a fix being available.”
The second value, Common Platform Enumeration (or CPE), is talked about less frequently but is possibly more important for vulnerability management because it determines whether a vulnerability actually applies to a particular piece of software.. A CPE is a machine-readable string, for example:
cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:* From (including) Up to (excluding)
2.0.1 2.3.1
This is one of the CPEs for CVE-2021-44228 and it tells us that this applies to versions of Apache log4j between version 2.0.1 and up to (but not including) version 2.3.1. CPEs are used for scanning assets for vulnerabilities to determine if a particular CVE applies – if log4j v2.3.0 is in the bill of materials, we know CVE-2021-44228 applies.
The third machine-readable attribute that will be enriched is a Common Weakness Enumeration, or CWE. CWEs are standard identifiers for the weaknesses that result in vulnerabilities. This will tell us that a particular CVE is caused by improper input validation (CWE-20), for example.
Traditionally, NIST was responsible for enriching all new CVEs and adding CVSS, CPE, and CWE values to each report. Unfortunately, as the OIG report tells us, “In February 2024, NIST’s NVD program experienced a contract lapse that led to a virtual stoppage of vulnerability processing, resulting in an unprecedented backlog.”
While various promises were communicated through 2024 and 2025, NIST continued to slip further behind on the backlog over the intervening years.
On April 15th, 2026, NIST announced major changes to what it will and, more importantly, will not enrich, reducing its mission to only cover a fraction of all vulnerabilities:
“Starting on April 15, 2026, we will prioritize the following CVEs for enrichment:
At first glance, the fact that NIST is no longer enriching all new CVEs appears to be bad – won’t most CVEs end up without enrichment?
Well, not exactly. The industry has been dealing with this problem since early 2024 and, while the current state is not perfect, it is largely functional. As NVD fell behind on enrichment, the CVE Numbering Authorities, or CNAs, began to fill the gap.
CNAs are the organizations that submit CVEs initially and, since they are closer to the source of the vulnerability, many of them are well-qualified to enrich new vulnerabilities to ensure that quality, machine-readable metadata is available. Jerry Gamblin’s CNA Scorecard shows that ~89% of new CVEs (published in the last six months) have CVSS scores and ~90% have CWEs. CPEs have lagged behind, with only ~16% coverage from the CNAs.
Thankfully, though, CNAs aren’t the only source of additional enrichment data. CISA-ADP is the Authorized Data Publisher that the US Cybersecurity and Infrastructure Agency (CISA) runs to further enrich CVEs. While the OIG’s report finds that there’s been some overlap between NIST’s enrichment and CISA-ADP’s, the work that CISA-ADP does is incredibly valuable in filling in gaps in metadata. Additional data providers, in the pilot Supplier Authorized Data Publisher program, are coming online and, I expect, will provide additional value to downstream consumers.
Finally, the vulnerability scanners (whether free/open source like Trivy & Grype or commercial products like Snyk & Wiz) have worked hard to fill gaps in detections and companies like Vulncheck have built both free & paid extensions to the metadata in NVD.
Let’s not panic but, if your vulnerability management program is mission critical, you should definitely have some questions.
The first question is, “Does my vulnerability scanner have accurate CVSS scores?” Before the NVD apocalypse, most scanners only used the NVD scores. In the intervening years, almost all have moved to using NVD, CISA-ADP, and CNA in a blended fashion.
You’ll want to make sure, first, that you don’t have a lot of new CVEs showing up with an “Unknown” severity because NVD hasn’t enriched the CVE. After that, make sure you understand how the scanner chooses which score to use and ensure that the algorithm works for your needs (or that all scores are made available).
The second question is, “Is my vulnerability scanner finding everything?” This is much harder to test as false negatives are hard to find. I would suggest auditing scans for selected new CVEs to ensure things you know should be found, are found, and, if practical, periodically comparing the outputs of different vulnerability scanners. For commercial products, work with support teams to understand discrepancies and, for open-source products, contribute and collaborate on fixes for issues you find.
With Minimus’s roots in Twistlock, we were already well-versed in the complexity of CVE data and we were tracking the changes in NVD’s data enrichment along with larger changes in software vulnerabilities.
We anticipated this and were ready. We've always used a combination of CVSS scores from NVD, CNAs, and CISA-ADP to ensure the most accurate data. We consume data that has enhancements to detection that help ameliorate the gap in CPEs, and we're continually working to find issues and address them.
.svg)
.svg)
.svg)
.svg)
