4 steps to address vulnerable dependencies

A couple of weeks back, we released Snyk’s tight GitHub integration. While building it, we were keen to make it as easy as possible to address known vulnerabilities, and explored the simplest and clearest actions you need to take to get it done. We eventually got it down to 4 steps, which proved true across all environments, from npm to Maven to Infrastructure-as-Code tools such as Chef and Puppet.

This post explains the steps, and how to implement them (for npm) using Snyk. Note that while the Snyk examples focus on testing applications using GitHub, these steps can also be done using the Snyk CLI.

The steps

Regardless of your tools or environment, here are the steps you need to take to address known vulnerabilities in your dependencies:

1. Find the vulnerable dependencies

2. Fix the vulnerabilities

3. Prevent addition of new vulnerable packages

4. Respond quickly and efficiently to newly disclosed vulnerabilities.

The first two steps help you get to a vulnerability-free state. Both are needed, as finding issues but not addressing them is not very helpful, but you can’t fix issues you don’t know about in the first place. Making Fix easy is critical, as its all too tempting to disregard alerts that aren’t easily actioned. Therefore, tools must not only support Fix, but make it super easy to do.

Once you’re free of vulnerabilities, the next 2 steps help you stay that way as your code evolves and when new vulnerabilities are disclosed. Both your application and the public knowledge of vulnerabilities are constantly evolving, requiring a continuous solution to this problem.

1) Find vulnerabilities in your repos

The first step is to test all your projects for known vulnerabilities.

At Snyk, we do this by giving you a single view to test all your repositories. Simply click “Test My Repositories” on this blog page or on our Test page, and you’ll get to a page showing vulnerabilities across all your npm-using repositories.

For each repo using npm, Snyk will map the dependencies and correlate them with our open source vulnerability database. Vulnerabilities are classified into High/Medium/Low severity for easy prioritization, and you can click through to see detailed test reports.

2) Fix vulnerabilities

For the projects that have vulnerable dependencies, your next step is clearly to make them go away. While finding issues alone is useful for assessing your current risk, what you really want to do is fix the issues. Investing in tools that simplify fixing is key, since otherwise you’ll quickly get desensitized to these errors and ignore them. The same effect happens with linting, performance testing and other quality tests.

At Snyk, making Fix easy is our primary focus, getting it down to a simple “Fix” button which auto-generates the code changes needed to make the vulnerabilities go away. To do so, Monitor a repo from the screen mentioned above, and click through to the Snyk project page (using the “View project”). There you’ll find a “Fix Vulnerabilities” button at the top right, which generates a Pull Request with the minimal changes needed to fix the issue and get back to writing code.

To fix issues, Snyk will first serch for the minimal direct upgrade you can apply to get a non-vulnerable version of the package in question. If there is no such upgrade, Snyk will aim to patch the vulnerability using open source patches from our Vulnerability DB.

"features-alert.png3) Prevent adding vulnerable packages

Security, like quality, is a continuous process. Once you’re free of vulnerabilities, you need to make sure you don’t add new vulnerable dependencies as your project evolves. And just like any other quality concern, the sooner you catch such a mistake, the easier and cheaper it would be to remediate it.

Catching issues early means adding them to your continuous testing flow, which typically translates to either CI time tests or tests as part of a GitHub Pull Request.

When you integrate a GitHub project with Snyk (by clicking the “Monitor” button mentioned above), Snyk will also add its tests to your Pull Request verification steps. This means whenever a developer creates a Pull Request, Snyk will test their changes and see if they made the application vulnerable. If so, the test would clearly fail and offer details on what can be done.

Adding tests to Pull Request makes vulnerable packages highly visible without getting in the way (you can configure the threshold). It’s useful for team members to catch inadvertent mistakes early, and a good way for open source projects to ensure contributions don’t include security mistakes. Pull Request tests are (usually) not blocking, so you can still choose to merge a change with vulnerabilities if you’re in a rush and have considered the consequences.

4) Respond to new vulnerabilities

This last step is where security diverges a bit from other quality concerns. In most cases, you only create new bugs when you modify your code. Known vulnerabilities, on the other hand, can show up even if your code hasn’t changed at all.

New vulnerabilities are disclosed regularly, uncovering previously unknown security holes in your application. These security flaws were in your application (and its dependencies) all along, but now that they are disclosed they are much more likely to be exploited by attackers. To stay secure, you need a setup that lets you quickly and efficiently learn about these new disclosures and fix them before attackers can exploit them.

At Snyk, we again aim to simplify this response. When using the GitHub integration, Snyk would remember the dependencies your application uses, as well as track changes to your package.json over time. When a new vulnerability is disclosed and added to our DB, Snyk will check if your project is impacted by it, and if so notify everybody in your Snyk organisation by email. Alongside that, we will automatically submit a Fix Pull Request, saving you another step.

Protecting all your projects

When running a test, it’s tempting to only look at the projects that have vulnerable dependencies today. These projects are indeed the only ones that require the second step - Fix.

However, keep in mind that the fact a project is not vulnerable today does not mean it won’t be vulnerable tomorrow. Be sure to monitor all of your projects so you can properly Prevent and Respond to new vulnerable dependencies as they occur.

Summary

That’s it. With these 4 steps, you’ll be in good shape tackling vulnerable dependencies. For npm dependencies, Snyk should make it extremely easy to get them done. For other platforms, you can pick your tools of choice (when they exist), but make sure you tackle all four steps.

Get started now — simply click “Test My Repositories” and you’re on your way!