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

#161

Post by inbx0 » Wed, Sep 17, 2025, 3:08 PM UTC

tanepiper wrote: post #155

simonw wrote: post #92

Question for tanepiper: what would you have Microsoft do to improve things here? My read of your article is that you don't like postinstall scripts and npx. I'm not convinced that removing those would have a particularly major impact on supply chain attacks. The nature of npm is that it distributes code that is then executed. Even without npx, an attacker could still release an updated package which, when executed as…

Oh I agree - it's far too late to make major changes. When they took over, they had the opportunity to drive a new roadmap towards a more secure solution. 2FA isn't a solution to security, it's a solution to hinder and dissuade low-effort hackers from compromising accounts - it's still subject to social engineering (like spearphishing). I tend to agree with your broader point - sandboxing will be the way to go, I've…

I don't think pinning deps will help you much, as these incidents often affect transitive dependencies not listed in package.json. package-lock.json is there to protect against automatic upgrades.

I know there are some reports about the lockfile not always working as expected. Some of those reports are outdated info from like 2018 that is simply not true anymore, some of that is due to edge cases like somebody on team having outdated version of npm or installing a package but not committing the changes to lockfile right away. Whatever the reason, pinned version ranges wouldn't protect against that. Using npm ci instead of npm install would.

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

#162

Post by pt » Wed, Sep 17, 2025, 3:16 PM 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…

When we close and reopen VSCode (and some other IDEs), it updates the NPM packages for the installed plugins. Would these mitigations steps (e.g. pnpm) also take care of that?

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

#163

Post by otterley » Wed, Sep 17, 2025, 3:21 PM UTC

madeofpalk wrote: post #75

shakna wrote: post #57

Earlier quoted context omitted.

PyPI is working towards attestation [0], and already has "Trusted Publisher" [1]. Ruby has had signed gems since v2 [2]. These aren't a panacea. But they do mean an effort has been made. npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4] I don't think it's fair to compare npm to the others. [0] https://docs.pypi.org/attestations/producing-attestations/ [1] https://docs…

NPM has both Trusted Publishing and provenance claims for where packages are built. https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/generating-provenance-statements Trusted Publishing is relatively new - GA-ed in July https://github.blog/changelog/2025-07-31-npm-trusted-publish...

Trusted Publishing is a marketing term—a fancy name for OIDC support and temporary auth token issuance. It delegates authenticating the uploader to their identity provider, nothing more.

In a very real sense, it shifts responsibility to someone else. For example, if the uploader was using Google as their identity provider and their Google account was popped, the attacker would be able to impersonate the uploader. So I wouldn’t describe it as establishing a strong trust relationship with the uploader.

It only meaningfully improves the security of the NPM ecosystem if (a) everyone is forced to sign packages and (b) identity providers require more secure authentication methods with as hardware tokens or passkeys.

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

#164

Post by marcosdumay » Wed, Sep 17, 2025, 3:26 PM UTC

sarchertech wrote: post #28

ricardobeat wrote: post #23

Earlier quoted context omitted.

I find this perspective harmful to OSS as a whole. It is completely fine to release free software that other companies can use without restrictions, if you desire to do so. It is not meant to be a transaction. You share some, you take some. It’s also ok to release paid free software, or closed software, restrictive licenses, commercial licenses, and sell support contracts. It’s a choice.

Just because you can do something doesn’t mean you should. There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t ope…

> telling you that this isn’t open source

Are you talking about promoting some software as open source when it's in fact not? Because yes, there's something wrong with that, you shouldn't do it, and people will rightfully react loudly if you try.

People don't complain about proprietary software honestly communicated as that.

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

#165

Post by tanepiper » Wed, Sep 17, 2025, 3:28 PM UTC

inbx0 wrote: post #161

tanepiper wrote: post #155

Earlier quoted context omitted.

