SECURITY 101
How to prioritize third-party package (SCA) vulnerabilities
November 28, 2023
Prioritizing third-party package (SCA) vulnerabilities requires tools and processes that enable accurate severity and exploitability assessments. These factors are affected by the context that surrounds each vulnerability, making it critical to understand the business importance of your projects in order to identify the problems that actually matter.
In the modern software supply chain, projects often depend on thousands of third-party packages, each of which may contain vulnerabilities. As your vulnerability backlog grows, you need to ensure you're spending time on the issues that actually matter to you and your team.
Software composition analysis (SCA) tools and vulnerability scanners identify the packages you are using and report any known CVEs they may contain. Yet when it comes to addressing these vulnerabilities, working from an unfiltered list of CVEs is ineffective. There's more than one way to prioritize issues, and it can be difficult to understand which ones will actually impact your project.
Understanding the context of a risk therefore plays a critical role in vulnerability prioritization. In this article, we explore how to use context to prioritize third-party package vulnerabilities efficiently, allowing for quick remediation of the most pertinent threats.
The Common Vulnerability Scoring System (CVSS), first released in 2005, is the oldest and most frequently used framework for determining the severity of software vulnerabilities. In the years that have followed its release, CVSS has become an industry standard.
Most vulnerability scanning tools display CVSS scores next to the CVEs they surface. The U.S. government’s National Vulnerability Database (NVD) also relies on CVSS values.
CVSS scores range from 0 to 10, based on the severity of the vulnerability:
CVSS scores are calculated by combining several factors that assess a vulnerability's exploitability and attack complexity. Supported attack vectors, privileges required, user interactions necessary to expose the vulnerability, and other relevant characteristics are all taken into account. However, you don’t necessarily need to understand the math of how each factor is weighted—score calculators can be used to determine a new vulnerability's value.
Taken at face value, CVSS is a useful indicator of relative threat severity. However, CVSS alone is an inadequate strategy for prioritizing your vulnerability backlog. Aside from the problems inherent in attempting to class all vulnerabilities on a linear 0-10 scale—a problem like Log4j is surely more than 10x worse than a minor issue such as limited data exposure in a log file—CVSS acts as a measure of severity alone, not risk.
The actual risk to your product and customers is a contextual factor that will vary every time a vulnerability occurs. A vulnerability with a high CVSS rating may in fact be innocuous if it's not exploitable within your product stack.
Yet despite the fact that CVSS 4.0 now acknowledges the importance of threat context, CVSS scores continue to incorporate exploitability assessments. This contradiction is confusing, as the scores include an element of predetermined risk while purporting not to. As a result, the vulnerability severity for your system could therefore be higher or lower than the CVSS score implies.
Furthermore, CVSS isn't granular enough to make precise threat priority distinctions. With no supporting context, it can be difficult to understand which "high" severity issue to tackle first. Likewise, there is no reliable way to anticipate the outcome of fixing a single "critical" severity issue as opposed to three "high" severity issues, for example.
To add a layer of depth to CVSS, the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog acts as an index of published CVEs where CISA has evidence that the vulnerability has been actively exploited.
KEV complements CVSS, with CVSS presenting the theoretical severity of a particular vulnerability and KEV providing real-world data to determine if the vulnerability is being exploited in the wild. This can help you more effectively prioritize CVEs that have similar CVSS scores: In the absence of any other data, if one of the vulnerabilities appears in KEV, it would be prudent to deal with that one first.
However, KEV is not without drawbacks of it’s own. Firstly, it provides minimal information about each vulnerability—it's really just a list of CVEs, usually without any description of how the exploit occurs or what kind of attack has been observed. In addition, KEV only tracks CVEs, so issues that haven't yet been assigned an identifier won’t be tracked.
Another shortcoming of KEV is its relatively small database. At the time of writing, it records just 989 exploited vulnerabilities, despite purporting to be "the authoritative source" for information on exploited vulnerabilities. CISA claims that data is sourced from "security vendors, researchers, and partners," but it is clear that KEV is indexing far fewer reports than other databases—including EPSS, which, at the time of writing, has observed exploits of over 12,000 unique vulnerabilities.
The Exploit Prediction Scoring System (EPSS) is a relatively young initiative from FIRST, the same organization that backs CVSS. EPSS aims to produce an accurate assessment of the exploitability risk for new vulnerabilities. It outputs a probability score between 0 and 1, with 1 indicating certainty that an exploit will occur within the next 30 days.
EPSS is data driven, with its scores based on analysis of known exploit attempts. This analysis is then combined with data from threat intelligence providers to produce an estimate of how exploitable a new vulnerability will be. EPSS 3.0, the latest version (as of the writing of this article), uses a dataset that’s based on 6.4 million exploit attempt observations.
Because EPSS scores measure the probability of exploitation within the next 30 days, the value assigned to each vulnerability is constantly changing. EPSS is updated daily to include the latest data and threat observations, enabling more accurate prioritization of your vulnerability backlog.
In addition, EPSS produces more discrete scores than CVSS, making it better equipped to assist with precise prioritization. Fixing all "high" or "critical" vulnerabilities based on their CVSS score alone often means fixing the majority of detected issues, since so many CVEs end up with scores in these ranges. Choosing to address solely those issues with an EPSS value above a certain threshold, however, means you will only need to resolve a small portion of those detected. This is because many CVEs have a low chance of exploitation, even if they have a severe impact when exploited.
EPSS – like CVSS and KEV – is ultimately just another signal you can use to determine whether a vulnerability needs to be addressed and then the priority it should be assigned. All vulnerability remediation decisions must take into account the unique business and organizational context surrounding the threat as well.
As context is specific to your organization, product, and codebase, you must first understand the business importance of your repositories. This requires accurate cataloging of your project inventory and knowledge of how different dependencies are being used.
To establish conviction on the importance of an asset, you should answer questions such as:
Assessing the business relevance and context of vulnerabilities should be the first step in your prioritization funnel. You may actually want to first determine whether the vulnerability affects your organization, and then analyze the severity (CVSS), theoretical exploitability (EPSS), and the availability of any mitigations.
This knowledge will enable an informed assessment of vulnerability priorities. For example, a vulnerability with a high CVSS score (severity) but low EPSS score (exploit likelihood) might be high priority if it is in a critical package that is directly used by one of your core products. Similarly, a vulnerability with a low CVSS score may need to be treated as a high priority issue if it has a high EPSS score and is contextually significant in your stack.
Prioritizing third-party vulnerabilities is challenging, as evident from the variety of scoring systems that have emerged—from different versions of the CVSS severity standard to the increasingly popular EPSS exploitability model.
As demonstrated, none of these frameworks can accurately prioritize vulnerabilities for you. They provide useful signals but lack critical contextual information about how different dependencies will affect your product, business, and deployment environments.
Are high-severity issues in code that never reaches customers actually worth prioritizing? If you also have low-severity but highly exploitable vulnerabilities in the same project, they may not be.
Arnica’s security posture management, including SCA, SAST, and vulnerability scanning, empowers you with 100% code coverage and provides actionable alerts where developers are already working to identify the vulnerabilities that matter most. Automate your supply chain security. Get started with Arnica or schedule a demo today.
