Friday, August 21, 2026
Forge News Breakdown
The National Institute of Standards and Technology (NIST) has opened a formal Request for Information on modernizing the National Vulnerability Database (NVD) for an environment increasingly shaped by artificial intelligence (AI) and machine-consumable security data. NIST says it wants to improve the NVD’s scalability, automation, interoperability, transparency, and utility. Comments remain open through October 13.
The timing is not accidental. In April, NIST changed how it enriches Common Vulnerabilities and Exposures (CVEs) after submissions increased 263 percent between 2020 and 2025. NIST enriched nearly 42,000 CVEs in 2025, 45 percent more than in any previous year, and still could not keep pace. Rather than continue pretending every record could receive identical treatment, NIST moved toward risk-based enrichment that prioritizes known exploited vulnerabilities, software used by the federal government, and federally defined critical software. Lower-priority CVEs remain in the database but may not receive immediate NIST enrichment.
That distinction matters because NIST is not struggling primarily to put vulnerability identifiers into a database. The current NVD already ingests published CVE records through automated processes within approximately an hour of publication. Human analysts then enrich those records with information including severity scores and affected product versions. The growing pressure sits farther downstream, where raw vulnerability information has to become useful operational evidence.
NIST’s new RFI explicitly describes a vulnerability-management environment being reshaped by AI-assisted discovery, triage, exploitation, and remediation, increased dependence on machine-readable security information, rising vulnerability volume, uneven data quality, demand for near-real-time enrichment, and finite analytical resources. Traditional approaches centered on periodic scanning, static prioritization, and manual remediation are becoming increasingly inadequate under that load.
The questions NIST asks are therefore broader than how to insert a language model into the NVD. It asks which vulnerability-management activities should be automated, which require human review, how reviewers can avoid over-reliance on AI, what production context should influence prioritization, how AI-driven prioritization can remain transparent and auditable, what safeguards are required around generated remediation, what asset and discovery dependencies must exist before remediation can be automated, and how machine-readable vulnerability data itself needs to evolve.
That is a considerably more serious problem than whether AI can summarize a CVE because the object being redesigned is no longer merely the database. It is the decision path from vulnerability discovery to operational consequence.
Forged Take
Security has spent decades improving its ability to discover and describe vulnerability. We built scanners, severity scores, vulnerability feeds, threat-intelligence systems, asset inventories, ticket queues, dashboards, patching systems, and eventually an enormous standards infrastructure for moving findings among organizations. The volume kept increasing, and now AI is compressing the time available to decide what those findings mean.
AI can assist both sides of the problem. Defenders can use it to find vulnerabilities, analyze code, correlate context, triage findings, propose remediations, and potentially execute parts of the repair process. Attackers may use the same class of systems to discover weaknesses, generate exploits at scale, and assist post-exploitation activity. NIST does not claim that every one of those capabilities is mature or uniformly effective. It says they are consequential enough that the vulnerability-management ecosystem has to anticipate them.
The obvious response is more automation, and some of that automation is necessary. The danger begins when throughput becomes the objective rather than a means of moving better evidence toward a better decision.
The database itself already demonstrates why. NIST’s April decision to prioritize enrichment is effectively an acknowledgement that vulnerability management is an allocation problem. There are more findings than finite analytical resources can treat equally, so some mechanism has to decide which evidence deserves attention first.
AI can make that prioritization faster. It cannot make the decision politically, operationally, or economically neutral. A vulnerability with a high severity score may exist on an asset the organization does not run. A moderate vulnerability may sit directly on a public attack path protecting sensitive data. One finding may already be exploited in the wild while another requires preconditions absent from the production environment. A patch may eliminate one vulnerability while creating an outage more expensive than the threat it removes.
Vulnerability priority is therefore not a property of the CVE alone. It is a relationship between the vulnerability and the system in which the vulnerability exists. NIST’s RFI gets unusually close to that distinction by asking what system context organizations need to prioritize vulnerabilities accurately in production environments and how NVD data should integrate with vulnerability-disclosure programs, vendor advisories, threat intelligence, asset-management platforms, security tools, and remediation workflows.
The future NVD cannot merely become a faster catalogue of bad things. It has to participate in an evidence system capable of helping downstream operators establish whether a vulnerability is relevant, exploitable, reachable, consequential, and actionable in their environment.
NIST has already started moving in that direction. In June, the NVD added Stakeholder-Specific Vulnerability Categorization (SSVC) data and structured affected-product information to its feeds and application programming interfaces. The SSVC schema includes a computed prioritization result intended to expose how a vulnerability priority was reached rather than supplying only another opaque score. Machine-speed security needs that kind of machine-readable context, but context by itself does not remove the need for judgement.
If the vulnerability process becomes increasingly automated, the dangerous failure mode is not merely that an AI system occasionally classifies a vulnerability incorrectly. The system can become extremely efficient at propagating the wrong decision. A false positive can become an emergency patch, the emergency patch can become a failed deployment, and the failed deployment can become an outage. An incorrect product mapping can send thousands of machines into remediation for a vulnerability they do not possess. A generated fix can eliminate the original weakness while introducing another one.
NIST explicitly asks what safeguards are required to prevent erroneous AI-generated remediations, what organizational structures should govern those actions, and what discovery and asset-inventory dependencies must exist before automated remediation can be operationalized. Those questions put the problem where it belongs, inside the operating environment rather than inside the model alone.
You cannot automate remediation responsibly against an environment you cannot describe.
An AI system does not rescue a weak asset inventory or repair uncertain ownership. It accelerates decisions made against both. Nor does automation make rollback less important. The faster the system can turn evidence into action, the more valuable it becomes to reverse an incorrect decision cleanly.
This is where the old vulnerability-management stack begins to resemble a control plane. Discovery supplies the event. Vulnerability data supplies the technical identity. Asset context establishes relevance. Threat intelligence changes urgency. Policy determines which actions are permitted. Automation executes within those permissions. Observability records what happened. Humans retain authority where the consequence requires human judgement. The individual systems already exist in pieces, but the contract among them remains weak. AI makes that deficiency harder to tolerate because it compresses the interval between finding, deciding, and acting.
Counter-Pressure
There is a danger in making the opposite mistake and assuming every vulnerability-management activity should operate at machine speed merely because machines can now participate. Some security processes are slow because organizations built bad workflows around them. Others are slow because they contain legitimate uncertainty.
Responsible disclosure can require coordination among researchers, maintainers, vendors, cloud providers, government agencies, and customers. Product identification is messy. Exploitability can remain ambiguous. Remediation can carry business consequences that no vulnerability feed can infer from a severity score. A production change affecting a hospital, power grid, aircraft, bank, or military system does not become automatically correct because an AI system calculated high confidence.
NIST’s RFI acknowledges that tension directly. It asks which tasks should require human review, what information those reviewers need, how review time can be minimized without creating over-reliance on AI, and how AI-driven prioritization can remain transparent and auditable. That is the correct boundary because human review has to preserve judgement rather than merely preserve the appearance of a person somewhere in the workflow.
A human mechanically clicking Approve on thousands of recommendations generated faster than anyone can examine them is not meaningful oversight. It is automation with ceremonial liability transfer.
The useful distinction is where judgement changes the consequence. Machines can normalize data, correlate records, identify affected assets, detect known exploitation, calculate reachability, propose remediation, estimate confidence, and assemble the evidence package. The control system then has to recognize when the action crosses a boundary that requires an accountable owner.
That boundary will differ by environment. Automatically updating a low-risk development dependency is not equivalent to changing a production database engine beneath a healthcare platform. A control architecture that cannot distinguish between those actions does not become mature merely because it contains AI.
Operating Takeaway
NIST’s modernization effort should not be measured by how much AI eventually appears inside the National Vulnerability Database. The better measure is whether vulnerability information becomes timely enough for machines to consume, contextual enough for operators to trust, auditable enough to reconstruct, and bounded enough that automation cannot silently turn uncertain evidence into irreversible action.
The April numbers already establish the pressure. NIST increased enrichment throughput substantially and still had to stop treating every CVE equally. AI is increasing the pressure to automate analysis, discovery, prioritization, and eventually remediation. That creates leverage, but leverage without a control architecture merely moves the bottleneck closer to the consequence.
A future-ready vulnerability system therefore needs more than speed. It needs provenance for the finding, context for the affected system, explicit authority for the action, a record of the judgement, an enforceable boundary on automation, and a recovery path when the decision is wrong. NIST describes the desired future as continuous, contextual, and automated.
The missing word is accountable.
Artifacts are cheap, judgement is scarce.
Per ignem, veritas.
Sources
NIST, Modernizing the National Vulnerability Database in the Age of Artificial Intelligence, Request for Information, August 12, 2026
NIST, NIST Updates NVD Operations to Address Record CVE Growth, April 2026
NIST Information Technology Laboratory, National Vulnerability Database, June 2026 deployment update adding SSVC and structured affected-product data
ITPro, NIST National Vulnerability Database modernization and machine-speed consumption, August 2026