Death Knell of the NVD?

A look at recent concerns around the NIST National Vulnerability Database (NVD) and its implications

Welcome to Resilient Cyber!

If you’re interested in FREE content around AppSec, DevSecOps, Software Supply Chain and more, be sure to hit the “Subscribe” button below.

If you’re interested in Vulnerability Management, you can check out my upcoming book “Effective Vulnerability Management: Managing Risk in the Vulnerable Digital Ecosystem” on Amazon. It is focused on infusing efficiency into risk mitigation practices by optimizing resource use with the latest best practices in vulnerability management.

---

Anyone who has worked in cybersecurity for some time and done any sort of vulnerability management has likely heard of the NIST National Vulnerability Database (NVD).

For those that haven’t, it is defined as:

“The U.S. government repository of standards based vulnerability management data. This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security-related software flaws, product names, and impact metrics”

However, don’t let the use of the word U.S. fool you, the NIST NVD represents the most widely recognized and longstanding vulnerability database in the software ecosystem.

It is used by countless security tools, both open source and proprietary and codified into various regulations and requirements from FedRAMP to the Risk Management Framework (RMF) just to name a couple and the vulnerability ID’s it provides, communicated as Common Vulnerability and Enumerations (CVE)’s are often cited in industry advisories from groups such as the FBI and CISA for both industry as well as critical infrastructure.

Despite its flaws and deficiencies, the NVD is a core part of the modern software and vulnerability management ecosystem to put it lightly. This image from Vulnerability Researcher Patrick Garrity (originally copyrighted by xkcd.com) does a great job of communicating the NVD’s importance to the ecosystem.

The Issue and Implications

So what exactly is the cause for concern and what has everyone up in arms?

Around February 15th the NVD made the below announcement:

This initially didn’t get noticed by many in the industry until researchers and practitioners such as Patrick Garrity, Jerry Gamblin and Josh Bressers began raising concerns.

What exactly is this consortium, who will be involved, what changes will be made and what sort of delays will we see as an industry when it comes to vulnerability analysis from the most widely used vulnerability database?

Well, some of those concerns have been captured by researchers such as Jay Jacobs (who also helped spearhead the Exploit Prediction Scoring System, which I’ve written extensively about in my article “A Look at the Exploit Prediction Scoring System (EPSS) 3.0” and can be used to predict with surprising accuracy how likely it is that a given CVE will be exploited over the next 30 day window).

The images below from Jay demonstrate that around the same time as the announcement, there was a significant drop off of CVE’s listed as Analyzed vs. Waiting for Analysis, compared to 2023.

Additionally, Jay provided another visualization showing that the gap between “Published” CVE”s and those tagged with associated CPE, CVSS, CWE and Reference information also has saw either a complete stagnation or decline.

Another outstanding vulnerability researcher named Jerry Gamblin published research showing that since the date of February 15th, 90% of all published CVE’s are still awaiting processing and analysis.

Software supply chain security company Anchore, which includes Josh Bressers published a blog titled “National Vulnerability Database: Opaque Changes and Unanswered Questions” which also highlights the drastic drop in NVD’s being enriched

To understand why these are significant, let’s recap what these acronyms mean and how they’re used.

Common Platform Enumeration (CPE)

First up is Common Platform Enumeration (CPE), which are defined as “a structured naming scheme for information technology systems, software and packages”.

There is a CPE Dictionary which is available for download.

As pointed out by the NVD “a fundamental part of the CVE analysis process is to uniquely identify the vulnerable products affected by a given vulnerability”.

A simple example is the below search related to Microsoft Outlook

This is critical for consumers, customers and organizations to understand what products in their environments are affected b y a specific vulnerability/CVE. Without a CPE identifier tied to a CVE, organizations won’t have an easy way to tie known vulnerabilities to specifics products and use their asset inventories to understand what products in their environment are potentially vulnerable.

As pointed out by Jay’s image above, the tagging of CPE’s to published CVE’s has essentially stalled, meaning despite new vulnerabilities being published they currently aren’t being tagged to specific products, leaving organizations blind to knowing what products and systems in their environments the specific vulnerabilities may be impacting.

