I agree other repos deserve a good look for potential mitigations as well (PyPI too, has a history of publishing malicious packages).

But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attractive target.

▲

znort_ 4 hours ago | parent [-]

npm in itself isn't special at all, maybe the userbase is but that's irrelevant because the mitigation is pretty easy and 99.9999% effective, works for every package manager and boils down to:

1- thoroughly and fully analyze any dependency tree you plan to include 2- immediately freeze all its versions 3- never update without very good reason or without repeating 1 and 2

in other words: simply be professional, face logical consequences if you aren't. if you think one package manager is "safer" than others because magic reasons odds are you'll find out the hard way sooner or later.

▲

tbrownaw 4 hours ago | parent | next [-]

Your item #1 there may be simple, but that's not the same as being easy.

▲

moi2388 3 hours ago | parent | prev [-]

Good luck with nr 1 in the js ecosystem and its 30k dependencies 50 branches deep per package

▲

godshatter 2 hours ago | parent [-]

As an outsider looking in as I don't deal with NPM on a daily basis, the 30k dependencies going 50 branches deep seems to be the real problem here. Code reuse is an admiral goal but this seems absurd. I have no idea if these numbers are correct or exaggerations but from my limited time working with NPM a year or two ago it seems like it's a definite problem.

I'm in the C ecosystem mostly. Is one NPM package the equivalent of one object file? Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones? I guess it's a problem either way, internal dependencies having bugs vs supply chain attacks like these. Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary?

	▲	marcosdumay 16 minutes ago \| parent [-]
		> Is one NPM package the equivalent of one object file? No. The closest thing to a package (on almost every language) is an entire library. > Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones? Yes, they can. They just don't do it. > Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary? There aren't many unecessary dependencies, because the number of direct dependencies on each package is reasonable (on the order of 10). And you don't get a lot of unecessary code because the point of tiny libraries is to only import what you need. Dead code is not the problem, instead the JS mentality evolved that way to minimize dead code. The problem is that dead code is actually not that much of an issue, but dependency management is.