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

111–120 of 235 posts

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

#111

Post by simonw »

apimade wrote: post #40

Here’s a one-liner for node devs on MacOS, pin your versions and manually update your supply chain until your tooling supports supply chain vetting, or at least some level of protection against instantly-updated malicious upstream packages. Would love to see some default-secure package management / repo options. Even a 24 hour delayed mirror would be better than than what we have today. find . -name package.json -not…

You can indent every line of a code block on Hacker News by two spaces to have it render as code.

  This is indented
  By two spaces

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

#113

Post by hu3 »

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.

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

#115

Post by simonw »

garblegarble wrote: post #83
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…

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

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

#116

Post by felixgallo »

acdha wrote: post #72
stingraycharles wrote: post #55

Earlier quoted context omitted.

Isn’t all this stuff with Secure Enclave supposed to address these kind of things? It’s my take that over the past ~ decade a lot of these companies have been making things a lot better, Windows even requires secure boot these days as well.

They’re not the same problems. The Secure Enclave protects things like your biometrics, hardware-backed keys (e.g. on a Mac, WebAuthn and iCloud Keychain), and the integrity of the operating system but not every bit of code running as your account. That means that an NPM install can’t compromise your OS to the point that you can’t recover control, but it means the attacker can get everything you haven’t protected usi…

it's not clear that the solution to this problem is to create several additional layers of barn doors.

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

#117

Post by _heimdall »

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'…

That's interesting. I take issue with companies that claim a level of security that doesn't match what they ship, but I never expect them to tell me how to do my job well.

I expect a company to put their current product in as good of a light as they can. They're going to over promise what it can do and show me the easiest "Getting Started" steps as they can. Its up to me to dig deeper and understand what they actually do and what the right solution is for my project.

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

#119

Post by bee_rider »

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.

That’s the solution. The whole theory of the many-eyes model is that lots of people will read the code.

You are doing the work. These automatic library installing services seem to have a massive free-rider problem.

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

#120

Post by rs186 »

izacus wrote: post #90
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

What about Java's Maven, much more popular and longer living?

When your only dependencies are Spring and Apache Commons, which requires legal approval in your corporation to use, and each update requires scrutiny, it's hard to get any supply chain attacks, right?
Post reply on HN