Click here to go straight to installation guide.
Say you use Package A, which depends on Package B, which depends on Package C and so on.
A > B > C > D > E
What if Package A uses outdated version of Package B?
If newer version(s) of Package A has updated its
package.json to use updated version of Package B, you simply update your
package.json to update Package A.
What if Package A is no longer maintained? You can fork its repo, update the package and re-publish under a new name. For example, hexo-autonofollow uses outdated version of cheerio, hexo-filter-nofollow meanwhile uses more recent version.
If you have time to fork and more importantly fix any compatibility issue (example), why not?
Now, what if E is vulnerable? For example, hexo-fs package has a vulnerability introduced by chownr package. The dependency path is
[email protected] › [email protected] › [email protected] › [email protected] › [email protected] › [email protected].
So, you fork, fix it and republish with a new name. Cool. Here comes the fun part, you also need to instruct tar to go for the renamed package. Fork, fix and republish. Repeat this for all the packages along the path.
Practically, you can use Snyk to patch it, if possible like this hexo-all-minifier. Snyk is free for open-source projects. Much like any other security products, Snyk is not a silver bullet to the NodeJS issue. Some like hexo-fs can’t be fixed (at the time of writing).
- Sign up for a new Snyk account.
- Snyk only supports SSO, no e-mail sign up. You need to have GitHub, Bitbucket, or Google account. It can be a separate account from your current GitHub account. Linking your current GitHub repo to Snyk is optional.
- Once you signed up, go to your account setting, grab the API token and save it in your password manager (or somewhere safe).
- Install Snyk,
$ npm install snyk # Add 'node_modules/.bin' to $PATH, if you haven't done so. Check ~/.profile before running the following command. $ echo 'PATH="$PATH:./node_modules/.bin"' >> ~/.profile
cdinto your repo folder.
- Login to Snyk,
$ snyk auth. Snyk website will pop-up.
- Once authenticated, you can start to use it.
- Test for vulnerability,
$ snyk test.
- If there is any vulnerability, run
$ snyk wizard.
- Snyk will prompt you for a possible action (update, patch or ignore).
- Snyk will ask if you want to add its commands to
package.json. This allows Snyk to check every time you
$ npm install. I don’t add it because it doesn’t play nice with CI.
.snykfile will be created. You can review it in a text editor.
- If fix is available, run
$ snyk protect.
- In step 10, if you choose to ignore, Snyk will ignore the issue for 30 days by default (even after you run
snyk test. Once elapsed,
$ snyk testwill say there is vulnerability again (and fail your build/CI). If you find it annoying, you can delay the expiry date in
- Lastly, link the project to your Snyk account,
$ snyk monitor. Your project will shows up at your Snyk account. Go to the project setting and add your github repo link. This is necessary to remove usage quota for open-source projects.
- Optional: add
snyk monitorcommands to your CI script to protect your CI build image.
Attention: Snyk depends on GNU version of
patch utility, so you need to install it if the CI build environment is Alpine or BSD. Otherwise,
snyk protect won’t work. Read my newer post for more info.
Edit: Snyk v1.131.0 onwards no longer use
Alternatively, you could integrate directly to your remote repo (github/gitlab). This integration allows Snyk to automatically create pull/merge request. Enable this by going to your Snyk account and Integrations tab.