Vulnerability Scanning is Broken

Vulnerability scanning in third-party open source dependencies, also commonly known as Software Composition Analysis (SCA), has become an integral part of most modern software development. It's crucial for security and often required for compliance certifications like SOC2 and ISO27001. However, the rapidly increasing number of open source dependencies, and consequently increasing number of vulnerabilities, pose challenges to the scalability of conventional SCAs. In this post, I will explain why conventional SCAs produce up to 95% false alerts, leading to excessive resources spent on vulnerability management.

Scanning Without Context

Most problems with existing SCAs stem from a lack of contextual understanding of programs they are scanning. To understand why context is important, let's examine a couple of real vulnerabilities as they are reported by the commonly used SCA tool Dependabot from GitHub.

CVE-2023-45133 →

This vulnerability affecting the package @babel/traverse allows an attacker to execute arbitrary code. It has an attack complexity rated as low, privileges required is none, and its severity score is a nerve-racking 9.3 out of 10. This information mirrors what users typically see in a conventional SCA, and for security engineers, it may appear rather daunting. However, if they read the actual vulnerability description they are likely to feel a sense of relief  ‘Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation’. Babel is a development dependency used to build applications, and an attacker is very unlikely to have any control over the code that goes into your build pipeline.

There is nothing inherently wrong with the information presented by the SCA, but its relevance hinges on specific contexts. For instance, if you were operating a cloud-based build service that uses Babel to compile your customers' code, then this vulnerability would be severe. The problem with the Dependabot is that it lacks the necessary context to determine whether such a scenario applies.

CVE-2023-4316 →

A recent low-severity issue in the Zod package, a popular JavaScript data validation library, allows attackers to launch a denial of service (DoS) attack by exploiting its email validation function. This function uses a regular expression that is computationally intensive for certain strings, enabling attackers to overload applications with malicious email-like inputs.

This vulnerability, unlike the one in Babel, is relevant to almost all Zod users that use its email validation feature. Despite its low-severity ranking, this vulnerability therefore poses a significant threat, acknowledged by services like Snyk, which classify it as high-severity.

Conventional Software Composition Analysis (SCA) tools, while detecting the presence of the Zod package in the dependency tree, lack specific insights into an application's use of Zod. This leads to alerts for many Zod users unaffected by the vulnerability, similar to the Babel CVE issue. Equally problematic is that users who do depend on the email validation feature of zod are left without clear information about if and how they are affected.

Why Context Matters in Security Vulnerability Reporting

The examples above underscore a significant limitation of conventional SCAs: they lack the contextual understanding necessary to provide detailed and relevant vulnerability reports. These tools cannot determine whether you are actually using the vulnerable part of an affected package, or if you are, whether it's in a context vulnerable to exploitation. As a result, conventional SCAs create lots of vulnerability alerts that simply aren’t relevant to their users. In fact, our findings at Coana reveal that up to 95% of all vulnerability alerts from these tools are completely irrelevant false positive alerts that present no security risk. The worst part is that to uncover the remaining 5% that do contain serious threats, the only real option is to siphon through each and every one of the alerts manually assessing their risk. This process, often involving the analysis of complex vulnerability descriptions, is not only time-consuming but also demoralizing given the high rate of irrelevant alerts.

This issue becomes particularly acute in organizations with dozens or even hundreds of repositories, all receiving the same vulnerability alert. This scenario is not uncommon, especially when vulnerabilities affect widely used packages like Babel or Zod. If you get the same alert across a hundred different repositories, it can be an extremely dreadful and time-consuming task to understand exactly which, if any, of the alarms are important and should receive immediate attention. To learn more about the costs vulnerability management presents to organizations, read our post Unpacking the ROI of Coana's SCA With Reachability Analysis.

Introducing Coana: An SCA with Context

At Coana, we have built an SCA tool that understands where are how your dependencies are used. This insight enables Coana to accurately identify which vulnerabilities are reachable, and thus potentially exploitable, within the context of your specific applications. When vulnerabilities are reachable, Coana also shows you exactly where the vulnerability might be exploited, which allows you to quickly plan an appropriate response. In a typical application, Coana is able to reduce the vulnerability burden by at least 80%. Not only does this limit the amount of time you need to spend on vulnerability management, but it also makes the process of handling vulnerabilities much more satisfying as you only have to focus on what really matters. You can learn more about Coana's reachability analysis in our post What is SCA with Reachability Analysis.

Interested in exploring how Coana could improve vulnerability management for you? Book a short demo below.