Ahhhh CVEs!
Tags: javascript, security, react, node
Published: 2022-11-02 03:44:18

Let me start by apologizing. I haven't been keeping up to date on my blog and I am ashamed of it.


![Shame! Shame! Shame!](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r3buf776kqm3gazebjmf.gif)

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](https://en.wikipedia.org/wiki/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 😂.

![Github security tab](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2srh4hn62njbv23gi0vx.png)

## 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](https://nvd.nist.gov/vuln/detail/CVE-2021-44906). 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.

![latest release](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m6uo78568ewiobgqflmc.png)

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 👀

![Kent C. Dodds](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p2tw03q1z13eznfotmwe.png)

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](https://github.com/JounQin) forked called [eslint-plugin-i](https://github.com/un-es/eslint-plugin-i#eslint-plugin-i) which removes `tsconfig-paths` and 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.