How to Determine the Severity of a Third-Party Risk with Software Composition Analysis (SCA)

Simon Wenet
Head of Growth
September 27, 2023
Simon has spent the last decade in security leading product management & growth teams at various companies focused on DNS security, DLP, and now application security.


Software composition analysis (SCA) helps organizations mitigate security risks by providing visibility into vulnerable third-party dependencies in their application source code. While Common Vulnerabilities and Exposures (CVE) severity ratings provide a useful indicator of a vulnerability’s potential impact, the severity of an SCA risk also depends on other factors such as the likelihood of exploitation and the business importance of the application system.


Determining the severity of a third-party risk with software composition analysis (SCA)

Software composition analysis (SCA) is the process of identifying, evaluating, and managing the security risks associated with the use of third-party open-source components in the codebase of the application. In this post, we explore how to determine the severity of an SCA Risk, and strategies to expedite severity measurement for newly published Common Vulnerabilities and Exposures (CVE) risks.

A quick refresher: What is a third-party vulnerability?

A third-party vulnerability is a security flaw in a software component that is not developed or maintained by the organization that uses it, including open-source libraries and third-party packages.

While the use of open-source libraries and packages can accelerate development, it also exposes organizations to third-party security risks in the form of potential exploitation of third-party vulnerabilities and malicious third-party packages within the software. The most famous example was the Log4Shell remote code execution (RCE) vulnerability in the Log4j 2 logging library, a popular Java logging framework that is widely used in other open-source libraries and applications. This was due to a Java Naming and Directory Interface (JNDI) vulnerability that allowed a specially crafted message pattern to be evaluated when message lookup substitution was enabled.

With the number of vulnerabilities published in the CVE list steadily rising, application security teams are finding it increasingly difficult to conduct risk prioritization without the right security skill set or tools to manage and mitigate the risks introduced by the use of open-source 

What is the Common Vulnerabilities and Exposures (CVE) database?

The Common Vulnerabilities and Exposures (CVE) is a database of security vulnerabilities and exposures that have been released to the public. CVE identifiers are used to uniquely identify vulnerabilities and exposures, and are assigned by the CVE Numbering Authority (CNA). Cyber risk management, intrusion detection, and other security tools rely on the CVE database to detect known security threats in the application.

Introduction to CVE measurements

CVE identifiers include a severity rating, which is a measure of a vulnerability’s potential impact. The severity rating is based on a number of factors, including the vulnerability type, impact, and likelihood of exploitation. A vulnerability with critical or high CVE severity rating can have a severe or high impact on an organization respectively, while vulnerabilities with medium or low CVE severity ratings are expected to have relatively less of a severe impact.

EPSS, CVSS, KEV, and other security frameworks

In addition to relying on CVE severity ratings, organizations can also use other security frameworks such as EPSS, CVSS, and KEV to help them to determine the severity of risks associated with third-party vulnerabilities.

  • EPSS: The Exploit Preference Score System (EPSS) framework is a data-driven approach used to assess the probability of security exposures for a vulnerability. EPSS considers a number of factors, including the vulnerability type, impact, and likelihood of exploitation based on current threat information from CVEs and real-world exploits, and assigns an EPSS score to each vulnerability.
  • CVSS: The Common Vulnerability Scoring System (CVSS) framework for measuring vulnerability severity assigns a CVSS score to each vulnerability by taking into account the vulnerability type, impact, likelihood of exploitation, as well as other factors. Numerical constants are assigned to metrics denoted in the CVSS vector string of the vulnerability to compute the Impact Subscore and Exploitability Subscore that is used in determining the CVSS score.
  • KEV: The Known Exploited Vulnerability (KEV) framework by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) is used to assess the risk of vulnerabilities that have been exploited in the wild. KEV considers a number of factors in order to assign a KEV score to each vulnerability to determine its inclusion in the CISA  KEV list. This includes the number of known exploits, how sophisticated they are, and the availability of exploit kits.

How can I tell if my source code is exposed through a third party vulnerability?

The first step in SCA is to identify any known security vulnerabilities and exposures from open-source components in the application and to determine if the vulnerability is exploitable in the application source code.

Use software bill of materials (SBOMs) to quickly assess existence of the vulnerability

A Software Bill of Materials (SBOM) is a list of all of the software components that are used in an application. SBOMs can be used to identify the third-party components used in an application and to track their versions and license terms. SBOMs can be automatically generated with the help of SBOM tools.

SBOMs assist application security teams in identifying the risks associated with third-party vulnerabilities and actively managing them. SBOMs allow teams to list all source code dependencies, compare the versions of the third-party components with known vulnerabilities for those versions, and quickly assess the existence of the vulnerability in the source code.

Transitive risks: third parties with vulnerable third parties

Open-source packages contain two types of dependencies: direct and transitive. 

If an open-source component is directly included in the source code, it is a direct dependency. 

Should an open-source component that is directly used in the source code contain dependencies from other open-source components, it is a transitive dependency. In such cases, this implies that the source code could inherit security vulnerabilities from nested dependencies that may not be declared in the source code.

