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

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

tane.dev

Post reply on HN
Print view View original

151–160 of 235 posts

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

#151

Post by jollyllama »

beart wrote: post #150
jollyllama wrote: post #135

The NPM monoculture is the problem. It would be absurd to suggest that all backend engineers use the same build tooling and dependency library, but here we are with frontend. It's just too big of an attack surface.

It would be absurd to make such a suggestion. However, the comparison is not correct. Not all front-end development uses the same build tooling or dependency libraries, or programming language for that matter. Even if you narrow to the typescript ecosystem, it's still not true.

And yet, 99% of front end development uses NPM.

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

#152

Post by giantg2 »

MrGilbert wrote: post #48
giantg2 wrote: post #19

Earlier quoted context omitted.

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…

> Nobody has the time I'd erase that part entirely, as it is not true, from my point of view. My day, as has every other person's day, has exactly 24 hours. As an employee, part of that time is dedicated to my employer. In return, I receive financial compensation. It's up to them to decide how they want to spend the resources they acquired. So yes, each and every company could, in theory, contribute back to Open Sour…

If your finite time at work is filled with business work, then there is no time left to do the open-source work. Seems true to me from an IC and delivery perspective. Company staffing and resource allocation could create the time to do it, but they don't.

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

#153

Post by dns_snek »

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…

For a start, maintainers of dependencies with more than 1000 weekly downloads should be forced to use phishing-resistant 2FA like WebAuthN to authenticate updates (ideally hardware security keys, but not strictly necessary), or sign the code using a registered PGP key (with significant cooldown and warnings when enrolling new keys, e.g. 72h).

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

#154

Post by Ajedi32 »

watwut wrote: post #77
MrGilbert wrote: post #48

Earlier quoted context omitted.

> Nobody has the time I'd erase that part entirely, as it is not true, from my point of view. My day, as has every other person's day, has exactly 24 hours. As an employee, part of that time is dedicated to my employer. In return, I receive financial compensation. It's up to them to decide how they want to spend the resources they acquired. So yes, each and every company could, in theory, contribute back to Open Sour…

> In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible. It is not just that. In a well functioning theoretical free market, no one is going to have time either. The margins are supposed to end up being tight and the competition is supposed to weed out economic inefficiency. Voluntary pro-social behavior is a…

Working an honest job is pro-social behavior, and it is rewarded. So is quitting your job to work on a side project that ends up being valuable enough for others to pay for. It's just that giving code away for free operates outside that reward structure.

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

#155

Post by tanepiper »

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 been having that very discussion today. we're also now enforcing CI pipelines with pinned dependencies (which we do with our helm charts, but npm by default will install with ^ semver and putting that on the developer to disable isn't good enough - the problem of course is that requires the OS vendors to agree on what is common.

This is a riff - not sure how possible this is, but it's not coming from nowhere, it's based on work I did 8 years back (https://github.com/takeoff-env/takeoff) - using a headless OS container image with a volume pointing to the source folder, run the install within the container (so far so good, this is any multi-stage docker build)

The key part would be to then copy the node_modules in the volume _data folder back to the host - this would of likely require the OS vendors to provide timely images with each release of their OS to handle binary dependencies, so is likely a non-starter for OSX.

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

#156

Post by smithkl42 »

amiga386 wrote: post #7

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

Among other things, the attack space for npm is just so much larger. We run a large C# codebase (1M+ LOC) and a somewhat smaller TypeScript codebase (~200K LOC). I did a check the other day, and we have one potentially vulnerable nuget dependency for every 10,000 lines of C# code, but one potentially vulnerable npm dependency for about every 115 lines of TS code.

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

#157

Post by Ajedi32 »

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…

I made a list a few years back: https://news.ycombinator.com/item?id=29266992

At the time, I was focusing more on the approach of reducing the number of people you have to trust when you depend on a particular package.

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

#158

Post by h1fra »

amiga386 wrote: post #127
h1fra wrote: post #82

Earlier quoted context omitted.

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…

postinstall is a liability for sure, but as soon as you execute untrusted code, it's the same no matter the language. Last week, npm pawn was working like this without a postinstall, which could be the same with Go. Nothing prevents me from pushing a code that would read all your files as soon as you load the library in your code.

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

#159

Post by user34283 »

hu3 wrote: post #148
user34283 wrote: post #126

Earlier quoted context omitted.

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.

You usually can. You just gotta be a bit adventurous. https://github.com/lukeed/uvu is a testing library with almost no dependency. https://github.com/biomejs/biome is a linter written in Rust which in theory has a smaller attack surface. And as long as you stay some versions behind bleeding edge, you can use time in your favor to catch supply chain attacks before they reach your codebase.

Well, can you?

Maybe you can.

Or you're talking about an approach you utilized in some side projects rather than moderately sized commercial web applications? I don't imagine there's many out there that have less than hundreds of dependencies.

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

#160

Post by beart »

jollyllama wrote: post #151
beart wrote: post #150

Earlier quoted context omitted.

It would be absurd to make such a suggestion. However, the comparison is not correct. Not all front-end development uses the same build tooling or dependency libraries, or programming language for that matter. Even if you narrow to the typescript ecosystem, it's still not true.

And yet, 99% of front end development uses NPM.

According to https://tsh.io/state-of-frontend#package-manager, it's not quite that high.
Post reply on HN