Hacker News Reader

Comment by anon7000 | Hacker News Reader

The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated.

This happened even if you had pinned dependencies and were on top of security updates.

We need some deeper changes in the ecosystem.

https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7...

View on HN

> We need some deeper changes in the ecosystem.

I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason.

As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage.

NPM will often have different source then the github repo source. How does anyone even trust the system?

Fucking this.

I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix.

No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't.

“It’s not difficult to fix, just change the entire culture”

The difficulty comes in trying to change the entire culture.

“Doctor, it hurts when I do this!”

“Stop doing that!”

“But I wanna!”

That is valid though, if someone says "It hurts when I walk" its not reasonable to tell them to not walk, you try to figure out why it hurts and if it can be fixed.

Other languages has similar package managers as npm, but with much less issues, so it can be fixed without changing the package manager completely.

Wanna is distinct from gotta, after all.

> It's an ecosystem and cultural problem that npm encourages huge dependency trees

It is an ecosystem and culture that learned nothing from the debacle of left pad. And it is an affliction that many organizations face and it is only going to get worse with the advent of AI assisted coding (and it does not have to be).

There simply arent enough adults in the room with the ability to tell the children (or VC's and business people) NO. And getting an "AI" to say no is next to impossible unless you're probing it on a "social issue".

I would say Javascript's lack of a standard library is at least in part responsible for encouraging npm use, things just spiraled out of control from there.

[not a dev] why isn't there the equivalent of "Linux distributions" for npm? I know I know: because developers all need a different set of libs. But if there were thousands of packages required to provide basic "stdlib-like functionality" couldn't there be an npm distribution that you can safely use as a starting point, avoiding importing asinine stuff like 'istrue' (yea I'm kinda joking there). Or is that just what bloated Frameworks all start out as?

So basically, Boost for JavaScript?

There could, this would essentially be in the form of a standard library. That would work until someone decides they don't like the form/naming conventions/architecture/ideology/lack of ideology/whatever else and then reinvent everything to do the same, but in a slightly different way.

And before you know it, you have a multitude of distributions to choose from, each with their own issues...

Who is shipping/maintainig this ? Even node itself is maintained by OSS. That's one of the advantages of Microsoft .NET ecosystem - you can do a lot of stuff without pulling anything not shipped by Microsoft. I don't know of any other ecosystem that's as versatile with so much first party support.

Source available beats open source from a security perspective.

The thing is, having access to such dependencies is also a huge productivity boost. It's not by accident that every single language whose name isn't C or C++ has pretty much moved to this model (or had it way before npm, in the case of Perl or Haskell).

The alternative is C++, where every project essentially starts by reinventing the wheel, which comes with its own set of vulnerabilities.

I'm saying this without a clear idea of how to fix this very real problem.

It's more like capex vs opex. Some languages and frameworks - you have to maintain the same level of effort, just to keep your apps working.

> The alternative is C++, where every project essentially starts by reinventing the wheel

Sure, in 1995.

Most C++ projects nowadays belong to some fairly well understood domain and for every broad domain there is usually one or two large 'ecosystem' libraries that come batteries included. Huge monolithic dependency with well stablished governance instead of 1000 small ones.

Examples of such ecosystems are Qt, LLVM, ROOT, tensorflow, etc. For smaller projects that want something slightly more than a standard library but not belonging to a clear ecosystem like the above you have boost, folly, abseil, etc.

Most of these started by someone deciding to reinvent the wheel decades ago, but there's no real reason to do that in 2025.

It's already solved by pnpm, which refuses to execute any postinstall scripts except those you whitelist manually. In most projects I don't enable any and everything works fine, in the worst case I had to enable two scripts (out of two dozen or so) that download prebuilt native components, although even those aren't really necessary and it could have been solved through other means (proven by typescript-go, swc, and other projects led by competent maintainers).

None of it will help you when you're executing the binaries you built, regardless of which language they were written in.

I could be wrong but I believe Pnpm would not have helped with the supply chain attach that brings us here. It's simply a problem with deploying new code rapidly and automatically without verification to a billion machines at a time.

That’s my read. Even if there was some other logistical barrier, updating a bunch of external dependencies as most people do it unavoidably involves pre-trusting code you’ve never seen. I don’t think there’s any way around that, and given that, I don’t think there’s a purely technical solution. This requires having more vetting within package manager, but that’s not an easy lift.

> None of it will help you when you're executing the binaries you built

Lavamoat would, if you get to the point of running your program with lavamoat-node or built with the lavamoat webpack plugin: https://lavamoat.github.io/guides/getting-started/

> None of it will help you when you're executing the binaries you built, regardless of which language they were written in.

Sure it would... isn't that the whole point of Deno? The binary can't exfiltrate anything if you don't let it connect to the net.

That doesn't help you if anyone on your team installs a vscode plugin which uses npm in the background & executes postinstall scripts.

I am now using the type remover in Node to run TupeScript natively. It’s great and so fast. Even still I continue to include the TypeScript compiler in my projects so that I can run TSC with the no compile option just for the type auditing.

You are lying to yourself. In this attack, nothing was executed by npm; it "just" replaced some global functions. A Go package can't do that, but you can definitely execute malware at runtime anyway. It can also expose new imports that will be imported by mistake when using an IDE.

Before we all conclude that supply chain attacks only happen on NPM, last time I used VS Code I discovered that it auto-installed, with no apparent opt-out, Python typing stubs for any package (e.g., Django in my case) from whatever third-party, unofficial PyPI accounts it saw fit. (Yes, this is why it was the last time I used VS Code.)

The obscurity of languages other than JavaScript will only work as a security measure for so long.

I've never seen Pylance automatically install anything. Are you talking about the stubs that come packaged with Pylance, which Microsoft maintains?

It was the Microsoft’s official Python extension, as far as I recall. It was possible to use some other extension for typechecking but there were some other issues with it. (Now everything works perfectly in Neovim, and my setup respects to only use typing stubs I specify in the project.)

The Microsoft official Python extension uses Pylance, which is a closed-source extension of Pyright with additional features such as built-in type stubs. This is probably what you saw.

If they were truly built-in I would not mind, but I found a bunch of third-party stubs in a dependency tree of the virtual Python environment VSC created (and ran obviously unsandboxed). What’s worse is that stubs, in addition to not being specified by me, were often pulled at the wrong version compared to the package I was using, leading to typing mismatches and runtime errors.

Honestly, the same is true in a lot of other areas of computing.

Whenever you download an open-source program and you don't have to compile it first, you're at risk of running code that is not necessarily what's in the publicly-available source code.

This can even apply to source code itself when distributed through two different channels, as we saw in the xz backdoor attempt. (The release tarball contained different code to the repository.)

Yeah, Editor extensions are both auto-updated and installed in high risk dev environments. Quite a juicy target and I am surprised we haven’t seen large scale purchases by bad actors similar to browser extensions yet. However, I remember reading that the VsCode team puts a lot of effort in catching malware. But do all editors (with auto-updates) such as Sublime have such checks?

The key thing needed is a standard library which includes 100000 of these tiny one function libraries (has-ansi, color-name).

I checked has-ansi. What's the reason that this library would exist and be popular? Most of the work is done by the library it imports, ansi-regex and then it just return ansi-regex.test(string), yet it has 5% of the weekly downloads of ansi-regex. ansi-regex also has fewer than 10 lines of code.

I don't know anything about the npm ecosystem, what's the benefit of importing these libraries compared to including these code in the project?

The benefit is getting your secrets stolen and pointing the blame at someone else? Yeah...

The VS Code ecosystem has too much complexity for my tastes. I do keep a copy around with a few code formatting plugins installed but I feel more comfortable with Emacs (or Vim for my friends who are on that side of the fence).

I am a consumer of apps using npm, not a developer, and I simply don’t like the auto updates and seeing a zillion things updated. I use uv and Python a lot, and I get a similar uneasy feeling there also, but (perhaps incorrectly) I feel more in control.

I usually make sure all the packages and db are local, so my dev machine can run in Airplane mode. And only turn on internet when use git push

All docs are local too, like we used to do with man pages and paper reference books or do you use another system for them? A second computer, a tablet, a phone?

wow. i uninstalled the nx plugin a few weeks ago after completing the migration to pnpm.

Reply on news.ycombinator.com