SOFTWARE SUPPLY CHAIN
How to Determine the Severity of a Third-Party Risk with Software Composition Analysis (SCA)
September 27, 2023
.png)
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.
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 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
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.
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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
