Going beyond reachability to prioritize what matters most

Most modern applications contain a substantial number of open source packages, libraries, and frameworks. In fact, it's estimated that at least 80% of the source code in modern applications is from open source. In addition to relying heavily on commodity components to build applications, development teams often deploy these apps and services via community-sourced container base images. They also lean on third-party resources such as AI coding assistants to generate first-party code, further accelerating the software supply chain. 

This ever-increasing usage of open source libraries, generative AI, and containers introduce new licensing and security concerns. Almost 29K new vulnerabilities were discovered in 2023 alone (and already over 28K in 2024). If history repeats itself, more than half of those newly discovered vulnerabilities will carry a high or critical severity. In other words, some of the greatest risks to your applications—and potentially your organization as a whole—come from components outside your control.

The challenges of open source security today

Finding, prioritizing, and fixing all open source vulnerabilities within your applications is unrealistic. Even aiming to only fix the high-severity vulnerabilities in your third-party dependencies can be a challenge. After all, it’s not just newly found vulnerabilities you need to tackle, but the entire backlog of vulnerabilities in your codebase. This backlog comes from a few different places—maybe you inherited them, or maybe they live in a project implemented long before you started looking for open source vulnerabilities.

Even small projects can have hundreds of vulnerabilities across dozens of direct dependencies (i.e., explicitly defined in your dependency manifests). They'll likely have even more indirect or "transitive" dependencies—the libraries that the direct dependencies need to function. Multiply all of the above by the number of projects that your organization has, and it becomes an overwhelmingly long list. 

Static prioritization techniques aren't enough

Many enterprises rely on static risk factors, like NVD/CVSS severity, to start triaging this lengthy list of vulnerabilities and prioritizing which ones to fix first. However, these point-in-time pictures of risk miss many important factors for accurate and impactful prioritization. 

Newer risk factors, such as EPSS (exploit prediction scoring system), attempt to incorporate more information about the vulnerability but still exclude key details such as the broader application or business context. Like other static risk factors, EPSS still follows a narrow, siloed focus on individual issues, not your applications. Each issue evaluated by EPSS is specific to a given CVE, as opposed to what impacts your entire organization most. 

Many companies have turned to reachability to enhance their static prioritization techniques to better understand which vulnerabilities to remediate first. Static reachability looks at the vulnerability definition, pulls information on where the vulnerability exists in a given version of a library, and then tries to determine if there is a call path from your first-party code to the function where the vulnerability likely resides. Teams can then combine different static signals, like reachability data and a high CVSS or EPSS score, to determine which fixes to address first.

While static reachability can help with the prioritization process, it can also leave gaps. For instance, static reachability might help identify code paths that are calling vulnerable functions, but the inverse isn't true: it can't definitively tell you when something is not reachable. Also, not all vulnerabilities include the information needed for static reachability analysis. There are, however, techniques that can be used to determine the functions that are vulnerable in open source packages. For example, Snyk leverages an AI-powered solution that evaluates fix commits to calculate them. 

Ultimately, using static reachability conjointly with CVSS/EPSS improves prioritization techniques, but prioritization can be enhanced even further by incorporating crucial context: the importance of a given artifact to their businesses. So, teams must consider contextual factors besides static reachability in order to accurately prioritize vulnerabilities based on actual risk to the business.

Organizations need a holistic approach to risk prioritization

One thing to keep in mind with vulnerabilities is that high criticality and reachability do not equal exploitability. 

Let's unpack this idea; say you have two vulnerabilities: a "reachable,” critical severity vulnerability that’s running in your internal dev sandbox, and a medium-severity vulnerability without reachability data running in production. Which one should you fix first? What if the medium-severity vuln in production has an easy, well-known exploit and is in an internet-exposed container on the edge? While the medium-severity vuln might seem like a no-brainer, static signals alone might actually rank the sandbox vulnerability as a higher priority!

With this example in mind, we see that static reachability often doesn’t give us the whole picture. While static reachability offers insights for priorizing vulnerabilities, it doesn’t enable teams to manage overall risk. Fixing a large number of critical severity vulnerabilities may look good on paper, but the real impact lies in remediating the vulnerabilities that pose the most potential harm to your business and its bottom line.

Here are some additional signals that can fill in the blanks left behind by static reachability: 

• Is the vulnerability even applicable to the operating system that the service is running in?

• Is the app critical to the business? Which specific role does it play and how does it relate back to the business’s key functions?

• Is it deployed? If so, where is it deployed, is it public-facing or public-reachable, and are the packages loaded?

• Does the service the vulnerability is in have access to sensitive data?

Contextual risk-based prioritization with Snyk

Because enterprises can’t resolve all open source vulnerabilities—or even all high- or critical-level vulnerabilities—prioritizing security issues correctly is crucial. At Snyk, we not only help organizations find and fix software vulnerabilities, but we also help prioritize remediation based on real-world risk to the enterprise. Our solutions strengthen organizations’ application security processes with the following: 

• Risk-based prioritization enables organizations to clearly understand the likelihood that an exploit could happen and the impact that would follow if it occurred.

• Reachability from code to cloud, including both static reachability, which analyzes code and vulnerable functions, and dynamic reachability, which looks at the app’s deployed/runtime environment. Our solution is powered by AI, and validated by human security experts, strengthening accuracy and coverage.

• Application context from SCMs, developer portals, CMDBs, and more. This in-depth context enables enterprises to further narrow down vulnerabilities to address based on code ownership, repository freshness, and other factors.

• Flexibility for enterprises, with the ability to integrate proprietary security and compliance guidelines directly into the Snyk solution.

• Holistic risk score that is simple to leverage in your AppSec efforts. These scores enable users to prioritize SCA issues across the environment or drill down and understand the impact of specific risk factors, including static reachability.

See how Snyk AppRisk works by watching our demo on demand.