Why developers need a supplemental source to NVD vulnerability data

Public sources, such as the National Vulnerability Database (NVD), are a good first step for information on publicly disclosed vulnerabilities in open source software. But keep in mind that there can be lags in the reporting of any given NVD CVE entry. Timeliness has always been a factor affecting the ability of the NVD to publicize security vulnerability data. In fact, there is often a significant time lag between the first disclosure of a vulnerability and its publication in the NVD, with some research reporting an average of 27 days between the initial announcement and NVD publication.

What is NVD, and what is a CVE?

The NVD is the U.S. government repository of standards-based vulnerability management data managed by the National Institute of Standards and Technology. The NVD includes databases of security checklist references, security-related software flaws, misconfigurations, product names, and impact metrics.

The CVE (Common Vulnerabilities and Exposures) list was created by MITRE in 1999. The CVE reference system assigns each publicly disclosed security vulnerability a CVE identification number. Those IDs are then provided to researchers, vulnerability disclosers, and information technology vendors.

Though the CVE list and the NVD are separate, they’re interconnected. That is, the NVD is built on and synchronized with the CVE list, so any updates to CVE should eventually appear in the NVD.

What’s the problem with the NVD?

The problem with the NVD is it often contains incomplete vulnerability data. Many CVEs do not capture vulnerable version ranges and are often too short to be useful. As I noted, CVEs may not even appear in the NVD database for some time (days, weeks, months, or even years). Sometimes this is because the vulnerability hasn’t been made public, or simply because no resources were available to research the entry. For example, four of the top 10 vulnerabilities listed in Black Duck's 2020 Open Source Security and Risk Analysis report did not have CVEs directly associated with them at the time of the report’s publication. The No. 1 vulnerability discovered in 23% of the codebases examined in that report concerns security issues in jQuery 1.x and 2.x—specifically, how scripts included in event attributes passed to the function parseHTML are executed immediately.

It’s unwise to rely solely on the NVD for vulnerability information. Many commercial software composition analysis (SCA) solutions can provide richer vulnerability data than the NVD alone, finding issues more accurately and helping you fix them more quickly when warranted. If you are using Black Duck, our SCA solution, you can take advantage of Black Duck Security Advisories (BDSAs).

What is a BDSA, and why is it better?

A BDSA is a classification of open source vulnerabilities identified by Black Duck security research teams but not published in the NVD at the time of discovery. With BDSAs, you get earlier notification of vulnerabilities affecting your codebase (often days or weeks before they appear in the NVD). BDSAs also provide more complete vulnerability data, delivering security insight, technical details, and upgrade/patch guidance beyond anything else commercially available today.

CVSS scores and more

For example, consider the Common Vulnerability Scoring System. The CVSS is an industry standard for assessing the severity of a vulnerability. Vulnerabilities in the NVD have a base score that aids in calculating the severity and can be used as a factor for prioritizing remediation. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

But the CVSS score is just a starting point for determining the real risk that a vulnerability poses. To properly assess vulnerability risk, you need additional data. Software composition analysis solutions, such as Black Duck, can also provide customers with a temporal score in addition to the CVSS base, exploitability, and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

Corresponding CWEs

BDSA records also provide key Common Weakness Enumeration (CWE) classifications for all vulnerabilities, providing our customers with essential insight into the type of weakness being exposed. CWE is a list of software or hardware weaknesses that have security ramifications. A CWE classification tells developers which type of weakness leads to the vulnerability in question. This information can help you understand what you’re dealing with and adds one more piece to assessing the severity of the vulnerability. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.