NIST seeks input to modernise vulnerability database

NIST has opened a request for information on modernising the National Vulnerability Database, as security teams face rising volumes of software flaws and growing use of AI in vulnerability discovery.

Karthik Swarnam, Chief Security and Trust Officer at ArmourCode, said the review should push the database beyond its longstanding role as a catalogue of disclosed weaknesses. In his view, the central issue is no longer identifying vulnerabilities, but deciding which pose the greatest immediate risk and what action defenders should take.

The current model, he argued, gives too much weight to technical severity alone. That can leave defenders with large numbers of alerts that appear equally urgent on paper, even when the operational danger varies sharply depending on exposure, exploitation activity and the availability of a remedy.

"The most noteworthy aspect in the RFI is the recognition that not every vulnerability deserves equal analytical attention. The sheer volume of vulnerabilities makes a uniform enrichment model increasingly difficult to scale, while treating every critical or high vulnerability as equally urgent creates enormous noise for defenders," said Karthik Swarnam, Chief Security and Trust Officer at ArmourCode.

He distinguished between severity scores and real-world urgency. "A technically severe vulnerability is not necessarily an operationally urgent vulnerability. Conversely, a lower-severity vulnerability that is internet-facing and being actively exploited may represent significantly greater immediate risk," Swarnam said.

Risk context

Swarnam said NIST has an opportunity to reshape the database into what he described as a trusted vulnerability risk platform. That would mean retaining core records such as CVEs and severity scoring while adding signals that help security teams understand how a vulnerability develops after disclosure.

"The opportunity is to evolve NVD from primarily a vulnerability information repository into a trusted vulnerability risk platform," Swarnam said.

He backed the effort itself, but said enrichment should sit at the centre of the redesign. "This is a very good effort by NIST to revamp and modernize the NVD process. The changes should focus on enrichment as the central theme," Swarnam said.

That enrichment, he said, has often been descriptive rather than operational. Existing records may explain what a vulnerability is and how severe it could be, but offer less help on whether attackers are exploiting it, how likely exploitation is, whether a fix exists and how much confidence defenders should place in that fix.

"NVD enrichment remains valuable, but much of it has historically been descriptive rather than operational. It tells us what a vulnerability is and how severe it could be, but provides much less context around whether it's being actively exploited, the likelihood of exploitation, the availability and effectiveness of remediation, and the confidence defenders should place in that remediation," Swarnam said.

He placed that criticism in the wider context of how vulnerability management has changed. "The NVD is one of the foundational components of global cybersecurity infrastructure, but the way enterprises manage vulnerability risk has changed dramatically since the database was originally designed," Swarnam said.

"The industry no longer has a vulnerability identification problem; we have a prioritization, context and remediation problem," he added.

Static to dynamic

At the heart of his argument is the need to treat vulnerabilities as changing risk records rather than fixed entries. A software flaw may remain technically the same, he said, but its operational importance can rise or fall as exploit code appears, attackers begin using it, or vendors issue and refine patches.

"The most important shift is moving from simply asking, 'How severe is this vulnerability?' to asking, 'How much risk does this vulnerability represent right now, and what should defenders do about it?'" Swarnam said.

He said NIST should use the modernisation process to build in dynamic risk signals and make them available in forms organisations can combine with their own asset and business context. "Modernization gives NIST an opportunity to enrich vulnerability information with dynamic risk signals, including exploitation activity, threat intelligence, remediation status and confidence, while allowing enterprises to combine those signals with their own asset, exposure and business context," Swarnam said.

Swarnam said the consultation should also ask how the database handles the full vulnerability lifecycle after publication. He proposed new questions on remediation availability, remediation effectiveness and software vendor attestation, as well as on how risk information should evolve as threat activity and proof-of-concept code change over time.

"A CVE should not be viewed as a static record. Its technical characteristics may not change, but its operational risk can change substantially over time. The enrichment model should reflect that," Swarnam said.

Machine-readable data

He set out three broad recommendations: add dynamic risk enrichment without replacing CVSS, make remediation part of the lifecycle, and spread more responsibility for complete and accurate information across CVE Numbering Authorities and software makers. Under that model, NIST would focus on governance, normalisation, provenance and distribution rather than manually filling every gap itself.

Swarnam also said the redesign should reflect the fact that software tools, rather than people, increasingly consume vulnerability information. Platforms used for vulnerability management, attack surface management and security analytics, as well as AI-driven systems, now depend on structured and frequently updated feeds.

"I strongly encourage NIST to think of NVD modernization as a machine-readable cybersecurity data platform," Swarnam said.

He expanded on that point by arguing that APIs, structured data and provenance will become more important as automated systems ingest and correlate vulnerability records. "Humans will increasingly not be the primary consumers of NVD data. Vulnerability management platforms, ASPM platforms, security analytics systems and, increasingly, AI security agents will consume and correlate this information automatically. APIs, structured data, provenance and the ability to consume changes dynamically therefore become critical," Swarnam said.

Swarnam noted that the NVD already provides APIs and feeds, and said newer additions such as Stakeholder-Specific Vulnerability Categorization suggest the database is already moving in that direction. "Ultimately, the goal shouldn't simply be a better database of vulnerabilities. NVD should become the trusted enrichment layer that enables the cybersecurity ecosystem to turn vulnerability data into risk decisions and remediation actions," Swarnam said.