Securing Critical Devices Demands Multi-Source Vulnerability Data

As software-driven products have grown in complexity, detecting vulnerabilities has become a complex task, demanding simultaneous sources, tools, and reports. 

The real challenge lies not in identifying vulnerabilities but in discerning their relevance and potential impact. An internal study from 2023 revealed that on average 70% of identified vulnerabilities are not relevant, requiring no action when analyzed against specific products. However, not all companies know the irrelevance of their vulnerabilities until a product security analyst goes on a mission to obtain complete information and identify if it applies to their device. 

False positives and negatives have plagued cybersecurity teams for years, eating up resources and sending them on wild goose chases. This creates significant business pain, as resources are wasted on chasing down false leads instead of focusing on genuine threats– and the impact is real. With stricter internal policies and new regulations, relying on a single source like the NVD leaves teams with incomplete information for critical decisions.

NVD data should be augmented with additional vulnerability sources to understand the ins and outs of a vulnerability and where it applies. On our Product Security Platform, for example, we rely on both automatic and manual research so companies can gain from the research and insights of our analyst team.

A recent customer engagement reinforced that notion for me yet again, especially the importance of multi-source vulnerability analysis.

Upon researching a software-driven component, one of our customers informed me that an internal scan found 59 more CVEs than the Product Security Platform. 

While looking deeper into how such a wide gap could occur, it became apparent that there were inconsistencies between the information provided by the National Vulnerability Database (NVD) and advisories provided by the organization that maintains multiple components there found within this device. 

To explain how this can happen, let’s focus on CVE 2009-1386 – an example of one of the CVEs that fell into this gap. 

Research

The internal scan flagged software package within the device was OpenSSL V0.9.7c, which our Vulnerability Management CoPilot automatically scans, discovers, and triages threats, found no problem with it, but the NVD did.

At the same time, the official vendor advisory validated my initial hunch– that it only applied to versions 0.9.8 and above.

Existence of the multi-source vulnerability also in earlier versions:

In the commit information we can see that the fix was done in the vulnerable source file according to the the CVE description in NVD: ssl/s3_pkt.c

In addition, we found that this source also existed in OpenSSL v0.9.7c, raising the question if this version is affected as well, and if OpenSSL neglected to mention it since this version is no longer supported.

Reconciling vendor contradictions

Upon reaching out to Open SSL for clarification, it appears that the vulnerability applies to anything before 0.9.8 but it has yet to specifically mention any edition of 0.9.7. This same incident has occurred before, regarding vulnerabilities in Linux kernels in the NVD, where a wide range of impacted versions are highlighted but linuxkernelcves.com will give more specifics on which impacted versions are included.

Upon communicating directly with OpenSSL, it turns out that even though the source code exists in earlier versions, it is related to a protocol that wasn’t supported before 0.9.8.

Since the Product Security Platform aggregates vulnerability data feeds from multiple sources and had the data that the NVD was missing, it correctly did not include it in the assessment report.

We closed out our conversation with them by identifying more CVEs with similar discrepancies in the NVD and OpenSSL updated NIST with more complete and accurate information. 

The gap of 59 vulnerabilities was the result of a scan that was conducted without complete information- resulting in legwork, research, communications, and ultimately the continuation of the original task at hand. 

When considering that a single scan can identify upwards of a thousand vulnerabilities, it’s critical to have all of the right data sets to triage and manage risk without the stop-and-go that is common amongst teams. Just as we had to dedicate resources to solving this puzzle, so too do product security professionals in the field need to comb through each vulnerability. Without complete information from multiple reliable sources, teams struggle to properly prioritize and address vulnerabilities in the most efficient way possible.

When considering the increasing software complexity alongside greater demands, reliable processes, and data must be utilized to see a problem from every angle and determine if it is an immediate threat or an irrelevant pest. Our platform’s ability to aggregate multiple vulnerability data/threat intelligence feeds is augmented with additional data from our research team, leading to a greater foundation of a complete, comprehensive, and accurate vulnerability database that is much more reliable.

To learn more about how we help teams better conduct and manage product security, book a demo.