Defeating the NPM Worm
davidbruant.github.io
davidbruant.github.io
There are problems with NPM, for sure. Like dependency level, absence of possibility to review new releases, being rather closed than open (https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...).
Maybe going with open solutions for package management will solve most of this problems. Like using git protocol to host ones libraries on github (or gitlab or bitbucket or anything where you can fetch dependencies and get to review the code). Of course, this is not that simple as it sounds.
Although even if NPM scripts only have access to files they need to access, the damage is bad enough (e.g. if some malicious dependency of a dependency of a dependency checks if it can find a DOM and if so siphon off a copy of every password field to the attacker, every user of your website has just been compromised even if your server's /usr/bin directory is safe).
In this amount of software people build and considering that really 90% of it is total crap, we'll never be secure unless we really be picky with what we use. But that does not work with our lazy nature and all that things about bicycles you hear (like not to invent one; why would I do something by myself if I can just use someone's else solution... duhhh).
We need better quality in our software, so we can trust it.
I'm interested in use-cases where access to anything outside the current folder (the folder npm is called in) is justified and depended on.
If you are that paranoid or its that critical then you are going to have to review every single line of code, which almost no one ever does for libraries. And even so a library could always use the network to sneak more code onto the computer that you didn't authorize.
npm doesn't give any more permissions than any other program run by the user. It's a powerful tool. That isn't a reason for people to be scared of it in ordinary circumstances.
/me thinks it is weak security