Outdated JavaScript tooling, vulnerabilities and security
June 29th, 2019
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!
Related Resources
Created by Maria D. Campbell who lives and works in New York City building useful things. You should follow her on Twitter. She also has a developer blog mariadcampbell.com you may want to check out!