An analysis by Google’s Open Source Insights team found that more than 80% of Java packages that were impacted by the Log4Shell RCE vulnerability had inherited the vulnerability from transitive dependencies, making it challenging for developers to assess the true impact of the risks in their application context. A vulnerability from a transitive dependency is only exploitable if the vulnerable code in the dependency can be accessed from the application source code. This means a vulnerability with a high CVE severity rating could be considered lower priority if it is not used by the application or any of its dependencies. In contrast, a vulnerability with a relatively lower CVE severity rating could in fact be a more severe risk if the vulnerable code is executed and required in the application.

How to expedite severity measurement for new CVEs or risks

One of the key challenges of SCA is determining the severity of a risk associated with a third-party vulnerability. A number of factors can affect the severity of a risk:

  • Vulnerability type: Some vulnerabilities are more severe than others. For example, a vulnerability that allows an attacker to take control of a system is more severe than a vulnerability that only allows an attacker to read metadata.
  • Impact: The impact of a vulnerability can also vary. For example, a vulnerability that affects a critical system is more severe than a vulnerability that affects a non-critical system.
  • Likelihood of exploitation: The likelihood of a vulnerability being exploited can also affect its severity. For example, an easily exploitable vulnerability is more severe than one that is difficult to exploit.

In addition to these factors, organizations should also consider their own specific risk tolerance when determining the severity of a risk associated with a third-party vulnerability based on how essential the vulnerable component is in achieving the organization’s mission, and whether the vulnerable component would cause material or irreversible harm to public well-being and the organization’s business reputation. For example, a critical vulnerability in a publicly accessible application that is of critical importance to the business would be considered a more severe risk than another vulnerability with similar severity in an internally used application that supports mission-critical functions and is firewalled within a private network. 

Examples of severity measurement for new CVEs and risks

Consider the example of a newly discovered RCE vulnerability in the open-source secure networking package OpenSSH (CVE-2023-38408). It has a critical CVE severity score and the CVSS v3.1 vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. 

As the vulnerability has an Impact Subscore of 5.9 and Exploitability Subscore of 3.9, it has a base CVSS score of 9.8. At the time of measurement, the OpenSSH RCE vulnerability has an EPSS score of around 4% and is not included in the KEV list.

Since the vulnerable OpenSSH releases affect the default installations of Linux distributions such as Ubuntu, the impact of the vulnerability is assessed as high. However, the severity of the risk is not critical, as the vulnerability is relatively difficult to exploit and the impact scope is limited to the vulnerable component. Nevertheless, the vulnerability should still be monitored in the event that the threat landscape changes such that the likelihood of exploitation increases significantly.

Consider another example of a deserialization of untrusted data vulnerability in the Log4j 2 logging library due to an incomplete fix of the Log4Shell RCE vulnerability (CVE-2021-45046). It has a critical CVE severity score and has the CVSS v3.1 vector string AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. While the vulnerability has an Impact Subscore of 6.0 and Exploitability Subscore of 2.2, it has a base CVSS score of 9.0, as the vulnerability has the potential to impact other software components that are beyond the scope of the Log4j 2 logging library. This vulnerability has an EPSS score of around 98% at the time of measurement and is included in the KEV list, indicating that the vulnerability has been actively exploited in the wild.

Since the Log4j 2 vulnerability affects a wide spectrum of third-party software components including debuggers and development toolkits, the impact of the vulnerability is assessed as high. The severity of the risk would be critical as the vulnerability is easily exploitable and the likelihood of exploitation is close to 100%. Due to its widespread use in critical open-source software components with a significantly higher likelihood of exploitation at the time of measurement, the Log4j 2 vulnerability would be considered a more severe risk compared with the OpenSSH RCE vulnerability despite the lower CVSS score.

Strategies to expedite severity measurement in organizations

While the threat landscape evolves and new CVEs with higher likelihood of exploitation are added to the KEV list over time, organizations may find it challenging to keep track of changes in severity measurements for third-party vulnerabilities in their applications. However, organizations can expedite the severity measurement for newly published CVEs or risks by adopting the following strategies:

  • Ensure every product has a designated owner for the response to a new critical risk.
  • Design a process to define the business importance and business-level severity of a risk.
  • Leverage existing vulnerability frameworks to determine the prioritization of risks based on the business context.


The increasing adoption of open-source in organizations alongside the growing number of vulnerabilities discovered in open-source components has made SCA critical for companies in evaluating the severity of risks associated with third-party vulnerabilities in their applications. There are many SCA tools and frameworks designed to evaluate the severity of a risk, and it is important to take all of them into account to ensure the most severe vulnerabilities are being mitigated as quickly as possible. The organization-specific context, such as ownership and importance of the asset to the business, is also key for identifying, prioritizing, and mitigating critical third-party risks.

Quickly identify new vulnerabilities introduced by third-party packages and prioritize risks while maintaining development velocity. Arnica enables you to generate SBOM artifacts that provide clear visibility into your application and to set up developer-focused workflows to automate the risk mitigation lifecycle. Schedule a demo today.


More from our blog

The Essential Guide to SCA and SAST
The Essential Guide to SCA and SAST
March 25, 2024
A Complete Guide: Enterprise Managed Users vs Bring Your Own Users on GitHub
A Complete Guide: Enterprise Managed Users vs Bring Your Own Users on GitHub
March 25, 2024
SBOM For Your Software Supply Chain: Added Visibility or Security Risk?
SBOM For Your Software Supply Chain: Added Visibility or Security Risk?
March 25, 2024