Oh no, not again a meditation on NPM supply chain attacks • Hacker News Board

Re: Oh no, not again a meditation on NPM supply chain attacks

#211

Post by TZubiri » Thu, Sep 18, 2025, 3:02 AM UTC

aj_g wrote: post #104

TZubiri wrote: post #95

Earlier quoted context omitted.

Any junior engineer should be able to solve this with grep in an afternoon.

For several thousand repos? Ensuring none of the 451 package versions have been installed on any branch in any repo? I don't think it's so simple.

aikido published a list of the affected vulns.

You can probably get a list of the repos with a github API or something.

Git clone with org admin user credentials (can be read only) so you have access to all the repos.

run grep on all package.json files, search for all of the affected repos.

No need to do any code regarding versions, just filter it down and manually process versions if needed. If you have any of these packages, no matter the versions, you should already be making efforts to migrating, kill the baby with the bathwater, cut off the arm before the gangrene spreads. At any rate you can check versions manually after you have filtered it down to something reasonable, part of automating is knowing when to stop.

Re: Oh no, not again a meditation on NPM supply chain attacks

#212

Post by b_lax » Thu, Sep 18, 2025, 4:38 AM UTC

[dead]

Re: Oh no, not again a meditation on NPM supply chain attacks

#213

Post by righthand » Thu, Sep 18, 2025, 4:55 AM UTC

rs186 wrote: post #203

dns_snek wrote: post #181

Earlier quoted context omitted.

Seriously? This is is extremely low hanging fruit that's not being taken care of. You shouldn't be able to take over a software dependency with a phishing email. Requiring simple PGP code signing or even just passkey authentication would eradicate that entire attack vector. Future attacks would then require a level access of access that's already synonymous with "game over" for all intents and purposes (e.g. physical…

As long as you can publish a package in a CI environment (which is essential), none of what you mentioned matters. And that's not even the point. That phishing email is just one of the ways attackers use to infiltrate, which is not Microsoft's problem to begin with. Next time, the attacker could install malware in your machine that silently runs code and publish a package on your behalf using your own credentials sto…

You should indicate whether or not you work for or somehow are affiliated with Microsoft.

Re: Oh no, not again a meditation on NPM supply chain attacks

#214

Post by dns_snek » Thu, Sep 18, 2025, 5:39 AM UTC

rs186 wrote: post #203

dns_snek wrote: post #181

Earlier quoted context omitted.

Seriously? This is is extremely low hanging fruit that's not being taken care of. You shouldn't be able to take over a software dependency with a phishing email. Requiring simple PGP code signing or even just passkey authentication would eradicate that entire attack vector. Future attacks would then require a level access of access that's already synonymous with "game over" for all intents and purposes (e.g. physical…

As long as you can publish a package in a CI environment (which is essential), none of what you mentioned matters. And that's not even the point. That phishing email is just one of the ways attackers use to infiltrate, which is not Microsoft's problem to begin with. Next time, the attacker could install malware in your machine that silently runs code and publish a package on your behalf using your own credentials sto…

> Next time, the attacker could install malware in your machine

I already addressed this in the previous comment but I hope you realize the absurdity of this statement. If the attacker can corner you in a dark alley they can steal your yubikey and beat the PIN out of you, too. By that logic is 2FA futile and should we all stop using it?

Security isn't binary, simply raising the bar from falling for a phishing email to gaining access to someone's machine will probably eliminate 99% of all compromises.

> and you'd still blame Microsoft for not doing enough

Gaining access to someone's machine is definitive "game over" scenario, using that as an excuse not to harden security to the point that that's the only option left is lazy and irresponsible. Even with that kind of access, code signing will slow the viral spread way down which would make a difference.

Once you make it hard to hijack packages, time will be better spent on investing in sandboxing which also protects people from insider threats.

Re: Oh no, not again a meditation on NPM supply chain attacks

#215

Post by amai » Thu, Sep 18, 2025, 7:32 AM UTC

"Unfortunately, Microsoft seem to be actively hostile - in their lack of attempts to shut down an active security hole that’s almost a decade old, they have left their customers are the higest levels of risk seen in computing."

Well said.

Re: Oh no, not again a meditation on NPM supply chain attacks

#216

