Live data from Hacker News

Keyv and friends compromised in active Shai-Hulud supply chain attack

aikido.dev

41–50 of 145 posts

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#41
The cheapest mitigation almost nobody deploys: a version cooldown. These worms get caught fast — this one was flagged same-day, and the article's own timeline shows detection racing ahead of spread. If your CI simply refuses to adopt any version published in the last N days (Renovate supports this natively via minimumReleaseAge), you convert "worm spreads through the ecosystem in hours" into "worm must survive N days of public scrutiny before it can reach you." You give up almost nothing: how often does your product genuinely need a dependency version that's 48 hours old?

Combine that with the workflow split insanitybit describes — build/test jobs holding zero publish credentials, a separate publish job that only touches a finished artifact — and the wormable path is mostly closed without waiting for npm to redesign itself.

None of this is "sufficient" in rcxdude's sense, and that's fine. Sufficiency isn't the bar during an active outbreak; raising the attacker's cost per hop is.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#42
post #19
post #15

Earlier quoted context omitted.

Nobody is claiming this is a complete solution to security. I would call this "necessary but not sufficient". You won't get far as an engineer if you refuse to implement "necessary but not sufficient" changes because the change doesn't in and of itself one-shot the entire problem.

The fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.

The term you are looking for is Defense in Depth/Layers

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#43

No way to prevent this says only package manager where this regularly happens

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent.

NPM gets targeted a lot because it's popular. That's it.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#44
post #19

Earlier quoted context omitted.

The fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.

The term you are looking for is Defense in Depth/Layers

That makes sense if it's actually a layer. You can create a thousand minor obstacles and it still won't be a very secure system.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#45

No way to prevent this says only package manager where this regularly happens

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's popular. That's it.

Other than what happened with 'xz', which was upstream of it getting packaged, how many times has this happened in the debian packages system? Also very popular.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#46

Earlier quoted context omitted.

Wouldn't the dropper get executed once tests are run within CI though?

Yes, you should separate "tests execute" into their own unprivileged workflows that don't have "deploy" secrets.

You can also do the same for the build workflow, no?

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#47

No way to prevent this says only package manager where this regularly happens

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's popular. That's it.

> NPM is by no means the worst offender here

Ok, I can agree it is a boring comment, but who is worse?

NPM gets targeted both because it is popular and because there is a wider attack surface (lots of little packages promoted by a huge variety of users) I have a high schooler who published work a couple weeks ago. This is good, but it comes with downsides. Maybe a couple more speed bumps or classifiers would be helpful. Maybe a consolidation of under maintained projects and deprecation is in order.

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#48
post #19
post #15

Earlier quoted context omitted.

Nobody is claiming this is a complete solution to security. I would call this "necessary but not sufficient". You won't get far as an engineer if you refuse to implement "necessary but not sufficient" changes because the change doesn't in and of itself one-shot the entire problem.

The fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.

Missile defense systems are unnecessary because they could just use tanks

Anti-tank measures are unnecessary because they can just use missiles

Re: Keyv and friends compromised in active Shai-Hulud supply chain attack

#50

No way to prevent this says only package manager where this regularly happens

This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's popular. That's it.

No other package manager is worse than NPM. Outside of its 'popularity', there are several fundamental reasons why this continues to happen to NPM:

- Imported packages are not pinned by default.

- Typescript / Javascript's lack of a standard library encourages the developer to import more packages into their codebase to address the short-comings which increases the risk of importing a bad package.

- Post install scripts execute external code by default upon downloading dependencies.

All of this comes by default in the ecosystem and we continue to see more shai-hulud worms all easily targeting NPM. Not even signed packages are enforced by default either.

Post reply on HN