Prioritize with Snyk’s Open Source Vulnerability Experience

Prioritizing which vulnerabilities to fix across your application isn't always easy. Is it exploitable? Is it reachable? Will the update introduce breaking changes? Are there any other teams using this library that you should be aware of? What does the backlog look like if other changes need to be made? 

And that's just this week. Next week, it'll be the same thing all over again, with new discoveries, new version releases, and maybe even a new cybersecurity breach.

Historically, communication and prioritization between AppSec and application developers have focused on individual vulnerabilities. You've probably heard (or even said) something like:

“Snyk is saying that this is a critical vulnerability related to this library. We should upgrade to whatever version they’re recommending to remediate it.”

Frankly, it's not a bad way to discuss application security. Teams should aim to eliminate high-risk vulnerabilities from their code. Most of Snyk’s customizability, controls, and reporting are based on an evaluation of every vulnerability surfaced by our platform. We encourage this behavior.

But what if there was another way to think about remediation?

We thought there should be. That’s why we’re introducing a new default view for our vulnerability list, focusing on libraries rather than individual vulnerabilities. This makes it easier to understand the holistic value and impact of each potential upgrade.

What's new in the Snyk UI?

The new view in the Snyk UI groups all vulnerabilities by dependency and the versions that fix them. Gone are the days of just trying to update to the minimum version you can get away with. In its place, you'll find a true cost/benefit analysis of how many vulnerabilities you can remediate with each upgrade.

We’ve found through internal testing that developers find it more rewarding to resolve issues from this view, leading to them fixing more issues without much extra effort. If you could resolve three additional medium vulnerabilities by bumping the version up just one more minor release, wouldn't you at least consider it?

These types of discussions just weren’t possible with the old view.

This new view also unlocks the ability to evaluate library updates against one another to maximize your development team’s impact. For instance, if two libraries have vulnerabilities of similar severity, but by updating one, you also remediate seven other issues that you don't with the other, which one would you fix? Before, it’d likely be a coin flip. Now, it’s a well-informed, holistic decision.

An evolving PR workflow

Once you’ve decided which version you want to upgrade to, Snyk makes it easier than ever to create a dedicated PR. In the old view, Snyk only showed a complete list of vulnerabilities with pre-selected checkboxes, making it difficult to understand and customize the changes applied within the PR. The new view makes it simple to understand and customize which upgrades are being applied – one click confirms the version you want to upgrade to, and a second click creates a Fix PR that references all the vulnerabilities the update addresses. Having this information available right in the PR provides crucial visibility for others in your organization.

Try it out for yourself!

This experience is live across all Snyk projects leveraging Maven, .NET, npm, Python, Ruby, and/or Yarn. To view it yourself, simply navigate to an individual project within your organization. Once clicked, the new dependency-grouped view should be visible.

Happy remediating!