Oh I agree - it's far too late to make major changes. When they took over, they had the opportunity to drive a new roadmap towards a more secure solution. 2FA isn't a solution to security, it's a solution to hinder and dissuade low-effort hackers from compromising accounts - it's still subject to social engineering (like spearphishing). I tend to agree with your broader point - sandboxing will be the way to go, I've…

I don't think pinning deps will help you much, as these incidents often affect transitive dependencies not listed in package.json. package-lock.json is there to protect against automatic upgrades. I know there are some reports about the lockfile not always working as expected. Some of those reports are outdated info from like 2018 that is simply not true anymore, some of that is due to edge cases like somebody on tea…

No, it doesn't solve it - but it might minimise the blast radius - there are so many unmaintained libraries of code that indeed one compromised minor patch on any dependency can become a risk.

That's sort of the thing - all of these measures are just patches on the fundamental problem that npm has just become too unsafe

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

#166

Post by cube00 » Wed, Sep 17, 2025, 3:32 PM UTC

aj_g wrote: post #11

Anyone have a good solution to scan all code in our Github org for uses of the affected packages? Many of the methods we've tried have dead ended. Inability to reliably search branches is quite annoying here.

If you have tens of thousands of repos with branches to match you'll be scanning all year.

Proxy NPM with something like Artifactory which stops the bad package getting back in or ending up in any new builds.

Follow it up with endpoint protection to weed the package out of the local checked out copies and .npm on the individual dev boxes.

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

#167

Post by marcosdumay » Wed, Sep 17, 2025, 3:38 PM UTC

austin-cheney wrote: post #146

tcoff91 wrote: post #78

Earlier quoted context omitted.

I think that ultimately it’s the fault of the web platform. With just a bit of retraining those engineers that could not be productive without a ton of npm packages could ship an iPhone app written in Swift. JS’ standard library is abysmal.

This sounds like blaming the victim. How do you on one hand call these people engineers, as if they are engineering something, and then on the other hand blame everything else for their inability to perform? That is weird. Its just a software platform. Would you really blame society for being too harsh if doctors, lawyers, police, teachers cannot do their jobs? It is weird to see so many people blame the web platform…

I dunno. Would you blame doctors if they were unable to perform in a single hospital and had a verifiably good track record anywhere else?

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

#168

Post by advocatemack » Wed, Sep 17, 2025, 3:45 PM 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…

You can also use tools like safe-chain which connects to malware databases and blocks installations of malicious packages. In this case it would have blocked installs around 20 minutes after the malware was added as this was how long it took to be added into the malware databases. https://www.npmjs.com/package/@aikidosec/safe-chain

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

#169

Post by whatevaa » Wed, Sep 17, 2025, 3:51 PM UTC

simonw wrote: post #92

Question for tanepiper: what would you have Microsoft do to improve things here? My read of your article is that you don't like postinstall scripts and npx. I'm not convinced that removing those would have a particularly major impact on supply chain attacks. The nature of npm is that it distributes code that is then executed. Even without npx, an attacker could still release an updated package which, when executed as…

Code signing would help with stolen authentication tokens.

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

#170

Post by czbond » Wed, Sep 17, 2025, 3:52 PM UTC

tanepiper wrote: post #155

simonw wrote: post #92

Question for tanepiper: what would you have Microsoft do to improve things here? My read of your article is that you don't like postinstall scripts and npx. I'm not convinced that removing those would have a particularly major impact on supply chain attacks. The nature of npm is that it distributes code that is then executed. Even without npx, an attacker could still release an updated package which, when executed as…

Oh I agree - it's far too late to make major changes. When they took over, they had the opportunity to drive a new roadmap towards a more secure solution. 2FA isn't a solution to security, it's a solution to hinder and dissuade low-effort hackers from compromising accounts - it's still subject to social engineering (like spearphishing). I tend to agree with your broader point - sandboxing will be the way to go, I've…

I have come to using a multi stage Docker build. One to install dependencies and build whatever it is. I then might have a second clean docker image where the dependencies are copied to and run.

This helps with localized risk, and some production risk - but not all of it.

NPM packages have become a huge nuisance security wise.