The npm registry's safe word is Socket Socket has found a way to protect developers from npm, GitHub's insufficiently safe JavaScript package manager, by wrapping it in a security blanket. The npm registry, operated by NPM until the security biz was acquired by Microsoft's GitHub in 2020, hosts software packages for the JavaScript ecosystem. It is, by its own …
>the average npm package has 79 transitive dependencies
That's the fundamental issue. When you use a NPM package, you are running and deploying code made by dozens of distinct unaccountable entities. When I use, I dunno, a typical .NET library, usually if something goes wrong I can point the finger at the library vendor, or at Microsoft, and that's it. The surface for a supply chain attack is comparatively very limited.
I don't think that adding a scanner can do more than mitigate this problem a bit. Scanners and malware are always an arms race at best.
I wouldn't know how to fix the fundamental issue either. JavaScript just does not have a standard library worthy of the name, so you need a crapload of external libraries even to do comparatively basic things.
Is there is a fix for the fundamental issue? Developers always use more code from someone else than the code they write themselves. But there's a big difference in trust between an import statement and pulling in so many transitive dependencies you need code just to enumerate them. For my projects I stick with languages where import is enough. True that limits what I can accomplish, I can live with that.
"I don't think that adding a scanner can do more than mitigate this problem a bit. Scanners and malware are always an arms race at best."
Mitigating is good. We don't always get to choose our battles, but going into an arms race unarmed will lead to tears. So far this seems well done (although I won't be needing it). Hopefully it will continue to work after Microsoft inevitably buys it.
"When I use, I dunno, a typical .NET library, usually if something goes wrong I can point the finger at the library vendor, or at Microsoft, and that's it."--yeah, and that's the problem. You can point your finger, and that's it. Nothing more happens.
NPM is a steaming pile. Everyone can see that. m$ stuff is a bigger steaming pile, but they don't let you see the details.
>You can point your finger, and that's it. Nothing more happens.
Sort of. Both MS and 3rd party lib vendors do make some effort to address issues eventually, but the same goes for NPM packages. The biggest differences are size, and fragmentation. Size: because everyone who does .NET uses MS' libraries, pretty much all of the bugs and other bad behaviors are well-known and documented, with established and well-explained workarounds. Fragmentation: if you have a problem in a NPM project, you might not even get to the point where you can point a finger, because it's difficult to even figure out whose fault it is.
I've done extensive development both in NPM environments and in .NET environments, and honestly it's difficult to argue that they are the same. I've literally spent days hunting down crap through transitive dependencies. On the other hand, when my Xceed DataGrid misbehaves, I just go to the Xceed message board and get the answer.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