There are discussions on the NVD about replacing CPE, perhaps with SWID, but given SWID has already been kicked out of the SBOM discussion as an industry leading format, and instead we see CycloneDX from OWASP and SPDX from The Linux Foundation dominating the SBOM format discussion, it is unlikely that SWID will be the successor.

---

Another useful note is that there are folks known as “the SBOM Forum” currently advocating for the NVD to adopt the use of Package URL’s (PURL)’s as well, given the pervasive use of software packages and open source software (OSS), but whether that materializes is still to be determined.

They published their recommendations as “New Recommendations to Improve the NVD” in September 2022, which included a paper titled “A Proposal to Operationalize Component Identification for Vulnerability Management” and the group involves folks such as Steve Springett (of CycloneDX and Dependency Track) along with Tom Alrich.

---

Common Vulnerability Scoring System (CVSS)

Next up in the key acronyms and terms is the CVSS. It is defined as “an open framework for communicating the characteristics and severity of software vulnerabilities”.

CVSS is currently is version 4.0 of the specification and I’ve written articles covering the new CVSS 4.0 specification which can be found here “Will CVSS 4.0 be a Vulnerability-Scoring Breakthrough or is it Broken?”

Despite many critiques of the use of CVSS for vulnerability prioritization (often due to poor use of CVSS in ways it was never intended to be used) it is widely used across the world to prioritize vulnerabilities for remediation based on the CVE’s assigned CVSS severity score (based on the Base Metric of CVSS).

Unlike CPE, Jay’s image demonstrates a decline but not entire halt of tagging CVE’s with CVSS scores. This means many CVE’s are being published without associated CVSS base scores, which inevitably likely is and will lead to challenges for organizations that use CVSS metrics as part of their vulnerability prioritization activities for vulnerability remediation.

---

CVSS is run by an organization known as Forum of Incident Response and Security Teams (FIRST), who also lead the previously mentioned EPSS. You can learn more about CVSS by navigating to the CVSS 4.0 Specification Document or FAQ.

---

Common Weaknesses and Enumerations (CWE)

We also have the CWE, which is defined as “a category system for hardware and software weaknesses and vulnerabilities”.

CWE’s are maintained by MITRE, an FFRDC who define weaknesses as “a condition in a software, firmware, hardware or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities”.

There is a comprehensive CWE list, which is updated 3-4x annually to add new weaknesses and information.

Users can interact with the CWE list directly, as well as via an REST API.

As we all know, the industry has been on a push to evangelize “shifting security left” over the last several years, due to claims that identifying and remediating vulnerabilities earlier in the software/product development lifecycle is less costly as well as minimizes exploitation windows for malicious actors. This concept is captured in the below image from, CWE’s “About” page.

Additionally, another industry trend is the push for “Secure-by-Design”, which is being championed by organizations such as CISA. Among that, includes the need to identify not just individual vulnerabilities but systemic vulnerabilities across the ecosystem and address them at their root causes to drive widespread vulnerability remediations across the software ecosystem.

Without vulnerabilities having tagged CWE’s as demonstrated by the image from Jay Jacobs, it will be difficult to categorize vulnerabilities properly and understand weaknesses they are associated with, impacting overarching efforts to both shift security left and drive down systemic vulnerabilities by addressing CWE’s.

Another example of this is the CWE Top 10 KEV Weaknesses, where the CWE team identified the Top 10 CWE’s in CISA’s Known Exploited Vulnerability (KEV) catalog, which is a database of security flaws in software applications that have been exploited by attackers. By focusing on CWE’s in the KEV, organizations developing software and systems can prioritize categorized weaknesses based upon evidence of exploitation, again leading to a systemic risk reduction.

Ironically, CISA’s Secure-by-Design publication calls for “CVE Completeness”, which includes ensuring that published CVE’s include root causes or CWE’s to enable industry wide analysis.

CWE also maintains what is called the “Top 25 Most Dangerous Software Weaknesses”, which is a list to demonstrate the most common and impactful software weaknesses which are easy to find and exploit. Without CVE’s having tagged CWE’s, the ability to identify and prioritize the most critical software weaknesses would be impeded.

References

