Let me start by apologizing. I haven't been keeping up to date on my blog and I am ashamed of it.
I also almost forgot how to upload GIFs it's been that long!
Back to the topic
So recently in my career, we have been heavily focused on addressing CVEs in our code. If you don't know what CVE stands for it is Common Vulnerabilities and Exposures (read more about it in the link). I am not going into too much detail about their history and whatnot. I want to focus on why we have been addressing them. So I assume you already know what CVEs are.
Who cares about this stuff?
It's all about your situation, are you delivering a product that needs ironclad security? Do you have customers that are knocking on your door to address these CVEs? Are you developing a project for yourself e.g. side-project? For me, we have customers that are scanning the bundle of code that we deliver to them and they report back if it passes their security inspection. For my projects, I have some repos that tell me I have double-digit security issues and I don't plan on addressing them 😂.
Are all CVEs the same?
Again, that depends. There is a scale called Common Vulnerability Scoring System (CVSS) to determine its severity NOT risk. Meaning these scores are meant to inform you of which vulnerabilities you should be prioritizing which could translate to risk, but I digress.
CVSS 3.x
Low - 0.1 - 3.9
Medium - 4.0 - 6.9
High - 7.0 - 8.9
Critical - 9.0 - 10.0
Should they all be fixed?
Short answer: Yes. Long answer: Yes, eventually. This is a huge oversimplification of the CVE world. So we'll dive into it a bit more. I primarily deal with front-end code and if you are a "smart" developer you'll be utilizing open-source packages to build your web app. And as gracious as I am to all the developers pushing packages to NPM I also get annoyed (for a few seconds) with them when the package they've created is no longer supported or has a very slow upgrade cycle. More about this below. I am not trying to start a witch hunt 😅.
Let's get to fixing
So you finally get around to addressing those Critical CVEs and you start to look through your lock file to find the culprit. Let's say in this instance you are trying to resolve issues with minimist <= 1.2.5. You are looking for all the packages that list minimist as a dependency and start upgrading them one by one. You almost have all packages upgraded, nearing the finish line and you get to eslint-plugin-import a pretty popular plugin. eslint-plugin-import has a dependency on tsconfigs-path which has a dependency on json5 which has a dependency on minimist with a version, you guessed it, <= 1.2.5. You fire off yarn add -D eslint-plugin-import because YOLO and no upgrades were found. You check their GitHub to see if they have any updates to the package and you see this.
The same package I have and it's been over a year since its last release. Jeez. Ok, let me take a look at PRs and see if they have something cooking. I find a draft PR https://github.com/import-js/eslint-plugin-import/pull/2447 and in that PR there is a long thread of people going back and forth about this upgrade. With some comments from people, you may know 👀
TL;DR the CVE isn't an issue for their package and they will not upgrade tsconfig-paths to fix it. Great, this doesn't help me, because this is not an acceptable answer for our customers.
What are my options?
At this point, you have to make a decision.
- A: Don't upgrade (big negative).
- B: Use the package that JounQin forked called eslint-plugin-i which removes
tsconfig-pathsand addresses the CVE (No, because I don't know JounQin's track record). - C: Remove the plugin from your project (I was very tempted).
- D: Use resolutions in your
package.json(this).
"resolutions": {
"minimist": "1.2.6"
}
Then run yarn install or npm install and notice your lock file has "forced" an upgrade to the package version you specified.
Resolutions are a great way to have your lock file to use a specified version. BUT be careful with the versions you are upgrading from -> to. You are mostly safe with minor and patch versions, but when breaking changes are introduced in major versions that can cause you a lot of headaches for your builds. For my use case, I went with option D, we want to address the CVEs and rarely want to use an exception if a resolution to the vulnerable package works.
Change of pace
There are a few benefits to fixing CVEs:
- I am getting very intimate with the projects I work on.
- When investigating a CVE in a package I use as a dependency I search through the code to see where these vulnerabilities live and get a better understanding of how the code works.
- It's nice to get away from coding, investigation work is always a nice little bonus and I believe it helps me build better maintainable code.
- Gives you a chance to interact with the OSS community. Raising issues or creating PRs to get some fixes in is great! And it shows you are trying to build a safer experience for your users and theirs.
Top comments (0)