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

#121

Post by fleebee » Wed, Sep 17, 2025, 1:06 PM UTC

nemomarx wrote: post #36

sarchertech wrote: post #28

Earlier quoted context omitted.

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…

Sidestep this debate with one trick - use the GPLv3. No company large enough to have a legal team will be able to use it, you're still squarely within the various definitions, and the FSF basically has to approve. As a bonus maybe you can get some proprietary software open sourced too.

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...

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

#122

Post by fergie » Wed, Sep 17, 2025, 1:07 PM UTC

tanepiper wrote: post #63

cube00 wrote: post #2

> The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products. The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.

Author of the article here - holistically this isn't just about NPM dependencies, it's the entire stacks we work with. Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts - this is dangerous - I have 25 years of experience and I wouldn't want to touch the depths of RBAC. SaaS products don't enforce good security - I'…

> a lot of this is left up to developers, without security experts - this is dangerous

Although I see where you are coming from, dismissing unaudited libs as dangerous is slightly missing the point. In fact, the world is a safer place for their existence- the value lost by security exploits is insignificant compared to the value protected by the existence of the libs they exploit. Also, I suspect that you could replace "value" with "lives" in the previous sentence.

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

#123

Post by donatj » Wed, Sep 17, 2025, 1:07 PM UTC

Every day I feel more and more like Go mod's decision to use the lowest common version of a dependency rather than the highest was pure wisdom. Not only does it prevent code breaking at rest from poor semantic versioning, it's also served to prevent automatic inclusion of supply chain attacks.

npm as designed really aggressively likes to upgrade things, and the culture is basically to always blindly upgrade all dependencies as high as possible.

It's sold as being safer by patching vulnerabilities, but most "vulnerabilities" are very minor or niche, whereas a lot of risk is inherent in a shifting foundation.

Like it or not it's kind of a cultural problem. Recursively including thousands of dependencies, all largely updating with no review is a problem.

The thing I find particularly frightful and distinctive from the other package managers I regularly use is there is zero guarantee that the code a library presents on GitHub has anything to do with it's actual content in NPM. You can easily believe you've reviewed an items code by looking at it on GitHub, but that can have absolutely zero relation to what was actually uploaded to npm. You have to actually review what's been uploaded to npm as its entirety disconnected.

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

#124

Post by tedggh » Wed, Sep 17, 2025, 1:10 PM UTC

giantg2 wrote: post #19

cube00 wrote: post #2

> The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products. The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.

I remember joining my company right out of college. In the interview we started talking about open source since I had some open source Android apps. I asked if the company contributed back to the projects it used. The answer was no, but that they were planning to. Over a decade later... they finally created a policy to allow commits to open source projects. It's been used maybe 3 times in it's first year or so. Nobod…

Most developers don’t work for software companies. So when you are not shipping software as a product you and your department are usually a liability. This is important to understand because it helps you frame your approach to upper management as a developer or c-suite as a director of engineering when it comes to talk about budgets. In my experience, most non tech corporations will be ok with allocating budget for open source projects, they already do it in other types of non profit domains. But you need to make a case that goes beyond the ethical reasons or personal motivations.

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

#125

Post by garblegarble » Wed, Sep 17, 2025, 1:14 PM UTC

simonw wrote: post #115

garblegarble wrote: post #83

Earlier quoted context omitted.

Bubblewrap seems excellent for Linux uses - on macOS, it seems like sandbox-exec could do some (all?) of what bubblewrap does on Linux. There's no official documentation for SBPL, but there are examples, and I found sandboxtron[0] which was a helpful base for writing a policy to try to contain npm 0: https://github.com/lynaghk/sandboxtron/tree/main

sandbox-exec is so frustrating . It could be a genuinely excellent solution to a whole bunch of sandboxing problems, except... 1. Documentation is virtually nonexistent. I think that is inexcusable for a security tool! 2. The man page says that it's deprecated, and has done for around a decade. No news on when they will actually remove it, maybe they never will? Hard to recommend it with that axe hanging over it thou…

Absolutely agreed on the lack of documentation, it seems completely insane (I assume this is because they want to reinforce that only Apple should be writing policies - but still no excuse for it)

>Hard to recommend it with that axe hanging over it though.

Given the alternative being no way to limit untrusted tooling at all today, it seems worthwhile using it despite these problems?

There's also a (very slim) chance that if it became central to the security of developers on macOS that Apple would give slightly more consideration to it

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

#126

Post by user34283 » Wed, Sep 17, 2025, 1:17 PM UTC

hu3 wrote: post #113

My non-solution years ago was to use as little dependencies as possible. And vendor node_modules then review every line of code changed when I update dependencies. Not every project and team can do that. But when feasible, it's a strong mitigation layer. What worked was splitting dependency diff review among the team so it's less of a burden. We pin exact versions and update judiciously.

You can't realistically do that when for example you use Jest as your test runner, which alone would add 300 packages.

ESLint would be another culprit, adding 80 packages.

It quickly gets out of hand.

To me it seems like the fewest projects could use this approach you described.

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

#127

Post by amiga386 » Wed, Sep 17, 2025, 1:19 PM UTC

h1fra wrote: post #82

amiga386 wrote: post #7

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm

As far as I remember:

"go get" doesn't execute downloaded code automatically; there's no "postinstall" script (there can be a manual "go generate" or "go tool" the user may run)

Go doesn't upgrade existing dependencies automatically, even when adding a new dependency: you need an explicit "go get -u"

You don't use the same tool to both fetch and publish ("go get" vs "git push") so it's less likely a module publisher would get pwned while working on something unrelated.

The Go community tends not to "micropublish" so fewer people have or need commit rights to published go modules.

Go has a decent standard library so there are fewer "missing core functionality" third-party packages that world + dog depends on.

Npm is easier to pwn than Go, Maven, RubyGems, PyPI, CPAN, etc. because the design has more footguns and its community likes it that way

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

#128

Post by simonw » Wed, Sep 17, 2025, 1:20 PM UTC

garblegarble wrote: post #125

simonw wrote: post #115

Earlier quoted context omitted.

sandbox-exec is so frustrating . It could be a genuinely excellent solution to a whole bunch of sandboxing problems, except... 1. Documentation is virtually nonexistent. I think that is inexcusable for a security tool! 2. The man page says that it's deprecated, and has done for around a decade. No news on when they will actually remove it, maybe they never will? Hard to recommend it with that axe hanging over it thou…

Absolutely agreed on the lack of documentation, it seems completely insane (I assume this is because they want to reinforce that only Apple should be writing policies - but still no excuse for it) >Hard to recommend it with that axe hanging over it though. Given the alternative being no way to limit untrusted tooling at all today, it seems worthwhile using it despite these problems? There's also a (very slim) chance…

Yes definitely worth using it, but I don't know how much time I want to spend integrating it deeply into my own open source projects given its uncertain status.

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

#129

Post by zachrip » Wed, Sep 17, 2025, 1:20 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…

What about if pw or 2fa change, your tokens go on a 24hr cooldown? I think the debug package maintainer even provided his 2fa to the phishing site. Obviously doesn't fix the case where they just exfiltrate and use tokens, but there's no fix that solves all of this, there needs to be layers. I also think npm should be scanning package updates for malicious code and pumping the brakes on potentially harmful updates for large packages.

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

#130

Post by pavel_lishin » Wed, Sep 17, 2025, 1:21 PM UTC

austin-cheney wrote: post #54

pavel_lishin wrote: post #29

Earlier quoted context omitted.

> Consider how many JavaScript developers are completely unemployable without that free software. Can you say more about this?

[flagged]

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?