References are used for additionally reading related to an impacted product as well as vulnerability advisories from the supplier. A simple example is the below references for a CPE associated with Amazon’s SSM Agency

While references may seem insignificant, they are useful for practitioners to find out more information related to impacted products as advisories for specific vulnerabilities associated with a product.

Again, as Jay Jacob’s image demonstrated there was a complete stagnation of CVE’s being enriched with references.

Alternatives

All is not lost, as there is a rich ecosystem of innovative and robust vulnerability management database alternatives as well, albeit not the same as the NIST NVD, which is backed by the U.S. Government, rather than private sector entities.

This section of the article isn’t intended to be an exhaustive discussion of every possible existing alternative. If you’re interested in a much deeper dive of the Vulnerability Database ecosystem, I recommend my article titled “An Incomplete Look at Vulnerability Databases & Scoring Methodologies”.

That said, let’s look at some of the primary alternatives or complimentary vulnerability databases discussed in the industry.

Sonatype OSS Index

As OSS adoption has continued to grow, and increasingly contributing to significant portions of modern applications and products, there has been more demand to understand the risk associated with OSS components. The Sontatype OSS Index has emerged as one reputable source to aid with this.

The OSS Index provides a free catalog of millions of OSS components as well as scanning tools, which can be used by organizations to identify vulnerabilities with OSS components, the associated risk and ultimately drive down risk to organizations. The OSS Index also provides remediation recommendations and much like NVD, has a robust API for scanning and querying as part of integrations.

In addition to being able to search for OSS components and find any information related to their vulnerabilities the OSS Index supports scanning projects for OSS vulnerabilities and integration with modern CI/CD toolchains through the indexes REST API. As part of the broader push to “shift security left”, moving security earlier in the SDLC, this toolchain and build time integration facilitate identifying vulnerabilities in OSS components prior to deploying code to a production runtime environment.

The OSS Index API integration is used by many popular scanning tools for various programming languages, such as the Java Maven plugin, Rust Cargo Pants, OWASP Dependency-Check and Python’s ossaudit among several others.

It is worth noting while the OSS Index is free for community use, it also doesn’t include any specially curated intelligence or insight from experts. Sonatype however does offer other service offerings to provide additional intelligence, manage libraries and provide automation capabilities.

Open-Source Vulnerabilities (OSV) Database

In 2021, Google Security launched the OSV Project with the aim of “improving vulnerability triage for developers and consumers of open-source software”. The project evolved out of earlier efforts by Google Security dubbed “Know, Prevent, Fix” and OSV strives to provide data on where vulnerabilities are introduced and where they get fixed so software consumers can understand how they are impacted and how to mitigate any risk.

OSV includes goals to minimize the required work by maintainers to publish vulnerabilities and improve the accuracy of vulnerability queries for downstream consumers. OSV automates triage workflows for open-source package consumers through a robust API and querying vulnerability data. OSV also improves the overhead associated with software maintainers trying to provide accurate lists of affected versions across commits and branches that may impact downstream consumers.

The Google Security team has published blogs demonstrating how OSV connects SBOM’s to vulnerabilities due to OSV’s ability to describe vulnerabilities in a format specifically designed for mapping to open-source package versions and commit hashes. It also aggregates information from a variety of sources such as the GitHub Advisory Database (GHSA) and Global Security Database (GSD). There is even an OSS tool dubbed “spdx-to-osv” That creates an OSS vulnerability JSON file from information listed in an SPDX document.

OSV isn’t just a database available at https://osv.dev but it also a schema and Open-Source Vulnerability format. OSV points out that there are many vulnerability databases but no standardized interchange format.

If organizations are looking to have widespread vulnerability database coverage, they must wrestle with the reality that each database has its own unique format and schema. The same goes for databases looking to exchange information with one another. This hinders adoption of multiple databases for software consumers and stymies publishing to multiple databases for software producers.

OSV aims to provide a format that all vulnerability databases can rally around and allow broader interoperability among vulnerability databases as well as ease the burden for software consumers, producers and security researchers looking to utilize multiple vulnerability databases. OSV operates in a JSON-based encoding format with various Field Details such as ID, published, withdrawn, related, summary and severity among several others, including sub-fields.

