Even the Aggregated CVE Database Isn’t Enough

Editor’s Note: In Part 1 of the blog, we discussed how Asimily created a comprehensive CVE database to fill gaps that have recently been introduced in the CVE process. In this blog, we’ll explore how even an aggregated CVE Database isn’t enough and how Asimily has gone further to ensure that organizations have a best-in-class Vulnerability Program. 

An aggregated CVE database is extremely valuable, yet has limitations in its applicability to a robust vulnerability management program. Consider that in 2024, there were 40,077 vulnerabilities reported to the CVE database and provided with a CVSS score. There are potentially thousands of vulnerabilities with High or Critical severity scores that need to be immediately addressed, and many with Low or Medium scores that may cause substantial issues on their own. 

While the severity score can be useful for ranking vulnerabilities, it is a nebulous signal of risk without additional context. Centralized reporting of vulnerabilities, while helpful in aggregating the swath of new CVEs discovered regularly, provides limited context about the vulnerability beyond that it affects a specific target. This means that reporting the vulnerability only alerts security teams that they need to investigate; it does not offer insight into how that vulnerability might interact with other systems. It also does not provide information on whether a CVE adds risk for a given device in its business context and environment. 

Adding information on whether a CVE is exploitable in the wild (as Asimily does) as part of an aggregated CVE database provides another layer of information to narrow down CVEs that matter, but even that does not account for many other vectors: 

• Can a CVE be taken advantage of in a given environment?
• Are there compensating controls that can mitigate that CVE?
• What actions can be taken to reduce Risk?
• What is the impact of the CVE for that device or the larger environment it is in?
• These questions determine how the CVE should be addressed in a wider and more sophisticated vulnerability program.

This is where Asimily’s comprehensive new vulnerability management approach comes in. 

A New, Comprehensive Vulnerability Management Approach 

Organizations need to adopt a more comprehensive approach to vulnerability management that uses the CVE database but then dives into whether it is worth investigating in the network. 

Once the CVEs have been correctly matched to the devices, this involves a few different questions that need to be answered:

1. What are the different ways in which a CVE can be taken advantage of?
2. Is the device configured and connected in a way that allows the CVE to be taken advantage of?
3. Are there compensating controls on the network or the device that prevent specific attack vectors?
4. What is the operational impact of such an attack getting through? Are the other kinds of impact that need to be considered?
5. Is it currently or soon-to-be exploitable in the wild?  

Other factors need to be considered as well. For some of the above, like point five, ISA provides the Known Exploited Vulnerability (KEV) catalog that identifies which CVEs are being used in active threat actor campaigns. This is important directional guidance for teams seeking to resolve vulnerabilities that are actively being exploited. Many other such sources need to be aggregated to get a comprehensive answer on exploitability.

Beyond that, other data sources and analyses need to be done to prioritize CVEs, such as:

• Specific software or hardware in their tech stack 
• System architecture design 
• Network communication flows 
• Other security controls are already in place 

A critical vulnerability in one system, for example, may not have any impact on an organization’s architecture if the impacted technology, for example, is limited in its communications with the rest of the network. Each CVE for every device may impact organizations in entirely different ways depending on the specifics of their network, so it’s incumbent on organizations to determine how they are impacted by every relevant identified vulnerability. 

This is the basis of the risk-based vulnerability prioritization in the Asimiliy platform. Where traditional vulnerability management has focused on CVSS as the sole determiner of which vulnerability gets resolved first, a risk-based approach instead examines the specific context of the system to determine remediation order. 

To ensure the above, along with different sources, detailed context of the network, Asimily Labs does monthly research on the different vulnerabilities using its own inbuilt AI-driven tools. Finally, using all the data, Asimily leverages AI to prioritize the vulnerabilities that have the highest likelihood and highest impact in the environment. Note that all of this is being done continuously, daily, for every vulnerability for every device to ensure changes in the system are being accounted for in the analysis.

Critically, Asimily is then able to provide recommendations and patching capabilities that are best in class to ensure risk from vulnerabilities is mitigated. Read our full category on Risk Mitigation here.

While the CVE database communicates the existence of a vulnerability, ultimately, it is incumbent on security teams to use additional tools to place the identified issue in the context of their systems. Without doing this, identifying the vulnerability and its mitigation does not make the organization more secure.