Snyk Documentation

Fixing vulnerabilities

Snyk helps you to fix vulnerabilities in two ways. Either by upgrading the direct dependencies to a vulnerability free version, or by patching the vulnerability.

Fixing with Snyk can either be performed in 4 different ways

  1. by using the Source code integrations and clicking the Open a fix PR button on the project page
  2. by clicking the ‘fix this vulnerability’ link on a specific issue card on the project page.
  3. automatic pull requests - When a new remediation becomes available that helps you to fix a vulnerability Snyk can open a automated pull request.
  4. by using the cli and running the `snyk wizard` command to fix node.js projects.


Snyk will always recommend the smallest upgrade of a dependency to resolve the vulnerability. To resolve a vulnerability in a transitive dependency Snyk will calculate the dependency tree for your project and determine the minimum upgrade to the direct dependency which will result in a vulnerability free version of the indirect dependency.

Some remediations may require a major upgrade of a dependency. In this situation we indicate on the Fix PR screen if we suspect a major change causing breakage.


For Node only Snyk also provides Snyk patches. Patches are applicable in the following scenarios

  1. When there is no upgrade available for the direct dependency
  2. When there is no way of upgrading a direct dependency to get to a vulnerability free version of a transitive dependency.
  3. When an upgrade would render the package incompatible with the current codebase.

Patches are available via the source code integrations and the snyk cli.

How and when are Snyk patches created?

Snyk creates patches for high impact vulnerabilities, a vulnerability is determined high impact if it is a serious vulnerability  in a popular package which affects many users.

The Snyk security team creates the patch usually by backporting a fix which has been added to the dependency. Backporting is the action of taking a fix that was built for a particular version of a piece of software, and applying it to a previous version of that software, by updating it to be functionally identical but with the fix for the vulnerability applied. For more information take a look at redhat’s description

Once the patch is created by a Snyk Security Engineer it is reviewed by 2 other members of the team. The patch is also tested in the following ways

  1. The package is build and tested using the packages automated tests
  2. Packages or applications that use that patched package are tested using their automated tests.  
  3. Custom tests are created and run by the Snyk Security team

All patches are available for download and review by the community and we welcome any feedback.

For unmaintained packages we will create a patch and open a pull request to the project for it to be merged.

How do patches work when using the source code integrations?

When you choose to use a patch to fix a vulnerability, snyk is added as a dependency, a .snyk file is created which contains the list of patches to apply and the snyk protect command postinstall hook is added, and it is this command that is responsible for applying the patches.

The .snyk file contains the detail of the patch for example


- errorhandler > accepts > negotiator:

patched: '2017-05-05T12:39:16.961Z'

The patch is essentially an instruction stating which bits of code in the dependency need to be replaced and the code that should be used to replace it.

The snyk protect command is what replaces the vulnerable code with the patch.

How do patches work when using the snyk cli?

If you use the snyk cli to fix your vulnerable node project by running `snyk wizard` and choose to apply a patch then  two things happen:

  1. Adds snyk  as a dependency of the project (so that the CLI is fetched with npm install )
  2. Adds a postinstall  hook to run snyk protect  when npm install runs

This means that whenever the project is 'built' with npm install, all dependencies are downloaded from their source and placed in the node_modules folder, and then snyk protect  runs to patch the necessary dependencies. If the heroku buildpack invokes npm install, the relevant dependencies are patched. This is easily inspected in the buildpack output; look for "Successfully applied Snyk patches".

Since running protect is the way to repeatedly apply patches, snyk protect needs to be run every time the you reinstall your modules. Common integration points would be in your CI/build system, or deployment system, and adding it as a post installation step in the package.json file (which is necessary if you consume this module via npm or yarn).