The last two years of the National Vulnerability Database (NVD) has been tenuous, perfidious, and an outright disaster for organizations world-wide. That isn’t hyperbole unfortunately, as the program has continued to go downhill for more than two years. NVD is no longer a place to get usable vulnerability intelligence. It started back in 2024 at VulnCon, when Tanya Brewer shared an update during a talk on the state of NVD. She gave the crowd assurances that did not come to fruition. It’s no surprise since a 2024 Freedom of Information Act (FOIA) request for the contract financials for ANALYGENCE (now operating as Tharros) who were performing the enrichment for NIST. This showed me that they were not using their considerable budget wisely.
In April, 2026 the NVD literally threw in the towel, giving up on doing enrichment for a vast majority of vulnerabilities. This was the lynchpin for many organizations’ attempts to do vulnerability triage. Without NVDs enrichment, there is a lack of programmatically using the data putting more burden and strain on triage efforts. After that announcement the world was left with what I dubbed a shell game and “Schrödinger’s enriched vulnerability”. Two months after throwing in the towel, the Office of the Inspector General (OIG) at the Department of Commerce released an audit report and summarized their findings:
What We Found
• NIST’s lack of strategic planning and decisive action have allowed the backlog of unprocessed vulnerabilities to continue growing.
• NIST must improve the efficiency of enrichment processes to ensure sustainability. We estimate that NIST could put approximately $800,000 to better use over the next 2 years.
• NIST and the Cybersecurity and Infrastructure Security Agency are operating two vulnerability enrichment programs with significant overlap, which has led to duplicated efforts and wasted approximately $200,000 since May 2024.
• NIST’s insufficient communication has frustrated stakeholders and decreased confidence in the NVD
The NVD is clearly not capable of handling human-based vulnerability disclosures for the last few years. As of a few months ago, we finally saw the start of what we knew was coming; a huge uptick in disclosures thanks to the use of large language models (LLM), or most often referred to as so-called “AI”. For ease of reading, I will use AI without quotes in this article but it absolutely isn’t actual AI they are talking about, rather the LLM-based problem solving. Here are two examples to demonstrate that increase:
As I write this, the August 18 Oracle CPU has 889 missing indicating another huge jump from the prior average showing the past few months are not a fluke. Note that Oracle CPUs in the last few years tended to average closer to 400 vulnerabilities, but a majority of those were previously disclosed vulnerabilities in Oracle’s software or most often third-party libraries used by Oracle products. Just these two companies graphed over one year shows the sharp rise in disclosures with many attributed to LLM products or the teams using them.
Now, NVD is asking how after all their failures for years, despite a ridiculous budget, they are going to handle this new AI wave. NIST thinks that by asking random people 30 questions that they will gain the insight they need to address what is coming. While there are a lot of InfoSec folks that can speak to some of this, NIST misses the point here. They are not qualified to run their own database and they don’t seem to realize it. Normally I would be very supportive of a U.S. government agency reaching out to stakeholders to seek input if it was under different circumstances. But this is the lynchpin for organizations throughout the entire world.
NIST asking these questions is a clear warning sign that even if the best minds answer the questions, which I have not read up to this point, there is no guarantee they will follow the guidance and implement solutions to address the problem. That said, I strongly encourage anyone that does vulnerability management, and more importantly, anyone that helps run a VDB that isn’t VulDB (not to be confused with VulnDB), answer them. They desperately need all the help they can get since they aren’t equipped to manage a VDB.
Brief Interlude – “VDB that isn’t VulDB (not to be confused with VulnDB)” If that isn’t a clusterbomb of acronyms and confusion, I don’t know what is.
As stated above, this is absolutely true and sincere. I did a quick count of questions but have not actually read any of the questions until now. So your mileage may vary and who knows, maybe NIST will be on point and ask some very nuanced questions that show expertise in a domain and not just looking for more nuanced input. I mean, we all know that isn’t likely to be the case but if it is I will give them credit where due. Otherwise, my answers will be hopefully helpful but also mixed with a dose of snark.
NVD’s RFI
On August 12, a Request for Information (RFI) on “Modernizing the National Vulnerability Database in the Age of Artificial Intelligence” was published. The survey, details, and instructions can be found here.
SUMMARY:
The National Institute of Standards and Technology (NIST) established and operates the National Vulnerability Database (NVD), which provides the U.S. government repository of standards-based vulnerability management data. NIST seeks stakeholder input on opportunities, challenges, and priorities for modernizing the NVD in an evolving cybersecurity landscape increasingly shaped by artificial intelligence (AI) and machine-consumable security data. NIST’s goal is to improve the NVD’s scalability, automation, interoperability, transparency, and utility.
Please note, these questions are framed in the context of “modernizing the NVD” which is an important distinction. It better helps us understand how qualified or detached the NVD staff are from the reality of this project. Further, any of my feedback around using AI in any capacity is predicated on it being set up correctly. Poorly configured prompting creates trash-in and expectedly trash comes out.
(1) Vulnerability Management Process
a. Where in today’s vulnerability management lifecycle (e.g., identifying, validating, disclosing, disseminating, prioritizing, remediating) are the biggest bottlenecks that could be improved with greater AI-enabled automation?
First, NVD receives all of the base data from MITRE. That means the description and initial references, at the minimum, come from them. Right out of the gate, that tells us that “identifying, validating, and disclosing” are unrelated to NVD’s processes. Disseminating is arguable since NVD itself is one place the information is disseminated but really if it were to be included I think it should be framed around NVD’s dissemination of their final product, more on that later. One might equally argue that it speaks to the researcher, aggregator feeds, news outlets, and others getting word out about the vulnerability and should not be included. I’ll give them the benefit of the doubt and include “disseminating” in a more accurate reframing of the original question.
Second, the single biggest thing that NVD has historically done is missing from this list; enriching. NVD creates metadata that makes the vulnerability information usable via the generation of Common Platform Enumeration (CPE) strings and Common Vulnerability Scoring System (CVSS) scores. This was also the single bottleneck that led NVD to throw in the towel, yet it is ironically and suspiciously missing. Third, once that data is enriched it is up to security teams that ingest NVD data to handle the prioritizing and remediating, which means those two should be removed from the list.
Now, in that more narrow and accurate context, it leaves the unmentioned enrichment as well as dissemination. Both are bottlenecks but one is much more important; enrichment. This is really where NVD broke down despite throwing ridiculous amounts of money at the problem. That means that the introduction of “AI” is best suited for enriching data by more automatically generating CPE and CVSS scores. This would also allow the expansion to start including CVSSv2/v3/v4 scores to better assist organizations around the world as there is no version universally used.
Speaking to the problem of NVD’s dissemination, that comes in the form of their API routinely having slowdowns or long instances of the API not being available. That is an engineering problem that has nothing to do with AI. So the final answer to this question is simply “enrichment”, the one thing not included in NVD’s examples of the process of disclosure. This is what I mean about an apparent lack of expertise going into what they do.
b. Which tasks are most appropriate for AI-enabled automation? Which tasks should require human review? For tasks requiring human review, what information is needed, and how can reviews be arranged to both minimize time spent and avoid over-reliance on AI?
This question reminds us there are two realities at play. The first reality is that all steps of vulnerability enrichment should be curated by qualified humans. That is the only way to better guarantee the data is accurate. Using AI, even reviewed by humans, is less likely to be as accurate as pure human analysis done properly. That means all enrichment goes through at least two people: an analyst and someone doing quality assurance (QA).
The other reality is that no VDBs are currently staffed properly. I say that fairly confidently because any form of automation wouldn’t be needed technically. Most VDBs are using some form of automation regardless of it being AI related or not. In this case it is clear that NVD is living in the second reality but more so than other VDBs.
Speaking in the context of NVD performing two of the most fundamentally required enrichments, CPE and CVSS, then I feel that CVSS should mandate human review. Portions of CVSS scoring can be automated where one metadata point that is generated can directly correspond to another. That would allow filling in parts of a score with a human fling in the rest and validating the complete score. CVSS is still used heavily for triage and prioritization which can have the biggest impact for a vulnerability management program.
CPE scoring I feel is much more suited to AI since a majority of that will be much easier to do based on matching to the official CPE dictionary maintained by NVD as well as prior enrichment data. For cases where a new CPE vendor or product is needed, then AI I feel is relatively well suited to do the generation. Security teams should have automation that validates CPE data in place already so supplementing those rules and logic with a few additional rules around data that hasn’t been seen before can better direct per-organizational processes around if their own QA should be present.
Speaking to what information is needed for tasks requiring human review, unfortunately the answer is the single source of truth (SSoT); who has the most definitive knowledge of the vulnerability that disclosed it. That might be the security researcher who found the vulnerability instead of the vendor, if one advisory is considerably more detailed. The last bit of this question are actually really interesting and would allow a more formal implementation of something VulnDB has informally used for two decades.
“How can reviews be arranged to both minimize time spent and avoid over-reliance on AI?” I won’t take the time to generate these statistics so anecdotally I will say that across all disclosures, the instances where a researcher or vendor has disclosed more than one vulnerability is considerable. Creating a confidence score for both researchers and vendors is the past to answering NVD’s question. As humans analyze disclosures, taking note of which ones are reliable is the start. Some researchers have frequent errors in their disclosures and some vendors frequently have one aspect of their advisories that are incorrect (e.g. CVSS scores).
These are data points you can use to determine if a party is occasionally, sometimes, frequently, or always accurate. That system should really be more granular than four ratings, but it presents the ideas neatly. Over time this creates a great weighting system that better informs when AI can be more safely used or when a human must most often be part of the metadata generation or QA process.
c. What are the novel governance and risk management considerations that should be taken into account in modernizing the vulnerability management ecosystem?
This question is baffling as it extends so far beyond “Modernizing the National Vulnerability Database in the Age of Artificial Intelligence” it is ridiculous. Entire books can be written on this single question. As such, I am not wasting my time with this one since it does not really pertain to the NVD overhaul needed.
d. What other actions could NIST and others involved in the vulnerability management process take to improve vulnerability management processes?
Again, this is too broad and any such answer must be around NIST’s involvement, not “and others”. As far as NIST goes, the best way they could really improve the CVE ecosystem (rather than the broader “vulnerability management processes”) requires more agency in said ecosystem. Since MITRE has done a negligible amount of work in ensuring accurate data from CVE Numbering Authorities and held them to virtually no account, NIST is actually in a better position to do so for two reasons. However, right now NIST is a cog in the wheel with MITRE driving.
First, as mentioned, MITRE doesn’t do it when they absolutely should. Ignore their silly little “CNA scorecard”, if they are still doing that. Second, the NVD with a confidence score is ideally suited to also act as an actual CNA scorecard to better hold them accountable for accurate data. If the CNAs, often the SSoT, produce more reliable data then the NVD can trust it more and allow more automation and AI involvement while reducing the QA needed.
In an ideal world, NVD’s initial ingestion of MITRE’s CVE data should be the first QA process. CVEs that come with anemic descriptions or longer descriptions with obviously contradicting or incomplete data should be rejected outright. MITRE’s input should be regulated by NVD, which would be a radical change from how the CVE ecosystem currently operates. Forcing bad data to be corrected by MITRE or their CNAs is desperately needed regardless of AI involvement.
(2) Vulnerability Information Dissemination
a. What capabilities, products, and processes, AI or otherwise, are needed to improve the responsible and timely dissemination of vulnerability information to technology developers and the broader community of affected stakeholders?
As stated previously, the NVD must operate an API to deliver the enriched CVE feed to stakeholders with 99.999% availability (aka the “five nines” mnemonic). As organizations that relied on hourly updates from a vulnerability intelligence provider move to more AI-based automation and the volume of vulnerabilities goes up significantly, requiring more and more frequent polling for updates is to be expected. The infrastructure to support that must scale.
b. What existing standards and technical guidelines are most helpful for disseminating vulnerability information? What gaps in standards and guidelines exist? How should addressing those gaps be prioritized?
I don’t think the problem centers around lack of standards, rather the opposite. There are many that are currently used. Asking about identifying the gaps makes me worry NVD would try to “solve” that problem by introducing yet another. Instead, since a majority of the fields in these standards are common among all of them, focus on quality data. Then deliver the top three or five most used based on a survey of stakeholders. Planning to support Vulnerability Exploitability eXchange (VEX) / OpenVEX, Common Security Advisory Framework (CSAF), Vulnerability Disclosure Report (VDR), and a native NVD-based XML and JSON feed that contains all of them fields and metadata they handle is warranted. After supporting one, the lift to supporting each subsequent standard should get easier.
c. What other actions could NIST and others involved in the vulnerability management process take to improve vulnerability information dissemination?
AI isn’t even needed, rather, a plugin or utility to invoke Google Translate would allow you to deliver vulnerability descriptions in additional languages. This would be helpful in further broadening international support for NVD. It might also make inroads into working more closely with foreign Computer Emergency Response Teams (CERT) and Software Incident Response Team (SIRT) maintained at the country level. That in turn could lead to more information shared back to NVD to be normalized and redistributed.
(3) Risk Assessment and Prioritization
a. How can the use of AI or other automated mechanisms improve contextual risk prioritization? What data sources and information should be considered by NIST to inform prioritization decisions?
This is a difficult question, one that many startups have tried to answer and more startups appear every month it seems. Using LLMs that are more coding-centered can be used to determine what paths are available to exploit a vulnerability. In doing that, it can surface additional contextual information such as if authentication is required, non-default functionality must be enabled, etc.
For NVD to do this and provide value, they would require the ability to more directly be part of the processes around updating a CVE description, or create additional fields that NVD currently does not, and deliver via the NVD web site and API.
b. How might transparency and auditability in AI-driven prioritization decisions be enhanced?
Enhanced implies there is transparency and auditability to begin with, when there is not. In the last two years NVD has famously shown a lack of transparency around their backlog for example. Language matters and this is not the forum to mis-advertise what NVD currently does.
Start by being more transparent around any and all NVD processes. Establishing more trust with the broader security community, many that fund NVD via their tax dollars, only helps. Specific to AI, publishing the prompts and models being used for any given functionality should be mandated. That information must be updated routinely, as warranted, as the LLM world changes quickly.
c. What data and system context is needed by organizations to prioritize vulnerabilities accurately in production environments?
Accurate affected and not-affected products, delivered via a standard format. While that is technically done, for the most part, the current situation with NVD’s control over the CPE dictionary has long been untenable in this industry. NVD’s lack of timely updates as well as not maintaining a community driven CPE dictionary has led people to alternate solutions. However, those frequently cause issues as external parties must attempt to guess what a CPE string will be long before NVD eventually makes one, if they do at all.
Vendor, product, and versions are mandatory for the prioritization process. It’s also critical that versioning be handled correctly which means no broad assumptions like “all prior versions” are vulnerable when that is often not the case. That is a pattern of NVD’s that must stop. Beyond that, authentication requirements and if the vulnerable functionality is part of a default installation or not is key in generating a proper CVSS score, which in turn better guides prioritization efforts. Finally, there are a considerable number of CVE IDs that cover issues that are demonstrably not vulnerabilities at all. This can often be determined without testing the vulnerability in a virtual environment, rather, just from reading the original disclosure and applying better standards for CVE entry quality.
d. How can the NVD improve interoperability and integration with other vulnerability management ecosystem components (e.g., vulnerability disclosure programs, vendor advisories, threat intelligence providers, asset management platforms, security tool vendors, remediation workflows) to enable more timely, accurate, actionable and contextual vulnerability management?
As stated above, delivering vulnerability data in a variety of forms as well as languages is perhaps the easiest lift while potentially achieving that goal. Beyond that, unfortunately NVD is not in the right place within the CVE ecosystem to facilitate that without structural changes to how MITRE and NVD operate. The current process has data originating with MITRE then being partially enriched by NVD and partially by Cybersecurity and Infrastructure Security Agency (CISA). This fractured process introduces delays and contradictions. The entire CVE process should be folded into a single agency to do all assignments, CNA minting, and enrichment efforts. This must be guided by people that are familiar with the VDB landscape, which is not MITRE unfortunately.
NVD’s data can be trivially integrated as is and that is not the current problem other than API reliability. Speaking of interoperability, that question should focus on how NVD can more easily contribute to the base CVE data without relying on MITRE. That doesn’t just mean fixing a typo in a CVE description. It means being able to edit any and all fields, introduce new metadata fields for NVD’s enrichment efforts, and the ability to more easily change the API to deliver that data without breaking integrations.
e. What other actions could NIST and others involved in the vulnerability management process take to improve risk assessment and prioritization?
Again, this RFI is about NIST and the management of NVD in the “AI era”. Asking how “others” in the VM process can improve is out of purview here. Until the NVD can get back on track and generating metadata for all vulnerabilities, asking what else to do seems futile at this point.
(4) Remediation Development, Deployment, and Monitoring
The next six questions all seem out of purview of the original RFI. NVD appears to have a desire to inject themselves considerably more in the vulnerability management lifecycle. The current purpose of NVD is to make CVE data usable and act as a vulnerability intelligence feed. History shows that has been too difficult for the managers of the project. This RFI, around the AI error that speaks to a much higher volume of data to process, has gotten derailed just as NVD did in enrichment efforts. Until NVD can reliably and quickly provide enriched vulnerability data, I strongly suggest that any other efforts be shelved in the interim.
a. What new mechanisms, standards, and procedures may be necessary for automated vulnerability remediation? What role, if any, should AI systems have in automated vulnerability remediation?
Ignoring what I said above about NVD and this RFI, this question is so broad it is ridiculous. The answer to these questions are up for debate and more importantly, will vary based on the organization.
b. What organizational structures, policies, processes, and frameworks are needed for organizations and open-source projects to manage AI-generated remediations?
See above.
c. What controls and safeguards are needed to prevent erroneous AI-generated remediations?
I find it fascinating, and not in a good way, this question was not asked of AI-generated vulnerability disclosures. This RFI has a strong message of NVD trying to “shift right” in the process rather than “shifting left“. MITRE and NVD should be focused on shifting left to help guide disclosures to better ensure accuracy. Their jobs should be to help validate that submissions for a CVE ID are better tested and IDs are not assigned to non-issues and stability bugs. This all speaks to the mindset I talk about, and demonstrates a general lack of expertise around VDBs.
d. What are the biggest barriers to stakeholders (e.g., users, developers, organizations) remediating vulnerabilities after they receive prompt and comprehensive vulnerability information?
This is another question apparently based in a fantasy realm that has NVD providing timely, complete, and accurate vulnerability intelligence. That has not been the case since its inception. Solve the first set of problems before seeking out new problems to solve. This kind of mission creep is not productive to solving issues.
e. What process and organizational dependencies (e.g., discovery and asset inventory) are prerequisites for organizations to more fully operationalize automated vulnerability remediation?
At the Fortune 500 level and size of companies, asset inventory cannot be completed by a longshot generally. When a single organization has over 10 million endpoints to catalog, monitor, and remediate for, an asset inventory is absolutely a dream. But it is just that; a dream. At this point there aren’t additional dependencies so much as finally figuring out how to achieve that first dependency. Regardless of the completeness of an inventory, having timely and reliable CPE data that is used in said automation efforts is key.
f. What other actions could NIST and others involved in the vulnerability management process take to improve vulnerability remediation development, deployment, and monitoring?
See above! Quit asking for more problems to solve until you figure out the basics. It’s literally that simple.
(5) Vulnerability Data and Standards
a. What changes are needed in organizational structures, processes, procedures, standards, and specifications to improve the quality of vulnerability data?
This is completely out of the current purview of NVD. As explained above, while this is a “shift left” approach which is great to see, this is something MITRE must deal with unless the current ecosystem interoperability between MITRE, NVD, and CISA changes.
b. Are existing standards, context, and specifications for vulnerability data, including vulnerability identifiers, product naming schemes, and severity scoring systems, sufficient for improving actionable prioritization of vulnerabilities in the AI era? If so, please describe.
All of the aspects listed above are just as sufficient today as they will be tomorrow for an increase in vulnerability disclosures. Yes, many of them could potentially use improvements but that should have been done ages ago. These aspects are not going to be a hindrance any more today than they will be tomorrow. NVD must independently evaluate if those directly influenced the backlog growth and prevented enrichment efforts. If not then move one from this question. If so, a public report must be issued explaining which aspects and how led to problems for NVD. From there issues can be better addressed.
c. What gaps are there in existing standards and specifications?
This is actually an interesting question because the answer isn’t what most expect. The gap is much less in the standard or specification and instead, much more centered around the implementations. For example, CVSS generally has clear documentation for most attributes of scoring. We’ll ignore the bits that are not so clear or poorly implemented. Despite those CVSS specifications, we consistently see NVD, vendors, and researchers not properly score a vulnerability. That gap in implementing the standard correctly has serious downstream consequences regardless of the score being artificially higher or lower.
d. What information is needed for organizations to efficiently and effectively manage the increasing number of identified vulnerabilities, including vulnerability prioritization and product identification?
At a minimum, complete and accurate CPE strings as well as CVSS scores for all versions to account for the fact some organizations are still on CVSSv2, while some on CVSSv3, and there is slow adoption of CVSSv4. Enriching all vulnerabilities to include Stakeholder-Specific Vulnerability Categorization (SSVC) would be ideal.
e. What changes are needed to improve machine-readable vulnerability data (e.g., data in the NVD) to improve vulnerability prioritization and contextualization?
The biggest change that would benefit NVD and the entire CVE ecosystem is a way for trusted organizations to help manage the CPE dictionary. That is required for better automation especially around third-party enriched vulnerabilities that are not open or tracked by CVE.
f. What other actions could NIST and others involved in the vulnerability management process take to improve vulnerability data and standards?
These questions are rapidly feeling more repetitive. At a high level, taking more effort to ensure that validated vulnerability information enters the CVE ecosystem. But at present, that must fall on MITRE due to the CVE workflow.
(6) Development Processes
a. How can organizations effectively integrate AI-enabled tools into technology development processes to proactively identify, reduce, and remediate security vulnerabilities, and to enhance overall vulnerability management practices throughout the system lifecycle? What changes, if any, are needed to processes, procedures, standards, and specifications to enable this integration.
Pass. This is out of purview for the stated RFI and would take thousands of words to begin to answer.
(7) Vision for the NVD
a. What has been the value of the NVD to organizations? To the extent practicable, please describe how organizations may use the NVD and what activities or decisions the NVD informs.
Before 2024, the value of the NVD was in producing actional vulnerability data, something that MITRE had not done. Specifically, CPE and CVSS were the minimum required to integrate that data in various ways and make it practical for CERT/SIRT teams to utilize.
b. What capabilities and services can be integrated into the NVD to increase its impact over the next five years?
Using some of NVD’s extremely large budget to attract better talent and experience in managing a VDB. Having an effective leader that has past experience specifically managing a VDB that is given autonomy to effect changes in NVD’s personnel and processes would be the best start.
c. What emerging cybersecurity trends relevant to the vulnerability management should the NVD anticipate over the next five years?
The most important one is stated in the RFI summary, and that is around the use of AI in vulnerability discovery and disclosure. That specifically is what this RFI is about and the most critical question to answer. So far questions have danced around this topic but not approached it head-on as much as they should.
d. What capabilities and services will enhance the NVD’s utility for vulnerability analysts, technology developers, researchers, and policymakers?
Once the problem of timely enrichment is solved (helping analysts), using the data set to generate a variety of statistics that are dynamically updated would be helpful. Analysis of CWE trends for technology developers, highlight which technology or vendors has been the focus of research, and more importantly, highlight which vendors and software seemingly have not been so heavily audited to better direct researchers. Overall statistics on vulnerability disclosure trends, the most prevalent weaknesses, and subsequent KEV status (aggregated from CISA and many other sources) can help policymakers.
e. What metrics should be considered to track and evaluate the success of the NVD and any modernization efforts?
The current NVD stats dashboard is a good start, but the historical data must be made public. That allows the public to see the trends, rate of backlog growth, and the rate of enrichment. Basically, every field that can be tracked, should. Let the public sort which metrics are helpful to them.
Conclusion
I found answering this RFI very frustrating, primarily due to scope creep. It simply isn’t worth talking about taking on a considerable amount of extra work when NVD hasn’t figured out the basics. While trying to ignore all of the various bits that are out of purview for this RFI, I found myself repeatedly pointing out that without the base level of enrichment, the data isn’t actionable. NVD must fix the basic enrichment, then figure out how to incorporate AI to handle the base enrichment of the impending volume increase, then after all that, perhaps, work on expanding their capabilities.
If you are in InfoSec and consider yourself an NVD stakeholder, I strongly encourage you to answer these questions and submit them. It isn’t particularly fast to submit, but here are the instructions provided:
1. Go to http://www.regulations.gov and enter NIST-2026-0100 in the search field;
2. Click the “Comment Now!” icon, complete the required fields, including the relevant document number and title in the subject field; and
3. Enter or attach your comments.Alicia Chambers,
NIST Executive Secretariat.
Leave a Reply