Identify, prioritize, and fix vulnerabilities with Reachable Vulnerabilities for GitHub

Imagine you are a Java programmer and that you just decided you want to use Snyk Open Source scanning to help you find security problems in your third party libraries. Good call!

However, after connecting your repository to the Snyk Open Source scanner, you find out that you have ten or maybe even 50 vulnerabilities in the packages you depend on. The major question is: where do I start?

In a perfect world, you want to do vulnerability remediation on all issues and end with zero vulnerabilities. We are all aware that is not always feasible. Besides, you are probably not able to fix all the vulnerabilities at once. You want to start with the most vulnerable issues that impact your application and start vulnerability remediation from there. Let’s see how this works.

The application

I created a small Maven-based Java application that I put on GitHub. This application takes a URL and executes a GET request on that URL. The output is shown on the result page as plain text. This can either be the HTML of a webpage or the output of for instance a REST endpoint. I use the HTTP client from apache and a few other dependencies for executing the requests, as shown in the pom file.

<dependencies>
   <dependency>
       <groupId>org.apache.httpcomponents</groupId>
       <artifactId>httpclient</artifactId>
       <version>4.3.1</version>
   </dependency>
   <dependency>
       <groupId>javax.servlet</groupId>
       <artifactId>javax.servlet-api</artifactId>
       <version>3.0.1</version>
       <scope>provided</scope>
   </dependency>
   <dependency>
       <groupId>org.owasp.encoder</groupId>
       <artifactId>encoder</artifactId>
       <version>1.2.2</version>
   </dependency>
   <dependency>
       <groupId>org.yaml</groupId>
       <artifactId>snakeyaml</artifactId>
       <version>1.25</version>
   </dependency>
</dependencies>

Identify security vulnerabilities in your GitHub repository

To identify security vulnerabilities in my open source dependencies, I connected my Github repository to Snyk. Also, I enabled the Reachable Vulnerabilities feature that is currently in Beta. You can find this switch at Settings -> Integration -> GitHub Edit Settings. Note that everything I use here is part of the free tier of Snyk.

When Snyk is finished scanning my GitHub repository, I see that my application has many vulnerabilities that I inherit from the open source package I use. However, the Reachable Vulnerabilities feature shows me if a vulnerability is reachable from code like the one below

Prioritize vulnerability remediation

The improper input validation vulnerability is a high severe issue in the apache httpclient version 4.3.1. The Snyk UI shows me that the vulnerable function is reachable via the doPost method in my URLServlet. This specific issue refers to a URI input is not correctly validated and can harm your software. After some testing, I found out at least one of the problems.

The URI can split credentials for the hostname in a URI—for instance, http://bmv:pwd@snyk.io refers to the domain snyk.io. However, if I put another @ sign in the password part of the credentials, I can break out of the URL. Long story short, http://bmv:pwd@foojay.io:80@snyk.io gives me the result of the domain foojay.io and not snyk.io.

The reachable flag is available for the GitHub integration on the Snyk platform for Java Maven projects. This is an essential tool for prioritizing vulnerability remediation in your application. Whenever this flag is raised, a path from your code to the imported package’s vulnerable method exists.

To calculate reachability in the GitHub integration, Snyk forks your code and inspects it. We create a call graph and analyze this graph to identify if there is a path to a method that has a known vulnerability. If so, the particular vulnerability gets the “reachable” badge. In addition, the fact that a vulnerability is reachable also influences the priority score that you see in the top right corner. This score is an aggregation of multiple heuristics to help developers determine what vulnerabilities are more harmful in your context and naturally need to get a higher priority when applying vulnerability remediation.

If we scroll down in my Snyk UI, I see more vulnerabilities, including a Denial of Service issue on the snakeyaml package. Notice that this vulnerability does not have the reachable flag as I only import it and actually never call it in my example program.

Conclusion

Reachable Vulnerabilities for our GitHub integration is a powerful and free feature that helps all our users make better decisions on where to start vulnerability remediation and what vulnerabilities to solve first.

However, this does not mean we can safely ignore vulnerabilities that do not have the reachable flag. These vulnerabilities are still part of your application and can possibly be triggered in other ways.

Especially in Java, we have things like the reflection API. In addition, all classes are available through the classpath. This means that if there is an arbitrary code execution possible in your application, all available classes are ready to get loaded and exploited.

What I am trying to say here, is that vulnerabilities that are not directly reachable can still be exploited in a chain of events.  Nevertheless, Reachable Vulnerabilities enable you where to start making your application better and safer! So, what are you waiting for? Create a free Snyk account and try for yourself!

The application used in this blog post can be found in this GitHub repository.