Post by [deleted] » Thu, Sep 18, 2025, 7:38 AM UTC

homebrewer wrote: post #25

Here's a short recap of what you can do right now, because changing the ecosystem will take years, even if "we" bother to try doing it. 1. Switch to pnpm, it's not only faster and more space efficient, but also disables post-install scripts by default. Very few packages actually need those to function, most use it for spam and analytics. When you install packages into the project for the first time, it tells you what…

[deleted]

Re: Oh no, not again a meditation on NPM supply chain attacks

#217

Post by Hexshin0bi » Thu, Sep 18, 2025, 7:38 AM UTC

homebrewer wrote: post #25

Here's a short recap of what you can do right now, because changing the ecosystem will take years, even if "we" bother to try doing it. 1. Switch to pnpm, it's not only faster and more space efficient, but also disables post-install scripts by default. Very few packages actually need those to function, most use it for spam and analytics. When you install packages into the project for the first time, it tells you what…

"...but also disables post-install scripts by default."

in pnpm docs it says:

""" enablePrePostScripts Default: true Type: Boolean When true, pnpm will run any pre/post scripts automatically. So running pnpm foo will be like running pnpm prefoo && pnpm foo && pnpm postfoo. """

am i missing something here?

Re: Oh no, not again a meditation on NPM supply chain attacks

#218

Post by em-bee » Thu, Sep 18, 2025, 1:44 PM UTC

ants_everywhere wrote: post #110

JensRantil wrote: post #96

Earlier quoted context omitted.

It's not just time. A lot of devs simply don't have the experience of dogging into third party sourcing code or understanding how one contributed to open source.

By "a lot of devs" do you mean devs at these companies? If so I think this is a good point. It's easy to see from any one open source project's perspective how a little help would go a long way. But it's really hard to see from the perspective of a company with a massive code base how you could possibly contribute to the ten gajillion dependencies you use, even if you wanted to. People will say things like "Why doesn…

it's really hard to see from the perspective of a company with a massive code base how you could possibly contribute to the ten gajillion dependencies you use, even if you wanted to

counterpoint: you don't need to actively contribute to all upstream projects, but you do need to be prepared to maintain, fix, or replace any dependency you have. if you can't do that, you should pay someone to do it. if you can't do that either then you should not be using the dependency in the first place.

yes, it can happen that you underestimate the resources needed for that, or that a project you use looked very stable and supported, but suddenly you can't find anyone who has the knowledge to fix the issue you have, but then that's simply bad luck. it can happen with company backed projects too. you need to deal with that. have no sympathy if you can't.

Re: Oh no, not again a meditation on NPM supply chain attacks

#219

Post by em-bee » Thu, Sep 18, 2025, 1:58 PM UTC

nemomarx wrote: post #136

fleebee wrote: post #121

Earlier quoted context omitted.

Is there a real reason not to use AGPL? The fact that it makes Google very uncomfortable[1] is a great selling point to me. [1]: https://opensource.google/documentation/reference/using/agpl...

For the purposes of me being facetious, it's less infectious than v3. but yeah it would have the same impact on large corps I think

it's less infectious than v3

putting aside the argument about how infectious the GPL is in general, the the current AGPL is based on the GPL v3. it adds additional requirements. so how can it be less infectious than the GPL v3?

Re: Oh no, not again a meditation on NPM supply chain attacks

#220

Post by em-bee » Thu, Sep 18, 2025, 2:06 PM UTC

austin-cheney wrote: post #142

pavel_lishin wrote: post #130

Earlier quoted context omitted.

I mean, you're right about that - but how many construction workers could build a house without having access to pre-cut lumber, pre-sharpened tools, nailguns, power equipment, pre-cast nails, etc., etc?

My neighbor works construction and my son did for a while. They were working on the new Texas Instruments silicon prefab. The people that do the actual work with their hands are expected to do just about everything. We are talking about advanced metal work in a place with liquid nitrogen and harmful chemical agents. The actual engineers just walk around to validate the work conforms to the written plans. That is why…

that's an interesting point about unions in the US. if true. because in europe (at least in austria and germany, but i suspect it's the case in most countries) unions do not do any validation of their members. having a job in an industry IS your validation to be a union member. the union then negotiates work conditions and pay on your behalf. figuring out whether you are qualified is the companies job.