For Node only Snyk also provides Snyk patches. Patches are applicable in the following scenarios
When there is no upgrade available for the direct dependency
When there is no way of upgrading a direct dependency to get to a vulnerability free version of a transitive dependency.
When an upgrade would render the package incompatible with the current codebase.
Patches are available via the source code integrations and the
Patches are created and maintained by Snyk. If the package owner has made code changes to fix the issues, our patch is based on this official fix, and we remove any cosmetic or unrelated changes. If a package owner has not addressed the vulnerability yet, we write a patch from scratch.
Before releasing it, we verify the patch, backport it to older versions, and test that the patch hasn’t broken functionality.
The patches are a part of Snyk’s open source vulnerability database, so you can check them out before applying them. For example, the patches for the ms ReDoS vulnerability. We don’t have patches for every case - if you need one that’s missing, let us know.
Snyk creates patches for high impact vulnerabilities, a vulnerability is determined as high impact if it is a serious vulnerability in a popular package that affects many users.
The Snyk Security team creates the patch usually by backporting a fix that 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 https://access.redhat.com/security/updates/backporting
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
The package is built and tested using the packages automated tests
Packages or applications that use that patched package are tested using their automated tests.
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.
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:
Adds Snyk as a dependency of the project (so that the CLI is fetched with
postinstallhook to run
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 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).
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 post-install hook is added, and it is this command that is responsible for applying the patches.
The .snyk file contains the details of the patch for example
'npm:negotiator:20160616': - 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.