Security

Beyond CVSS: Project Context, Exploitability, and Reachability of Vulnerabilities (Part 2)

September 13, 2023
•
4 mins
In this two-part series, we look at the importance of Severity when assessing software supply chain vulnerabilities and outline how Safety combines Severity, Project Context, Reachability, and Exploitability to deliver end-to-end software supply chain security without the noise.

Welcome back to Part 2 of our series on assessing vulnerabilities in the software supply chain. In Part 1, we explored the Common Vulnerability Scoring System (CVSS), its mechanics, benefits, and limitations.

‍

In this post, we will discuss why assessing vulnerabilities based on severity alone is inadequate and introduce Safety's multi-dimensional approach, which offers a more comprehensive evaluation of threats.

The Limitations of Severity Alone

CVSS severity is not a good predictor of which vulnerabilities that actually impact security

‍

While CVSS can provide some useful data, it solely focuses on a vulnerability's severity and, most often, is not a good predictor of which vulnerabilities actually impact security at most organizations. Evaluating a vulnerability's impact on a project requires considering not just the potential damage but also the likelihood of that damage being done, the relevance of the specific vulnerability in the project, and the potential scope of the damage within the active project's specific context.

‍

Consider a critical-severity vulnerability found in a library referenced by your project, but that is neither exploitable at all within your specific use of it nor is the vulnerability known to be exploitable in the wild. In this case, the vulnerability does not pose the level of risk to your project or organization at all despite its critical severity score.

‍

Alternatively, consider a medium-severity vulnerability in a vital component of your project that is exploitable and, if exploited, could result in massive financial or reputational damage. Despite its relatively lower severity score, this vulnerability presents a much more real and immediate threat that should be addressed.

‍

With the huge growth in the number of vulnerabilities the industry is seeing today, to effectively assess and triage vulnerabilities, startups and organizations must look to contextual analysis in a consistent and data-driven manner.

Safety's Four Pillars of Vulnerability Assessment

To address massive growth in vulnerabilities and the ineffectiveness of CVSS severity, Safety combines multiple assessment criteria to calculate a single vulnerability risk score based on project context.

‍

The four criteria used by Safety to evaluate vulnerabilities are as follows:

‍

  1. Severity: Leveraging CVSS data and our team of Cybersecurity Analysts' research, Safety provides more comprehensive severity data than other providers. We manually vet every vulnerability to ensure accurate severity ratings, even if maintainers and package authorities haven't updated the details. In fact, Safety now has detailed and accurate Severity data for over 12,600+ vulnerabilities tracked in Safety DB.
  2. Project Context: Different software projects have varying significance. Some projects and components are critical for business operations, while others are less important. The same vulnerability can have hugely different implications depending on the project in which it exists. Safety allows developers and DevSecOps teams to define the Project Context for each project in their organization. This customization ensures that vulnerability severity carries the appropriate impact on the overall risk score across an organization. Project Context consists of four constituent ratings:
    • Lifecycle: The stage of the software development life cycle (SDLC) in which the project resides (e.g., development, CI/CD, production).
    • Business Criticality: The project's importance to business operations and the potential financial or reputational impact if a high-severity vulnerability is exploited.
    • Data Sensitivity: The degree of access the project has to sensitive or valuable data. For example, publicly accessible information may have minimal risk if exposed.
    • Network Exposure: The project's accessibility to networks, both internal and external. Restricted access through mechanisms lowers the risk of vulnerability exploitation by internal actors.
  1. Exploitability: This factor considers whether a vulnerability has actually been known to be exploited in reality and how easy it is to exploit. Some vulnerabilities may be theoretically damaging but are complex to exploit and, as a result, not often or even used in any successful exploits. Other vulnerabilities are widely known to be used and are easier for attackers to leverage, making them more dangerous in practice. Safety utilizes the Exploit Prediction Scoring System (EPSS) in conjunction with CVSS data to assess risk more accurately.
  2. Reachability: This criterion determines whether an attacker can access the vulnerable part of the dependency within the project’s actual codebase. Suppose a package has a vulnerability in a specific component, function or use case, but the project does not use that component, function or use case. In that case, the vulnerability is not relevant and not reachable.

‍

‍

In this example, the vulnerability has a high CVSS score (8.5). Safety further raises the risk score because the Reachability score is 100, meaning potential attackers can easily reach the vulnerability in the current project. Combined, the Safety score indicates that this vulnerability should be addressed in the context of the project in which it is used.

Comprehensive Vulnerability Assessment

By incorporating project context, exploitability, and reachability data, in addition to severity ratings, Safety reduces vulnerability noise by up to 90%.

‍

By focusing on relevant vulnerabilities, development teams can allocate their time more efficiently, prioritizing fixes based on real-world risk rather than only theoretical severity ratings.

‍

This approach results in

  • Fewer false positives and unnecessary alerts.
  • Targeted fixing of the most critical threats.
  • Huge savings in development time.

Safety's Approach with Machine Learning and Research Techniques

Safety combines Machine Learning and proprietary research techniques to conduct in-depth analyses of vulnerabilities, considering not just their severity but also their exploitability and reachability. Our extensive database provides more detailed information than other providers, empowering our customers to make informed decisions and take effective action.

The Future of Vulnerability Assessment

In an ever-evolving digital landscape, developers must not only be aware of vulnerabilities but also understand their real-world implications within their project's context.

‍

By moving beyond severity scores and adopting a multi-dimensional approach to vulnerability assessment, Safety ensures that developers can confidently code, knowing that their projects are protected from all angles.

‍

To learn more about our approach, connect with one of our software supply chain experts or email us at info@safetycli.com.

‍

All posts
Security

Reduce vulnerability noise by 90%.
‍Get a demo today to learn more.

Get a Demo

Related Research Posts

Critical Supply Chain Attack Targets Ultralytics AI Library
Security
December 10, 2024
Read more
CryptoAITools Supply Chain Attack: What It Means for Package Security
Security
November 1, 2024
Read more
Understanding the Security Vulnerability in the llama-cpp-python Package
Security
June 3, 2024
Read more