- Published on
Outdated JavaScript tooling, vulnerabilities and security
- Authors
- Name
- interglobalmedia
- @letsbsocial1
I have spoken or written about this topic before, but feel the need to re-address it.
Node Security/npm audit appeared for the first time in my Terminal window in March of last year (2018). I had read that it was a new feature in npm created by Node Security, and was excited about the prospect of knowing more about what was going on under the hood with my npm packages and how that all boded for Web/Software Development and Individual Machine(s) Security. Previously, many of us were under the false impression that everything in our code, in our workflows using third party plugins and packages passed muster. But the minute npm audit came along and we downloaded various npm packages, added libraries and frameworks using those packages, or simply learned from other code using the tooling etc, if there were "known" vulnerabilities in any of the code, Node Security (now part of npmjs) would print out something like this:
ॐ ~/development/testing-javascript/js_mocking_fundamentals/1_override_object_props_monkey_patching_js:
10314 ◯ npm audit
=== npm audit security report ===
┌──────────────────────────────────────────────────────────────────────────────┐
│ Manual Review │
│ Some vulnerabilities require your attention to resolve │
│ │
│ Visit https://go.npm.me/audit-guide for additional guidance │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ braces │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=2.3.1 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ babel-cli [dev] │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ babel-cli > chokidar > anymatch > micromatch > braces │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/786 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 low severity vulnerability in 864568 scanned packages
1 vulnerability requires manual review. See the full report for details.
The first time I had done this, I was in a full stack JS class (not the boot camp by the same name, another school which has since then closed down), and we were told to clone a repo which had been created 2 YEARS before. We all did so, and I received a message in Terminal from Node Security on download, that there were around 1,000 vulnerabilities in the project. I mentioned it to the teacher, but he looked at me as if I had three heads. That was a little over a year ago. March, 2018, to be more exact.
You know what? It seems that there are still people in "teaching" positions who don't bother to check their repos, even though, most probably, Github is sending them security alerts regarding such vulnerabilities.
So this podcast is for those who might be new to the JavaScript Developer ecosystem, and might see similar warnings when cloning or downloading courses they have paid for and want to learn the best and latest practices from. Apparently, many teachers of courses don't bother to share this kind of information because it just is "not relevant" to their subject matter. You'd better bet your bottom dollar it is. It is relevant to everything JavaScript, and everything all other programming languages.
If, when you clone or download something from a repository, and then run npm i (assuming there is a package.json present), and there is a message (correction: npmjs and not Node Security) stating that it has detected vulnerabilities in your package(s), follow their instructions to run npm audit.
Oftentimes, there is already a remediation/patch/package update that will remove the vulnerabilities. Follow the instructions you receive in Terminal after running npm audit. Sometimes there is no remediation yet, or it might be difficult for you to do manually. That's when you should contact the creator/maintainer of the repository or package.
Sometimes things take a little while. After all, these packages are open source. Sometimes, however, it is not a matter of fixing the vulnerabilities in a current version of a package by simply updating to the latest version, but updating one that results in breaking changes. That's when things get a bit ugly. Sometimes developers are too lazy to have to do a complete overhaul of their workflows associated with those breaking changes, and this results in vulnerabilities in the current package(s) version(s) that won't go away. This is especially NOT COOL when it happens within course code that you have paid good money for. If the creator of the course has not updated the code/curriculum in more than 6 months or even 3 months (things these days are changing daily), think twice before signing up for it. Do a bit of detective work regarding the dependencies and devDependencies in the package.json before making your final decision. Of course, sometimes we don't have access to this information until we have actually paid for it. I don't have an answer for that.
Note: Be sure to do the same in your own open source repositories. It is hard to keep up with Github security alerts, but just do your best to do so as you can. The longer you wait, the more complicated the remediation.
I will be embedding this episode of Plugging in The Holes along with a transcript in the form of a post on interglobalmedianetwork.com for your hearing and reading pleasure. Bye for now!