npm already has "npm audit fix" to review known vulnerabilities but the point being in the blog is it's too easy to inject malicious code and I hope GitHub (MS) buying npm would make the situation better.
Perhaps if you can easily flag a package as vulnerable from npm command would make people get alerted quickly?
npm audit flag [package name]
And just show how many percent of the downloaded people have flagged it when you try to install it.
You can easily see if it's a false positive by checking GitHub issues by seeing if people are talking about any vulnerabilities.
- Get rid of custom NPM install scripts for dependencies, force modules that rely on native code to bundle WASM or be set up by the user themselves. This closes off a lot of attack vectors. JS dependencies should not be able to execute custom code when they're installed.
- Make NPM treat minor semantic version changes as breaking changes by default. Currently, `npm install` ignores lockfiles for packages with bugfixes.
- In fact, if you want to be a little crazy consider getting rid of versions entirely and using package hashes instead. This has some tradeoffs, but might have some benefits as well.
- Vendor dependencies so you don't need to worry about them changing at the source. Apparently Yarn 2 is planning to do this by default, which is encouraging.
- On a community level, consider making it easier to put user-defined filters on top of NPM that define "safe" versions of specific packages. In Arch we have a distinction between vetted packages and AUR packages. That's not a perfect system either, but it's better than NPM which doesn't really have a ton of obvious indicators whether anyone else has vetted a specific version of a package. Note I'm not saying, "have somebody moderate every single package on NPM". I'm saying, "make little whitelists of safe packages that everyone uses, and let people easily subscribe to those whitelists."
Somebody somewhere has to do the security audit in order for us to have security. The collective part is about, "how do we make sure that the dependency isn't changing behind our back? How do we figure out who has and hasn't done the audit?" The reason why security in the Node ecosystem is so individualistic is because there are so many ways to circumvent collective security audits, and so few ways for users to aggregate those audits and coordinate them.
---
Also, I'll take any opportunity to advocate that we could also solve a lot of these security problems by having a proper permissions system for Node dependencies. This makes it easier to be responsible about what dependencies need what capabilities without necessarily needing to audit every line of code.
//No capabilities, leftPad and its dependencies cannot
//access the filesystem/network/etc...
var leftPad = require('leftPad', {});
//fs-extra can access the filesystem under this location,
//but not other capabilities like network/child-processes/etc...
var fs = require('fs-extra', {
filesystem: './assets'
});
There's been some talk about doing this (see Realms), but there are still a ton of details to work out. And there's always the caveat that doing in-process sandboxing is just really hard.
Deno (Node's 'replacement') is a step in the right direction, but unfortunately only has permissions for the top-level binary. It's not trying to extend that system to dependencies, which I feel like is a kind of big mistake.
I mean, it's probably not actually going to happen, at least not anytime soon, so no.
But ideally, yes, we would head at least a little bit in that direction. SELinux has bad UX, but some of these hard UX problems are solveable with enough effort.
Nice suggestion. How do you propose this to be done?