And of course a clever attacker would do this: * add some code with a subtle and accidental-looking vulnerability to a package * wait until lots of other pack

And of course a clever attacker would do this: * add some code with a subtle and accidental-looking vulnerability to a package * wait until lots of other packages were dependent on it * report the vulnerability so the package got flagged by "npm audit" as needing an urgent update * release a new version with a more damaging malicious payload in it, which everyone would rush to install. The way to stop this scheme would be for NPM to make sure that "npm audit fix" installs the earliest non-exploitable version, and to make sure that that version contained only the minimum changes necessary to fix the reported vulnerability. That would mean having engineers whose job it is to do security reviews of patches to packages that have vulnerabilities found in them, but that shouldn't be too much work to take on. I mean, how often are NPM package vulnerabilities found? Two per day, or something?[0] Also it would require that packages are reproducibly built from their published source code, which sadly isn't a thing yet.[1] [0] https://github.com/advisories?query=type%3Areviewed+ecosystem%3Anpm https://github.com/advisories?query=type%3Areviewed+ecosyste... [1] https://hackernoon.com/what-if-we-could-verify-npm-packages-c2a319cff758 https://hackernoon.com/what-if-we-could-verify-npm-packages-...