Vulnerability remediation process: reducing your vulnerability backlog with Snyk’s automatic backlog PRs

We’re happy to announce Backlog Management—a new enhancement to Snyk’s automated vulnerability remediation capabilities that enables development and security teams to reduce their vulnerability backlog at a manageable pace.

Most projects have over 20 vulnerabilities when first scanned by Snyk. It’s no wonder vulnerabilities have a tendency to pile up into what becomes an overwhelming vulnerability backlog. Even with the best of intentions, these backlogs can end up containing hundreds, if not thousands, of vulnerabilities. Fixing each and every vulnerability may feel impossible and, most likely, not necessary. You have to prioritize. But where do you start?

Earlier this year, we announced our developer-first vulnerability prioritization capabilities—a comprehensive set of developer-friendly tools that help you accurately assess risk and prioritize fix efforts. Priority Score, one of the tools announced, is already helping thousands of developers to improve their vulnerability remediation process by quickly sifting through their backlog and focus their time and effort on issues posing the greatest risk to their organization.

Backlog Management takes this intelligent, context-aware prioritization up a notch by automatically taking action—opening targeted fix pull requests to fix vulnerabilities in your backlog based on their priority score. 

Crash course: Snyk’s automated vulnerability remediation

Just in case you’re new to Snyk or are a Snyk veteran and have forgotten how Snyk helps you automatically fix vulnerabilities, here’s a reminder.

Building on top of our integrations with popular source code management systems such as GitHub and Bitbucket, Snyk automatically triggers different types of pull requests populated with actionable vulnerability fixes. You can decide upon the pace and scope of these pull requests to ensure you are not overwhelmed by too many of them.

So, when are these pull requests opened by Snyk?

There are two main types of pull requests triggered by Snyk—upgrade pull requests and fix pull requests. While both can upgrade a package, the aim is different, and therefore the way they work. The former, upgrade PRs, will be opened when Snyk identifies that new versions for your dependencies exist, and only if certain conditions are met (for a full list of these conditions, please read our docs). The aim is to keep you in the best place to avoid new vulnerabilities and make future fixes easier by staying up to date. The latter, fix PRs, will be opened in two cases—when a new fixable vulnerability is identified OR when a new fix becomes available for an existing vulnerability.

In addition, Snyk’s PR Test capability helps you ensure you are not introducing new vulnerabilities and license issues into your codebase by automatically testing any new pull request that you or any contributor opens.

Snyk’s Backlog Management supplements this existing functionality, automatically opening pull requests for fixable vulnerabilities already in the backlog and in a prioritized fashion.

How does Backlog Management fit into your vulnerability remediation process?

In a nutshell, every time recurring Snyk tests occur (by default daily, but configurable), Snyk opens one pull request per project to resolve the fixable vulnerability with the highest Snyk Priority Score.

Enabling these backlog pull requests can be done at the integration level (and so apply to all projects monitored via that integration), or at a per-project level.

To enable at the integration level, go to the settings for that specific integration via the cog icon on the integration in the Integration page.

Then look for the settings governing Automatic fix pull requests. There you can toggle the appropriate setting.

To enable this for a specific project, you need to edit the integration settings on a per-project basis. You can access these settings from the top-right of your project page:

On the Settings page for your project, click the GitHub Integration on the left, and toggle the appropriate setting in the Automatic fix pull requests section:

That’s all there is to it. Once you update the settings, backlog pull requests will be triggered as explained above, per each Snyk scan.

As with the other types of fix pull requests, these will continue to be opened, regardless of how many pull requests are already open in your repository. They will not be opened, however, for a vulnerability in your backlog that you have chosen to ignore using Snyk’s Ignore capability:

Getting started!

As mentioned, the average project has over 20 vulnerabilities when first scanned by Snyk. We are pleased to be able to offer targeted pull requests to reduce this backlog, to supplement existing functionality that already prevents the introduction of new vulnerabilities and fixes any that are newly disclosed.

Snyk’s backlog pull requests are available across all our plans—Free, Standard, Pro, and Enterprise, and are supported in GitHub, GitHub Enterprise, and Bitbucket Cloud.