[userbinator]

I have a feeling that a lot of other systems also provide "the capability for a self-replicating worm", as that's just the nature of computers in general, and part of why they're so very useful.

To me, the fact that this "vulnerability" requires explicit user action, akin to deliberately downloading and running malware, says that it's really a property of all software ecosystems in which people can publish and disseminate freely.

In that respect, it's nice to see a "this is as intended" response instead of the typical direction of coming up with a set of more draconian policies and processes merely to protect users from themselves.

But given what "security research" these days seems to involve, I can almost imagine in the future: "Vulnerability #1048576 - computer allows users to perform potentially malicious actions."

[vjeux]

As a developer in the node ecosystem, you run npm install multiple times a day. If one of the dependency you require has been infected, it will look for all the packages you own on npm and will publish a new infected version. Now any time another developer that has one of your packages as dependencies does npm install, it will infect that person again.

Once it reaches a package like left-pad that is used by a ton of libraries, it will instantly infect hundreds of thousands of developers.

[NathanKP]

Solution:

1) Pin your packages to a specific version. If you aren't doing this already they you are in for a world of hurt when someone who doesn't know what they are doing releases a breaking package change on a minor version number.

2) Shrinkwrap your packages. Once again if you aren't already doing this then you npm install will probably break about once per three months when someone pushes a bad package to NPM.

3) Publish your NPM packages from an NPM in one vagrant development environment and run your code that installs from NPM in another vagrant development environment. If you have one shared environment then you are going to have other issues of which the small chance of an NPM worm is probably going to be the least of your worries.

[jjnoakes]

You forgot (4): either never upgrade (missing out on security and bug fixes) or audit every update to every package which you are pulling down (which in node could be thousands)

I prefer sticking to curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence. I get security updates, bug fixes, far fewer breaking changes, regular updates, reasonable assurance that code works together, and lower risk.

NPM has a lot to learn.

[NathanKP]

> curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence

How does this differ from how NPM works? For example the set of packages that is utilized by Express is downloaded more than 5 million times per month. There are tons of eyes all over those packages.

Sure if you are installing sketchy packages that have 100 downloads a month you have to do a lot of auditing yourself, but when sticking to the core modules that are used in practically every node project you can benefit from the auditing being done by all the others who use those packages.

[jjnoakes]

I don't think there are eyes all over those packages though.