Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

It's just where the users and the juicy targets are.

NPM packages are used by huge Electron apps like Discord, Slack, VS Code, the holy grail would be to somehow slip something inside them.

It's the entire blase nature of js development in general.

> is there something fundamentally wrong with NPM?

Its users don't check who the email is from

Every NPM turd should be run with bubblewrap or a similar sandbox toolkit at least.

We don't see these attacks nearly as severe or frequent on Maven, which is a much older package management solution. Maven users would be far more attractive targets given corporates extensively run Java.

It is also, in my humble but informed opinion, where you will find the least security concious programs, just because of the breadth of it's use and myriad of deployments.

It's the new pragmatic choice for web apps and so it's everyone is using it, from battle hardened teams to total noobs to people who just don't give a shit. It reminds me of Wordpress from 10 years ago, when it was the goto platform for cheap new websites.

Apparently Maven has 61.9M indexed packages. As Java has a decent standard lib, mini libs like leftpad are not contributing to this count. NPM has 3.1M packages. Many are trivially simple. Those stats would suggest that NPM has disproportionately more issues than other services.

I would argue that is only one of the many issues with the JS/TS/NPM ecosystem. Many of the other problems have been normalized. The constant security issues are highly visible.

It's actually relatively simple.

Adding dependencies comes with advantages and downsides. You need to strike a balance between them. External libraries can help implement things that you better don't implement yourself, so the answer is certainly not "no dependencies". But there are downsides and risks, and the risks grow with the number of dependencies.

In the world of NPM, people think those simple truths don't apply to them and the downsides and risks of dependencies can be ignored. Then you end up with thousands of transitive dependencies.

They're wrong and learn it the hard way now.

On Maven, I restrict packages to Spring and Apache. As opposed to NPM, where even big vendors can depend on hundreds of small ones.

Number of packages doesn’t mean much. If you can get your code into just one Javascript package you could have it run on billions of browsers. With Java it’s hard to get the same distribution (although the log4j vulnerability shows it’s not entirely impossible).

> Apparently Maven has 61.9M indexed packages.

Where did you see that number? Maven central says it has about 18 million [1] packages. Maybe with all versions of those 18 million packages there are about 62 million artifacts?

While the Java ecosystem is vastly larger, in Java (with Maven, Gradle, Bazel, etc.) it is not common to use really small libraries. So you end up with vastly less transitive dependencies in your projects.

[1] https://mvnrepository.com/repos/central

Just spit-balling here, but it seems that the problem is with the pushing to NPM, and distribution from NPM, rather than the concept of NPM. If NPM required some form of cryptographically secure author signing, and didn't distribute un-signed packages, then there is at least a chain of responsibility that can be followed.

This. You would expect some of the mature packages to be quite diligent about dependencies, but they are the one pulling random stuff for a minor feature. then the transitive dependencies adds like GBs of files to your project.

NPM isn’t perfect but no, it’s fundamentally self inflicted.

Community is very happy to pick up helper libraries and by the time you get all the way up the tree in a react framework you have hundreds or even thousands of packages.

If you’re sensible you can be fine just like any other ecosystem, but limited because one wrong package and you’ve just ballooned your dependency tree by hundreds which lowers the value of the ecosystem.

Node doesn’t have a standard library and until recently not even a test runner which certainly doesn’t help.

If your sensible with node or Deno* you’ll somewhat insulated from all this nonsense.

*Deno has linting,formatting,testing & a standard library which is a massive help (and a permission system so packages can’t do whatever they want)

There is a guy (ljharb) who is literally on TC39 - JavaScript specification committee - who is maintaining like 600 packages full of polyfills/dependencies/utilities.

It's just javascript being javascript.

That is correct.

It's both that and a culture of installing a myriad of constantly-updating, tiny libraries to do basic utility functions. (Not even libraries, they're more like individual pages in individual books).

In our line-of-business .NET app, we have a logger, a database, a unit tester, and a driver for some specialty hardware. We upgrade to the latest version of each external dependency about once per year (every major version) to avoid accruing tech debt. They're all pinned and locally hosted, nuget exists but we (like most .Net developers) don't use it to the extent that npm devs do. We read the changelogs - all four of them! - and manually update.

I understand that the NPM ecosystem works differently from a "batteries included" .Net environment for a desktop app, but it's not just about where the users are. Line of business code in .Net and Java apps process a lot of important data. Slipping a malicious package into pypi could expose all kinds of juicy, proprietary data, but again, it's less about the existence of a package manager and more about when and how you use it.

So do you expect other supply chain services that also supply juicy targets to be affected? I mean, we live in a bubble here in HN, so not seeing something in the front page doesn't mean it doesn't exist or it doesn't happen, but the feeling is that NPM is particularly more vulnerable than other services, correct me if I'm wrong.

There was a huge uproar about that guy specifically and deep dependency graphs in general a year ago. A lot has already changed for lots of the popular frameworks and libraries. Dependency graphs are already much slimmer. The cultural change is happening, but we can't expect it to happen all at once.

That wouldn't be a problem if there was proper package signing and the polyfill packages were hosted under a package namespace owned by the javascript specification committee.

Irrelevant here. You use eslint-plugin-import with its 60 dependencies; One dependency or 60 is irrelevant because you only need one token: his. They're all his packages.

The problem with that guy is that the dependencies are useless to everyone except his ego.

> Slipping a malicious package into pypi could expose all kinds of juicy, proprietary data

> In July 2024, Bittensor users were the victims of an $8 million hack. The Bittensor hack was an example of a supply chain hack using PyPI. PyPI is a site that hosts packages for the Python programming language

https://www.halborn.com/blog/post/explained-the-bittensor-ha...

You can't put this all on the users. The JS/node/npm projects have been mismanaged since the start.

node should have shipped "batteries included" after the left-pad incident. There was a boneheaded attachment to small stdlib, which you could put down to youthful innocence, except that it's been almost 10 years.

The TC39 committee which controls the design of JS stdlib and the node maintainers basically both act like the other one doesn't exist.

NPM was never designed with security in mind. It's a dirty hack that somehow became the most popular package manager.

The dependency hell is a reflection of the massive egos of the people involved in the multiple organizations. Python doesn't have this problem because it's all centralized under one org with a single vision.

Yes, there are hackers on every platform... but it feels like there's an NPM compromise announced about once a week.

With Javascript, yes, but also with all programming-language package managers and software development culture in general. There's too huge of an attack surface, and virtually no attack mitigation. It's a free for all. These are solvable problems, though. Distros have been doing it the right way for decades, and we could do it even better than that. But being lazy is easier. Until people are forced to improve - or there's some financial incentive - they don't.

This has been brewing for a long time. Maven, CPAN before it.

Maybe some of these systems have better protection from counterfeiting, and probably they all should. But as the number of packages you use goes up, the surface area does too. As a Node developer the… permissiveness of the culture has always concerned me.

The trick with playing with fire is understanding how fire works, respecting it, and keeping the tricks small. The bigger you go, the more the danger.

you can't just blame it on the platform. if the users had half a brain they'd come settle on an external "standard" library, a bit like C++ Boost. but no, everyone wants to pad their cv with a thousand packages.