CISA Launches Vulnrichment Project as NVD Backlog Hits 10,000

CISA unveiled Vulnrichment at RSA this week, a new project that focuses on adding Common Platform Enumeration, Common Vulnerability Scoring System, Common Weakness Enumeration, and Known Exploited Vulnerabilities to CVEs.

Enriching CVEs is the process of adding valuable details and context to a CVE record, like severity and exploitability, which helps organizations prioritize patching and mitigation efforts.

“We understand that timely and accurate information about Common Vulnerabilities and Exposures (CVEs) is critical to help organizations prioritize remediation, understand trends, and drive vendors to address classes of vulnerability,” the agency said in the announcement.

“Soon, we’ll also start sharing decision points from CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC). We will use CVE JSON format so stakeholders can immediately start incorporating these updates into vulnerability management processes.”

CISA has already enriched 1,300 CVEs and is requesting that all CVE Numbering Authorities (CNAs) provide complete CVEs when submitting to CVE.org. The Vulnrichment project is offered under a CC0-1.0 license, ensuring the enriched data is freely available and can be widely used to enhance cybersecurity efforts across the industry.

NVD Backlog of CVEs Awaiting Analysis Hits 10,000#

The NVD stopped enriching CVE’s in mid-February, with little explanation, fueling speculation. NIST updated its program announcement page acknowledging the growing backlog of vulnerabilities and stating its intentions to establish a consortium. Critics were not satisfied with NIST leadership’s remarks at VulnCon, nor the lack of clarity regarding the abrupt challenges in enriching CVEs.

This week the number of unenriched CVEs passed the 10,000 mark, according to the NVD dashboard, and just 122 CVEs are currently undergoing analysis.

A total of 4,523 CVEs have been analyzed by NVD this year with only 223 in the last month. The backlog continues to grow and NIST has given no updates on its plan for a consortium.

CISA didn’t explicitly state that it is taking over for NVD, although many previously speculated about this when NIST’s lack of transparency about halting enrichment left stakeholders uncertain about the future of CVE processing.

“Overall, the announcement sounds like they are stepping in for NVD but... why?” Vulnerability Historian Brian Martin said when asked to elaborate on his comments on Twitter. “NVD still hasn't provided a sufficient answer to the near-stop they are experiencing.”

Martin said it’s clear CISA is taking on the Vulnrichment effort to address the growing backlog of CVEs awaiting analysis.

“[It’s] also clear that any vuln on CISA's KEV needs that enriched data to help with remediation efforts,” he said. “That said, they are not enriching all CVEs in NVD missing that data. It is a subset and ones they decide using SSVC. They are also apparently making it available via a GitHub repo, which means processing yet another source for stakeholders. It adds technical debt.”

Conflicting CPE Strings Pose Challenges for Vulnrichment Implementation#

While the Vulnrichment effort has been well-received in the security community, the announcement on LinkedIn did not elaborate on what kind of arrangement CISA has with NIST, particularly in regard to adding CPE to CVEs. Historically, CPE, the structured naming scheme for information technology systems, software, and packages, has been exclusively maintained by NIST.

“NIST controls official CPE,” Martin said. “But what happens if someone else needs to add CPE to a vuln w/o a CVE? Or in this case a CVE but it isn't NVD doing it? You can follow the CPE 'specs' to the best of your ability, and predict what will be official many times but not always. Then you end up with NVD ultimately assigning CPE that differs from yours, causing more headache for automation.”

CPE strings that don’t match the NVD are already a problem for some consumers, who have logged multiple conflicting records in the Vulnrichment repository’s GitHub issues. Consumer expectation is that CPE strings will match NVD wherever possible.

CISA representatives offered some comments on how consumers can expect the agency to navigate these conflicts:

1. There is the official NVD CPE Dictionary. First choice. However, even that has matching issues, for example, some xpdf entries use xpdfreader as the vendor.

2. Next, there are a number (84K+) of CPE entries in NVD data that are not in the Dictionary (1.2M+). Second choice (use something that exists).

3. Last choice is to create new CPE. In this sense, we're following the CPE specification, but publishing CPE-compliant data does not get it added to the Dictionary.

“Let's be clear, CPE is an attempt to address the wicked problem that is consistently naming all the software,” @amanion-cisa commented on the issue. “Neither the CPE specification nor existing CPE data can do this, but it's a start, and an existing data set (or sets). There will be errors, and part of this process is to evaluate how CPE or other software identification systems work in practice.”

Consumers should expect changes to the Vulnrichment implementation, as CISA said the project is “expected to evolve quickly over the next several weeks.” During this phase the agency is focusing on assessing new and recent CVEs and adding key SSVC decision points. CISA will score the CVEs and enrich some they deem to be higher risk.

The data is available in JSON format and can be accessed via the GitHub API. CISA vulnerability wrangler Tod Beardsley said that this is a temporary consumer situation - “My hope is that the ADP gears start turning soon-ish, and all this ADP will get reabsorbed back up into the main CVE corpus. But, the important part is just getting the data out there, and giving people a chance to mess around with it, find bugs, do the normal open-source thing.”