Introduction:
This is going to be a short article showing you how I deal with security vulnerabilities. If you’ve struggled with update dependencies that cause security vulnerabilities in the past or you just want to see my approach, this article is for you.
As far as I know, no one likes to deal with alerts such as the one above. Instead, we would like to write some new features or cover more of the code with tests, but this work still has to be done. OK, no more introductions. Let’s dive in.
Goal
Our goal should be to resolve all security vulnerabilities or at least those with the highest severity. We can recognize four types of severity level:
- Critical
- High
- Moderate
- Low
You can always start by sorting them according to severity level. Basically, a good approach is to look into Dependabot alerts once in a while in order to not end up with a situation like in the image above (48 potential vulnerabilities).
Dependabot
First, if you have the possibility to add Dependabot Preview
from the GitHub marketplace, do it. It’s completely free.
The “Security advisories handled automatically” option will be especially helpful for your case. To achieve that, Dependabot creates pull requests with dependency updates.
If you have Dependabot configured, you can go to the pull requests page and try to merge the PRs created by Dependabot, which often solves the problem with security vulnerabilities.
Workflow
Investigate
If you can’t resolve all issues with Dependabot or you don’t have Dependabot configured at all, you can switch to the terminal and try to list all the security vulnerabilities with the audit
command:
yarn audit
npm audit
The output of the audit
command contains:
- Level of severity
- Name of suspicious dependency
- Version you should use
- Name of the package containing that dependency (I will call it the root dependency)
- Path to the dependency in the
*.lock
file - More info
Fix
package.json
The first approach will be to see if we’re using a root dependency in our application. That sounds ridiculous, but the truth is that applications often contain some leftover packages that are unused. If that’s the case, we can just remove the dependency from the package.json
file and you are done. To delete an unused dependency, you can use these commands:
yarn remove dependency-name
npm uninstall dependency-name
Otherwise, you can try to find out if a new version of the root dependency is available. If so, you should take a look at the new package version in order to know how serious the update is according to the semantic versioning.
Upgrade command
Another approach will be to use the upgrade
command:
yarn upgrade-interactive
npm doesn’t support the upgrade
tool natively, so when you use npm, you need to install the global dependency npm-check:
npm install -g npm-check
npm-check -u
The interface follows semantic versioning (take a look at color legend
in the image above).
Navigate through the upgrade interface with the keyboard arrows, select the package to update by pressing the space key, and hit enter to accept all of the changes.
You can use --latest
with the yarn upgrade-interactive
option in order to show all possible upgrades even if they don’t match the versioning in package.json
. Those ones will be red.
Test
My approach to testing if everything is still in place is different for each update type.
- Patch: Test run.
- Minor: Test run, run an application, and click around.
- Major: Test run, run an application, click around, go to the changelog and read what has been added as well as what has been changed in the new version. Then you can navigate to a particular change and read more about it.
Closing Thoughts
You should repeat that investigate-fix-test circle until you fix all security vulnerabilities — or at least the major ones.
That is my workflow for updating security vulnerabilities. Please share your thoughts on if it works for you as well or if you found some room for improvements.
twitter: k_wdowik