OSV was founded by Oliver Chang, who is currently a Senior Staff Software Engineer at Google.

While OSV is an incredible resource, it is primarily focused on Open Source Software (OSS), which of course doesn’t include the world of closed source and proprietary software vendors or products, meaning it wouldn’t be a direct replacement for NVD and the use of CPE’s. This also applies to the previously discussed Sonatype OSS Index.

GitHub Advisory Database

While organizations have increased their efforts around utilizing technology to drive business outcomes, organizations have increasingly begun to employ software developers. Whether it is those writing software natively for the organization or working to integrate software products into their business workflows and operations. There is no commercial organizations used more worldwide to facilitate software development activities than GitHub, which boasts over 100 million users worldwide.

As the use of GitHub has grown, the organization has expanded its offerings to include what is known as the “GitHub Advisory Database,” which is a list of known security vulnerabilities and malware. These advisories are grouped into two categories which are reviewed and unreviewed advisories.

The GitHub Advisory Database sources vulnerabilities from sources such as the NVD which we have discussed above as well as many others such as popular language and package databases from npm, Go, Python and Ruby among others. It also accepts community contributions, allowing users to submit vulnerabilities information that may be beneficial to the broader community.

GitHub Advisory Database makes use of the Open Source Vulnerability (OSV) format, which aims to provide a standard interchange format for vulnerability databases, to facilitate easier exchange of vulnerability data. This format is supported by other databases we have discussed, such as OSV as well.

In the context of GitHub Security Advisories (GHSA)’s, the database makes use of a GHSA ID, which is a unique identifier that every security advisory in the GHSA database is assigned. The GitHub Advisory Database provides a robust REST API that the community can interact with for doing activities such as creating security advisories, or consuming advisory data.

With the continued growth of software developers and organizations performing software development activities and adopting DevSecOps methodologies and practices, the authors anticipate the GitHub Advisory Database will continue to experience growth and adoption rather than Developers going to original sources such as the NIST NVD.

What’s Next?

So what’s next for NVD and the broader vulnerability database ecosystem?

It’s actually hard to say, due to a lack of transparency and communication from NIST and the NVD, aside from the obscure notice that I shared at the start of the article.

That said, Chainguard CEO Dan Lorenc had a post on LinkedIn that got quite a bit of engagement from folks across the industry around the topic.

It ranged from people seriously concerned about the future of the NVD and promoting its value, to those raising harsh criticisms and longstanding issues with the NVD, and more broadly the Government’s ability to do this right.

I think it’s worth noting there are some parallels with those comments and broader society, as there’s been a recognized increasing distrust in the Government to function effectively and efficiently and the world of software and vulnerability databases are of course a microcosm of the bigger society.

Many expressed doubts that any sort of consortium will solve the problem and are asking for further transparency and clarification from NIST.

Some even went as far as advocating that we quit wasting time and energy into vulnerability prioritization and CVE’s in general and instead shift to investing more time and energy into application security updates and patches without needing to scan for CVE’s before doing so.

While there’s some merit to cutting down patch remediation windows to minimize exploitation, this argument also ignores the supplier side of the paradigm, where software and product suppliers need to make more informed decisions around the integration of third-party components into their products and ensuring they aren’t shipping poorly maintained, insecure and vulnerable components to downstream consumers.

Even the Senior Director of Product Management at GitHub, Justin Hutchings weighed in starting that the world needs NVD to be an effective database of vulnerabilities. He also highlighted Madison Oliver’s involvement with the CVE Board and potential to help fix systemic issues.

I think its probable that most cybersecurity professionals share Justin’s sentiment, that NVD is a key part of the software ecosystem, and despite deficiencies with NVD and its associated processes, it is and has served as a key part of the vulnerability management landscape for decades.

That said, the current lack of communication and clarity, coupled with decreasing quality of CVE’s due to a lack of enrichment is undoubtedly giving credibility to criticisms and risks further jeopardizing the NVD’s longterm trust and reliability.

I will be speaking at the first ever 2024 VulnCon, hosted by CVE/FIRST later this month and I hope we will get some answers then.