Optimizing prioritization with deep application-level context

Prioritizing vulnerability fixes is becoming increasingly difficult due to both the constant rise in the number of vulnerabilities and the complexity involved in assessing the risk they pose. Vulnerabilities are not born equal, and their risk variance is influenced by an array of objective and subjective factors. Effective prioritization depends on an accurate assessment of these factors.

CVSS is commonly used to overcome this challenge but suffers from some inherent limitations. Yes, CVSS v3 expands upon the base score and can include temporal and environmental metrics. But it still lacks the context of the application—CVSS does not take into account the various specific interdependencies and interactions between the application and the open source libraries and functions it calls.

This is where Snyk’s Reachable Vulnerabilities comes into the picture.

Why “reachability” matters

Most solutions analyze your application to determine which open source dependencies are being pulled into the application. This list is then compared to a vulnerability database to produce a report on vulnerable dependencies.

But a vulnerability in one part of your code does not necessarily mean that the entire library is vulnerable. In many cases, developers use only a small part of a library or package, and so there’s a good chance that the vulnerable function is not being “reached” as part of the application’s execution path. Vulnerabilities not being reached will usually not compromise the application as a whole and therefore pose less risk compared to vulnerabilities that are reached.

Snyk’s Reachable Vulnerabilities is able to dive deep into the application’s code flow and determine whether a vulnerable function is being “reached” by the application. The results of this analysis can then be used to prioritize more effectively.

Reachable Vulnerabilities in numbers

We are continuously improving the algorithms and heuristics powering Reachable Vulnerabilities but can confidently claim that the context added by Reachable Vulnerabilities dramatically reduces the number of vulnerabilities requiring urgent attention. For the 300 Java maven projects we tested, only 2% of the vulnerabilities found were actually reachable by the application. A further 20% were found to be potentially reachable.

This does not mean that the remaining 78% of vulnerabilities are all false-positives. On the contrary—these vulnerabilities need to be triaged and assessed as well with the help of Snyk's Priority Score and other prioritization capabilities. But, using Reachable Vulnerabilities for context helps you quickly pinpoint those vulnerabilities that need to be addressed first.

How does it work?

To determine whether a vulnerability is reachable, we use various algorithms to work out a call graph for the application’s proprietary code and open source dependencies. The call graph maps out all the execution paths in the application, providing us with the insight we need to understand whether they are indeed reaching the vulnerable part of the dependency.

The various dependencies and functions mapped out in the call graph are correlated with Snyk Intel Vulnerability Database - the most comprehensive, accurate, and timely vulnerability database in the market. Containing hand-curated, enriched, and actionable content on dependencies and their vulnerable functions, the database ensures the analysis performed by Reachable Vulnerabilities produces accurate results.

Snyk’s security expertise comes into play in cases where rendering a call graph is not enough to accurately determine reachability. In some applications, for example, the dependency tree used in runtime is affected by external factors. In other applications, vulnerabilities found to be reachable are actually harmless, while others need to be prioritized as if they were reachable, regardless of the call graph. Reachable Vulnerabilities applies additional heuristic techniques and analysis logic to guarantee accurate results.

Testing your projects with Reachable Vulnerabilities

Testing projects with Reachable Vulnerabilities is executed via the Snyk CLI by simply adding the --reachable-vulns parameter to the snyk test command (note - projects need to be compiled before running the test):

snyk test --reachable-vulns

Snyk commences the analysis. Behind the scenes, Snyk builds the call graph for the application and correlates it with Snyk’s vulnerability data.

Once completed, the test results are displayed in the CLI. These results include the number of tested dependencies, the number of vulnerabilities identified, and how many of these vulnerabilities were found to be reachable. A reachability level is displayed in adjacence to the vulnerability, and a path from the application’s code to the vulnerable function is displayed below.

There are three reachability levels:

• Reachable - a clear path from the application to the vulnerable function has been identified. This vulnerability should be fixed first.

• Potentially reachable - partial evidence has been found that indicates the vulnerable function might be reachable. This vulnerability should be reviewed.

• No info - there is not enough information to determine whether the vulnerability is reachable or not.

Prioritizing with Reachable Vulnerabilities

The Snyk UI provides an easier way to prioritize with Reachable Vulnerabilities within and across projects. To use Reachable Vulnerabilities in the Snyk UI, execute the following CLI command:

snyk monitor --reachable-vulns

On the Project page in the Snyk UI, reachability indicators are added to issue cards alongside the other types of indicators used for prioritization - severity and Exploit Maturity, and new Reachable Vulnerabilities filters allow you to quickly filter vulnerabilities based on reachability:

To help you quickly fix reachable vulnerabilities, Snyk also displays detailed information on the exact path through which the vulnerable function is called by the application.

Reachability data is also available on the Reports > Issues page to allow you to monitor and track your vulnerabilities more easily over time.

Get started now!

Accurate and fast vulnerability risk assessment are the key ingredients for effective prioritization. Accuracy, in turn, relies on having access to contextual information on both the objective and subjective factors pertaining to a vulnerability. That type of context is hard to come by.

Diving deep into the application’s execution path and correlating with Snyk’s rich security data, Snyk’s Reachable Vulnerabilities provides the deep application-level context required for accurately assessing risk and prioritizing accordingly.

Reachable Vulnerabilities is available in beta for all paid Snyk plans, Standard and above, and for Java (Maven) projects only. Sing up for a free account and try it out yourself!