Black Duck Security Advisories provide more-accurate information on vulnerable software version ranges to help customers get more out of NVD data. 

**Disclaimer** The information contained within this blog post was accurate at the time of writing. 

The National Vulnerability Database (NVD) is considered the go-to source for accurate information on vulnerability management data, including vulnerable open source software versions. But is it the most accurate and thorough source?

The full range of vulnerable software versions is considered the most important and useful vulnerability data—it’s vital for determining whether a given piece of software is within the range of versions affected by a vulnerability. There is no room for error when identifying vulnerable ranges. Inaccuracies can lead to false alarms, or worse, the release of misleading information that software is fixed or safe when in fact it is vulnerable.

But the vulnerable ranges that the NVD identifies are often too short or too long, meaning that vulnerable versions may be missed, or a fixed version may be included. Black Duck® Security Advisories (BDSAs), created by the Synopsys Cybersecurity Research Center (CyRC), address this issue by performing thorough research from public sources and tracing vulnerable code within source repositories. These techniques enable the CyRC to discover more-precise vulnerable version ranges and produce BDSAs with more accurate and secure information to customers.

How BDSAs provide more-accurate vulnerable ranges

A BDSA is a handcrafted report delivering detailed and concise open source vulnerability information to customers, tailored to their software Bill of Materials.

Each BDSA is created using independent research that starts, when possible, with the vulnerability report or the original researcher’s report. It also uses other trusted third-party security advisories, which often contain key information about the vulnerability. That makes it possible to determine vulnerable modules, functions, files, or variables, and that data can enable the CyRC to find a fixing commit. A fixing commit enables researchers to trace vulnerable code back to its introductory commit. The introductory commit helps define the start of the vulnerability range through the version tags associated with the commit. It also indicates that the vulnerable code does not exist in previous versions.

Accurate detection is key

It is important to clarify which versions are affected by a vulnerability and which are not. Failing to detect or mark a version as vulnerable in publicly available information may result in a false negative. This creates a false sense of security for customers, who mistakenly believe that a component version is not vulnerable when it is. If customers are not alerted correctly about whether to take appropriate action to address a vulnerability within their software, their systems might be prone to attack. The following tables include examples of instances when the NVD created false negative situations by not marking/missing versions that are vulnerable.

Why the ranges are different

When creating the BDSA for ImageMagick, the CyRC checked both the 6.x branch and the 7.x branch. The NVD did not mark the 6.x range within CVE records, nor the fixed version in this branch. The NVD marked versions 7.0.9-27 to 7.0.10-17 as vulnerable. Version 7.0.9-27 was the vulnerable version highlighted when the issue was first reported by ClusterFuzz-External on February 27, 2020. When the CVE was analyzed, 7.0.10-17 was the most recent version. This appears to be how the NVD made its version range. The NVD did not review or update the CVE record since October 2020. CyRC research discovered that there was no evidence in the repo that this vulnerability was introduced in 7.0.9-27.

The CyRC found a fixing commit in version 6.9.11-20 and an introductory commit within ImageMagick6, which was not stated by the NVD. In the 7.0 branch, the CyRC found the fix was included in 7.0.10-20, and this was introduced via an introductory commit in 7.0.1-0. Ultimately, the NVD did not correctly flag the vulnerable versions before and after the range identified in the 7.x branch. The NVD did not list vulnerable versions in ImageMagick6, which is also maintained, and it also did not list the fixed versions.

Why the ranges are different

This vulnerability was disclosed on Eclipse Jetty’s GitHub here on July 7, 2022. It was reported by rafax00. When creating a BDSA for this CVE record, the CyRC found that the fix was performed in versions 9.4.47, 10.0.10, and 11.0.10, and this was confirmed by the vendor. However, the NVD stated that the vulnerability is not present within the 9.x branch above 9.4.45, and in the 10.x branch above 10.0.8. The CyRC found that the vulnerable code is still present in version 9.4.45 and 9.4.46, is fixed in 9.4.47, is still present in 10.0.9, and is fixed in 10.0.10.

False positives

False positives happen when a report indicates that a vulnerability is present in a version when it isn’t. This type of alert to customers could result in unnecessary remediation measures for a vulnerability that may not even exist in the software version, taking up time and resources. The following tables include examples of false positives.

Why the ranges are different

This vulnerability was disclosed on July 27, 2022 on Jenkins own security advisory here. It was reported by Jesse Glick of CloudBees Inc.

The BDSA has a more refined and shortened range of vulnerable versions because the CyRC found an introductory commit by tracing through the code within the vulnerable file to find when this specific vulnerability was introduced (version 1.21.0). The NVD identifies versions below 1.21.0 as vulnerable, but the vulnerability doesn’t exist in these versions, so there are approximately 51 false positives from version 0.1 to 1.20.0.

Why the ranges are different

This vulnerability was disclosed on April 22, 2022 on Openwall.com here. It was reported by Jayden Rivers and David Bouman. For this Linux Kernel vulnerability, the CyRC identified an introductory commit in version 5.10-rc1, and using this and the fixing commit, researchers were able to identify a more accurate vulnerable range to monitor and detect fixed versions in each branch.

This more detailed range eliminates the potential of a false positive as it doesn’t include fixed versions in parallel branches/releases. Again, the NVD marked all versions below 5.10-rc1 as vulnerable, as well as all versions up to but excluding 5.17.3. This includes all the fixed versions in each branch of Linux kernel.

You can see how important it is to accurately detect vulnerable ranges. The Synopsys Cybersecurity Research Center is committed to identifying software component versions with vulnerabilities in its security advisories. The CyRC performs intricate research to provide a more accurate and trustworthy service to customers.

Learn more about the research conducted by the CyRC

Visit our website