Every scanner you run is reading someone else's homework.
When Snyk or Wiz or Dependabot tells you a dependency is vulnerable, the severity that lands in your ticket, the vector your SLA clock runs on, and the product match that decided this CVE applies to you at all, most of it came from a National Vulnerability Database record. A small team at NIST reads the advisory, assigns the weakness class, computes the score, and writes the product applicability by hand. A few hundred tools consume that, and the rest of us argue about which findings to fix.
Almost nobody thinks about that layer until it stops.
What it has been running on
It nearly did stop.
The Commerce Inspector General published an evaluation of the NVD in May. In February 2024 the enrichment contract lapsed. The OIG's words: "a contract lapse that led to a virtual stoppage of vulnerability processing." A replacement was not in place until May, and the new analysts were not fully trained until November.
CISA had been providing roughly $3.8 million a year, about half the NVD's total budget. It did not renew for FY2024. Half the money for the database this entire industry runs on went away, and most of us found out from a banner on a website.
Submissions rose 263 percent between 2020 and 2025. The backlog went from around 13,000 records in mid-2024 to over 27,000 by the end of 2025.
They kept it running anyway. NIST enriched nearly 42,000 CVEs in 2025, 45 percent more than in any year before it. That is a team absorbing a doubled workload on half a budget.
This data has real problems. The people producing it have been doing more with less than anyone consuming it.
They are asking, and the window closes October 13
In August NIST opened a request for information on modernizing the NVD, docket NIST-2026-0100. Seven question areas: the vulnerability management lifecycle, dissemination, risk prioritization, remediation, data and standards, development processes, and where the NVD should be in five years.
The notice asks for input from "technical experts, industry and government leaders, researchers, cybersecurity professionals, and software vendors," and specifically for "technical priorities, innovative frameworks, and practical recommendations."
That is a federal agency saying in public that it does not have all the answers and would like some. It does not happen often, and the people who answer get to shape what gets built.
What we found before filing
Konvu's agents read NVD records every day and turn them into decisions a bank has to defend to an auditor. Before writing the comment we pulled the CVE Program's full published corpus and counted what is in it.
CVE Record Format 5.x has a field called configurations. The schema describes it as "Configurations required for exploiting this vulnerability." It is exactly the field you would want if you were working out whether a CVE matters in your environment. Juniper uses it properly. CVE-2018-0019 reads: "This issue only affects systems with SNMP mib2d enabled. SNMP is disabled by default on devices running Junos OS." That one sentence is the difference between a real finding and a false alarm.
It is populated in 1,211 of 360,436 published records. That is 0.34 percent.
Six organizations write 78 percent of those. The most common value, appearing in 62 records, is "No special configuration is required to be affected by this issue."
The field for the property that decides whether a vulnerability matters exists, and it is empty.
What we asked for
Six things:
- Make
configurationsstructured, and require it where the CNA already knows the answer - Attach provenance and confidence to every enrichment field, flagged where AI-generated
- Convene an evidence format extending VEX and CSAF, so the reasoning travels with the conclusion
- Publish a versioned public benchmark of CVEs with ground-truth exploitability labels
- Require abstention as a valid output of any automated determination
- Publish enrichment coverage as a rate, by publication cohort, and keep the series
Go file one
If you build anything on this data, you know something NIST does not.
You know which field your matching logic actually fails on. You know which advisory format costs you a day every time it appears. You know the query you had to write because a status meant one thing last year and something else this year. None of that reaches the docket unless somebody puts it there.
It does not have to be long and it does not have to cover all seven areas. The notice says respondents are encouraged to address "any or all" of the questions. One well-evidenced observation from somebody who runs this data in production is worth more than a comprehensive document from somebody who does not.
Go to regulations.gov, search NIST-2026-0100, and tell them the one thing you wish this data did.
You have until October 13.