Two months ago, I recorded a podcast for CSO Online titled "Running an effective SCA practice in a post-NVD era.” It was just released this week. The podcast was sponsored by Revenera (a division of Flexera), which makes a widely used “software composition analysis” (SCA) tool; Venkat Ram Donga of Revenera was the other participant in the podcast. If you’re not familiar with that term, an SCA tool analyzes a software product or codebase and identifies components included in the software (in other words, it creates an SBOM – software bill of materials – for the product). Some SCA tools (like Revenera’s) identify open source license(s) that apply to each component, as well as vulnerabilities found in the component.
In my bio for the podcast, I described my relatively new consulting relationship with Foxguard Solutions. Foxguard is an entirely OT-focused cybersecurity service provider, which provides services in some very important areas. One is OT patch management, where their widely used Patchintel service provides patch discovery, evaluation, and verification for OT-focused organizations, especially those that must comply with NERC CIP-007 Requirement R2. The other is OT vulnerability management, where Foxguard’s Cyberwatch product provides OT asset discovery, as well as asset-based vulnerability management.
The primary focus of the podcast was the last phrase of the title: “post-NVD era”. This doesn’t mean we think the National Vulnerability Database is dead or even on the way out, but it does mean that the NVD, which is run by NIST and has for years been the primary resource for software vulnerability information for a significant percentage of public and private organizations worldwide, has retreated from performing such an important role.
The questions we answered in the podcast can be summarized as, “Given that the NVD is no longer able to be our one-stop shop for vulnerability identification and prioritization, how else can we perform the tasks we previously relied on the NVD for? In fact, once we’re no longer dependent on the NVD, are there better ways to do vulnerability management?” (If you would like to see an overview of how the CVE program works, including its relationship to the NVD, see this post)
There are three main components to this problem:
The decline (but not yet fall) of CVSS
Because the CVSS Base Score used to be published in almost every CVE record, it became widely used for vulnerability prioritization, even though many vulnerability management professionals pointed out that it didn’t provide much value as a measure of risk, especially OT risk. For example, suppose that CVE-2026-12345 has a 10.0 CVSS Base Score (the highest severity). It affects two systems in your organization: a system that monitors safety in your factory and a system that displays menus for the company lunchroom. At the same time, a system that schedules production in the factory is affected by a vulnerability with a 9.0 score, which is severe but not the highest severity. If you use only CVSS Base Score to prioritize application of patches, this means you should patch the lunchroom menu system before the factory scheduling system. Of course, that makes no sense.
In fairness to CVSS, the Base Score by itself was never intended to be a measure of true risk; that is only achieved if the CVSS Temporal metrics[i] and Environmental metrics are utilized with it – i.e., if the user pays attention to a composite score created by combining the Base metrics with the other two types of metrics. This is not usually done, because neither the Temporal nor the Environmental metrics are published.
The Environmental metrics are completely under the user organization’s control; they are meant to distinguish different systems based on their importance to the organization, i.e., the criticality of the process controlled by the system. For example, an organization might assign each of their control systems a criticality level of low, medium or high, or else use a binary low/high criticality score. When the organization incorporates these metrics into the CVSS Base Score, they will get a “Base and Environmental” score that is specific to each asset or type of asset. Of course, that will be much closer to a true measure of risk than the Base Score alone.
The Temporal metrics change over time. Two Temporal metrics are the maturity of exploit code and the remediation level of the vulnerability (i.e., the degree to which the CVE has been patched). But the problem with the Temporal metrics is that no data is regularly available for them, so the user organization will normally only be able to compute Temporal scores for a small percentage of the CVEs that they deal with. Of course, this doesn’t mean that Temporal scores are useless, since they can help compare risk posed by one CVE with risk posed by another, when both have a Temporal score.
However, the biggest problem with CVSS today is that a large and growing percentage of CVE records contain no CVSS Base Score. In February 2024, due to funding problems, the NVD greatly decreased the rate at which it added a score to each new vulnerability record (NVD calls this process “enrichment”). Moreover, in January of this year, NIST announced that from then on, CVSS scores will only be added to the records for CVEs deemed to pose the highest risk (e.g., those in CISA’s KEV Catalog). Of course, it’s good that the NVD will focus on enriching the highest risk vulnerabilities, but it’s not good that they aren’t enriching other vulnerabilities at all.
However, the fact that fewer and fewer CVE records contain a CVSS score doesn’t mean organizations should stop using CVSS for vulnerability prioritization, especially if they are able to utilize Environmental and (if possible) Temporal metrics to create a true CVSS risk score. But CISA recently changed their guidance on vulnerability prioritization.
SSVC
Last month, CISA’s BOD-26-04 deprecated CVSS as an appropriate measure of risk for vulnerability and patch prioritization purposes, in favor of SSVC[ii]. SSVC is a decision tree process that CISA developed in 2022. It operates simply and incorporates user provided data on Technical Impact of the vulnerability, based on the system (or class of systems) that is affected by the vulnerability; SSVC also takes account of whether the CVE appears in CISA’s KEV Catalog. Thus, it can be considered a much better representation of risk than CVSS Base Score.
The final output of the SSVC process (called the “decision” for the CVE) is the prioritization of the vulnerability into one of six classes. CISA is currently providing three of the four SSVC metrics (only the “Publicly Exposed” metric, which has a yes/no answer, is the only metric CISA doesn’t provide. The user organization needs to provide that, whether or not they are a federal organization) for some, although not yet all, CVE records.
CPE and PURL
The third component of the “NVD problem” is that the NVD, along with reducing the number of CVSS Base Scores that it adds to CVE records, has also greatly reduced the number of CPE names that it adds to CVE records. Since CPE is currently the only machine-readable software identifier that ties a CVE to an affected software product (or intelligent device), this means an ever-increasing percentage of CVEs are invisible to an NVD search using a product name. This is probably the most serious of the three problems, since simply learning about a vulnerability doesn’t help if there’s no way to know what product(s) is affected by the vulnerability.
Last fall, the CVE Program added support for the PURL software identifier (which stands for Product URL) to the CVE Record Format. PURL has the big advantage that nobody needs to “create” a PURL for most open source products; all users of a product can create their own PURL, using its simple specification. A PURL can always be constructed using information the user already has, or could easily obtain. This includes, for most open source software products, the package manager from which the product was downloaded and the name of the product in that package manager.
PURL could ultimately be the solution to the lack of a machine-readable software identifier in many CVE records. However, PURL’s biggest problem today is that currently it can’t be used to identify commercial software products. This is not a technical problem but an operational one, since solving it will require a significant number of commercial developers to agree on procedures for naming commercial software products. OWASP has formed the PURL Expansion Working Group to address this problem. Anyone interested in participating in that group should contact me at [email protected].
Vulnerability databases
Toward the end of the podcast, I was asked what other vulnerability databases are available besides the NVD. My answer was there are many other options, but they are very diverse, so it’s impossible to point to a single database that would replace the NVD. You may need to get used to using 2-4 vulnerability databases, although it would be nice if in the future that wasn’t necessary.
1. GitHub Security Advisories (GHSA): This huge database contains open source software vulnerabilities (mostly found in GitHub projects). GHSA has its own vulnerability numbering scheme called GHSA. There’s no way to map a GHSA identifier to a CVE number, unless the GHSA record refers to a CVE number. Often, GitHub creates a new CVE record at the same time as it creates a new GHSA record (GitHub is one of the most prolific CVE Numbering Authorities – CNAs). Vulnerable projects in GHSA are identified using PURL or OSV (OSV is the main software identifier used in Google’s OSV.dev vulnerability database. That database includes GHSAs, as well as advisories from a large number of ecosystem-specific databases, like those for Maven, Python, and many flavors of Linux).
2. Sonatype Guide (formerly OSS Index). This is another huge open source vulnerability database, although all the vulnerabilities are identified using CVE identifiers. The vulnerable products are identified with PURL. Since so many organizations are used to working with CVE records, it is easy to use this database to look up open source vulnerabilities, since the coverage of those vulnerabilities is much more comprehensive than it is in the NVD. However, the fact that PURL is currently limited to open source software distributed in package managers means this database cannot currently handle commercial software vulnerabilities – although, as discussed above, an OWASP project will hopefully start soon to extend PURL to commercial software. Currently, the only vulnerability databases that identify vulnerabilities in commercial software products are the NVD and its offshoots.
3. VulnDB, VulDB, VulnCheck, Vulners, JP-CERT/CC, as well as others. These databases were all built on the NVD. All of them include everything that the NVD does (they’re updated in close to real time, since it only takes about ten minutes to download the entire NVD). This means they support CVE as a vulnerability identifier and CPE as a software identifier. Each of these databases adds their “secret sauce” to what the NVD has, but you need to go through their websites to compare them. They all (except JP-CERT/CC) charge for at least some use. However, people swear by all of them.
4. The EU Vulnerability Database is run by ENISA; it started operating last year. It identifies vulnerabilities using EUVD identifiers, although in many cases they are mapped to CVE numbers and/or GHSA advisories. However, no machine-readable software identifiers are included in the records (i.e., neither CPE nor PURL). This makes automated searches difficult.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for three months after they come out by becoming a free subscriber. You can also access all of my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can become a founding subscriber for $100). Whether free or paid, please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment in my chat or email me at [email protected].
[i] These are called “Threat metrics” in CVSS 4.0.
[ii] CISA’s BOD-26-04 doesn’t specifically refer to SSVC, but the process it describes is clearly SSVC. SSVC documents are referenced in the Implementation Guidance for the BOD.