Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

socket.dev

Post reply on HN
Print view View original

431–440 of 1001 posts

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

#431

Post by lukan »

Ajedi32 wrote: post #420
gameman144 wrote: post #416

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

"rewrite every single dependency from scratch"

No need to. But also no need to pull in a dependency that could be just a few lines of own (LLM generated) code.

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

#432

Post by pier25 »

So glad I left JS for backend last year. It was a big effort switching to a new language and framework (still is) but it looks like so far the decision was worth it.

I'm still looking at Bun and all the effort they're doing with built-in APIs to reduce (and hopefully eliminate) third party deps. I would prefer using TS for the whole stack if possible but not at the expense of an insecure backend ecosystem.

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

#433

Post by zwnow »

AnonymousPlanet wrote: post #424
zwnow wrote: post #404

Earlier quoted context omitted.

Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.

Every place I ever worked at made sure to curate the dependencies for their main projects. Heck, in some cases that was even necessary for certifications. Web dev might be a wild west, but as soon as your software is installed on prem by hundreds or thousands of paying customers the stakes change.

Curating dependencies won't prevent all supply chain attacks though

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

#434

Post by theruss »

m3kw9 wrote: post #327

Is using any type of NPM type stuff a no go? Who reads the code and verifies is secure?

Other than the maintainer (which isn't of course guaranteed) no-one other than it being incumbent on userland deployment, and those deploying a lib into a project to review the code.

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

#435

Post by the8472 »

ncruces wrote: post #381
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

Rather than adding friction there is something else that could benefit from having as little friction as sharing code: publishing audits/reviews.

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

#436

Post by kubafu »

codemonkey-zeta wrote: post #31

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…

Took that route myself and I don't regret it. Now I can at least entirely avoid Node.js ecosystem.

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

#437

Post by sgc »

Pet_Ant wrote: post #412
ncruces wrote: post #381

Earlier quoted context omitted.

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

I find that the issue is much more often not updating dependencies often enough with known security holes, than updating too often and getting hit with a supply-chain malware attack.

There have been several recent supply chain attacks that show attackers are taking advantage of this (previously sensible) mentality. So it is time to pivot and come up with better solutions before it spirals out of control.

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

#438

Post by brianleb »

lukan wrote: post #431
Ajedi32 wrote: post #420

Earlier quoted context omitted.

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

"rewrite every single dependency from scratch" No need to. But also no need to pull in a dependency that could be just a few lines of own (LLM generated) code.

>>a few lines of own (LLM generated) code.

... and now you've switched the attack vector to a hostile LLM.

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

#439

Post by gameman144 »

Ajedi32 wrote: post #420
gameman144 wrote: post #416

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

It isn't feasible to audit every line of every dependency, just as it's not possible to audit the full behavior of every employee that works at your company.

In both cases, the solution is similar: try to restrict access to vital systems only to those you trust,so that you have less need to audit their every move.

Your system administrators can access the server room, but the on-site barista can't. Your HTTP server is trusted enough to run in prod, but a color-formatting library isn't.

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

#440

Post by nbf_1995 »

pier25 wrote: post #432

So glad I left JS for backend last year. It was a big effort switching to a new language and framework (still is) but it looks like so far the decision was worth it. I'm still looking at Bun and all the effort they're doing with built-in APIs to reduce (and hopefully eliminate) third party deps. I would prefer using TS for the whole stack if possible but not at the expense of an insecure backend ecosystem.

Just curious, what did you switch to?
Post reply on HN