Skip to main content

Prioritize fixes more efficiently with Reachable Vulnerabilities for GitHub

Escrito por:
Daniel Berman
Daniel Berman
wordpress-sync/Prioritisation-header-9

21 de janeiro de 2021

0 minutos de leitura

We are pleased to start the new year with the beta availability of Reachable Vulnerabilities for GitHub, providing development and security teams with deep application-level context for vulnerabilities identified in GitHub-hosted applications and enabling them to prioritize fixes more efficiently.

Announced in July last year, Reachable Vulnerabilities analyzes an application’s execution path to identify whether the vulnerable part of a dependency is indeed reached or not. This application-level context can then be leveraged to ensure fix efforts are focused on the right set of vulnerabilities—those posing the greatest level of risk to the organization.

Snyk CLI users are already using Reachable Vulnerabilities to prioritize fixes for their vulnerabilities, and we are now happy to announce the extension of this capability to support our GitHub integration as well, making prioritization in GitHub-managed repositories much easier.

wordpress-sync/reachable_vuln_card

What “reachability” is, and why it matters

Most SCA (Software Composition Analysis) solutions scan your application to determine which open source dependencies are being pulled into the application, and will subsequently compare these findings to a vulnerability database to produce a report on vulnerable dependencies.

These reports will slowly grow to consist of hundreds, if not thousands, of issues. Since organizations cannot tackle all of these vulnerabilities, nor should they, they must prioritize. Most solutions on the market will provide CVSS-based severity levels to help guide prioritization, but when facing hundreds of high severity vulnerabilities, or five vulnerabilities with the same CVSS score, this is simply not effective.

This is where “reachability” comes into the picture, providing you with the deep, application-level context, needed to help you assess risk quickly and more accurately. Just like eating from the healthy parts of a rotten fruit, a vulnerability in one part of your code does not necessarily mean that the entire library is vulnerable. Vulnerabilities not being reached will usually not compromise the application as a whole and therefore pose less of a risk compared to vulnerabilities that are reached.

Reachable Vulnerabilities dramatically reduces the number of vulnerabilities requiring urgent attention. Around  3% of the vulnerabilities found in the Java maven projects we’ve tested with Reachable Vulnerabilities are indeed “reachable”. Does this mean that the remaining vulnerabilities can be discarded? Of course not. They also are important and need to be triaged but herein lies the difference between urgent and important.

How does Reachable Vulnerabilities work?

If you’re curious as to how Reachable Vulnerabilities actually works, this blog post provides a deep technical dive into how Snyk combines proprietary security research with automated static analysis to perform the analysis needed to provide accurate and deep application-level context on identified vulnerabilities.

The extension of this capability to support our GitHub integration involved some additional engineering work. The key ingredient that enables the analysis is the creation of a call graph that maps the various interactions between your application and dependencies. For GitHub-hosted applications, Snyk clones your repository, builds the application and creates the call graph needed to determine reachability. Once the call graph is created—all the source code is removed from Snyk’s servers.

Enabling Reachable Vulnerabilities for your GitHub projects

Integrating Snyk with GitHub allows you to continuously perform security testing across all your GitHub-hosted code repositories to find vulnerabilities in your open source dependencies and subsequently fix them using automated fix and upgrade workflows. So if you haven’t already, follow the steps outlined in our documentation to set up your initial integration with GitHub.

Reachable Vulnerabilities for GitHub is NOT enabled by default. Fully appreciating data security requirements, this functionality requires you to manually opt-in to perform the analysis.

So, to enable Reachable Vulnerabilities for your GitHub projects, open the organization settings for the GitHub integration, and simply use the toggle switch in the Reachable vulnerabilities analysis section.

wordpress-sync/enable_reachable_github_settings

Reachable Vulnerabilities will then be enabled for any new GitHub project you import AND for existing GitHub projects which will be analyzed once a daily or nightly test is executed.

Prioritizing with Reachable Vulnerabilities

Once enabled, various indicators and reachability information are displayed on the relevant project pages within Snyk which can then be used to quickly filter the various issues identified in the project.

wordpress-sync/reachable_vuln_card_annotated

Reachable Vulnerabilities is also factored into Snyk’s Priority Score (1)—an advanced, built-in scoring system powered by a proprietary algorithm that processes a wide array of factors, such as CVSS score, the availability of a fix known exploits, how new the vulnerability is, and—as mentioned - whether it is reachable or not. The resulting score is displayed on the top-right corner of the individual issue cards and can be used to quickly filter and sort through your backlog.

A reachability label (2) is added to relevant vulnerabilities and you can use reachability filters (3) to quickly sort through the issues identified for the project and focus on those posing the greatest risk. Snyk also displays detailed information (4) on the exact path through which the vulnerable function is called by the application.

Fixing with Reachable Vulnerabilities

Snyk’s GitHub integration enables you to not only identify issues but also fix them as part of your git-based workflow.

You can manually trigger a pull request directly from the vulnerability within the Snyk UI. To make things even easier, Snyk will automatically trigger a pull request in a number of scenarios—when Snyk identifies a new fixable vulnerability or if a new fix becomes available for an existing vulnerability. Snyk’s Backlog Management will also trigger a pull request based on the Priority Score (read more about Backlog Management here).

All of these pull requests display reachability information, together with the other fix advice Snyk provides, on the pull request’s Conversation tab, context that will help you make the decision to merge much simpler.

wordpress-sync/fix_reachable_github

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

wordpress-sync/filter_reports_reachable_github

Get started now!

Accurate and fast risk assessment are the key ingredients for effective prioritization. CVSS might be a good enough starting point, but is simply not comprehensive enough and does not provide deep context into the subjective factors pertaining to a vulnerability.

By analyzing the application’s execution path and correlating with Snyk’s rich security data, Snyk’s Reachable Vulnerabilities - now also available for GitHub-hosted applications - provides the deep application-level context required for effective prioritization.

Reachable Vulnerabilities for GitHub is gradually being rolled out in beta, to all Snyk plans, supporting Java (Maven) projects for now. If you can't wait and want to get access sooner, reach out to us at: support@snyk.io. For more details, please see the main documentation.