A pretty good actual summary of the problem.<p>As the article says, I'm not convinced code signing would have made this not happen - given the distribution model you could trivially just have node library updates check to see whether the owner/maintainer had the same user name.<p>Similarly it is absolutely not the fault of the old maintainer - no one should have to commit to permanently supporting a library they wrote years in the past. And if you weren't maintaining a library why would you necessarily be opposed to transferring ownership over to someone who is at least apparently working on/with it?
We don't need a standard library, they said. Letting basic functionality be spread out through a hundred thousand separate packages is fine, they said...
Aside from validating your dependencies, when you run the code ensure it can't phone home.<p>On AWS, lock-down outgoing traffic. The Node instance (heaven help you if it's in a browser) on the back-end shouldn't be able to get out to anything, with the necessary exceptions of your codes back-end data store, and, perhaps temporarily, your deployment store.
Maybe it could come down to requiring npm modules be accessible on a publicly accessible git repository with enough instructions in the package to build that package's output. Exceptions would be the more custom/large packages than the rule. Binary packages would of course also need some exceptions.<p>There could be a concept of "trusted" packages. That have had at least a review step. So either your package is trivial and easily automated or difficult with manual review. Where the costs are absorbed is the thing.<p>In the end, I do feel that anything that's being published publicly should have publicly available source, and that the build should be repeatable at the least... that wouldn't prevent such a thing (if it was checked into git), but would at least make it harder to hide.
One thing I'm a bit confused about --<p>The attack was present in the minified JS, but not the source JS.<p>(I'm ignorant about NPM.) Does this mean on NPM, the publisher gets to publish the source AND the minified version? Is there no validation that the minified code is sourced from the true source code?
The trust issue is a fundamental issue with volunteer / anonymously-contributed open source.<p>At least with paid software, in theory if not in practice, the organization publishing the software is responsible for verifying it, and for keeping track of whom it is employing to contribute to the code, so you can figure out who to lock up if they intentionally push malicious code.
Another guy blaming a programming language because a third party independent company dont check out every single piece of line for malicious code. Kids these days think injecting 400 dependency libraries is a better idea than writing their own code. P.S Always remember, it's your responsibility to check out what code library you adding to your project.
Any thoughts on how these situations could be automatically detected by a third party given the current realities of the JS ecosystem? Here are some quick ideas:<p>1. Detect commits that are radically different from previous ones in the same repo by some measure (tricky)<p>2. Detect npm publish events whose contents are different than source repo<p>3. Detect author/ownership changes in the context of npm packages<p>What else?
What I don't understand, how come there are no automatic red flags/or permissions when a deep dependency attempts to write on desk or make network calls?<p>I mean in theory any npm package could have a payload that would hijack the machine or override other system functions, where is the security in any of that?!
This is so superficial. How can you talk about ecosystem fragility when NPM is one of the best open source companies and which actually cope with problems (unlike most package registries who are completely passive)