Aikido says: > We were alerted to a large-scale attack against npm...

Socket says: > Socket.dev found compromised various CrowdStrike npm packages...

Ox says: > Attackers slipped malicious code into new releases...

Safety says: > The Safety research team has identified an attack on the NPM ecosystem...

Phoenix says: > Another supply chain and NPM maintainer compromised...

Semgrep says: > We are aware of a number of compromised npm packages

NPM debug and chalk packages compromised (1366 points, 754 comments): https://news.ycombinator.com/item?id=45169657

Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-parties.

For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chore". While I agree it's nice to have consistent style, in some projects it seems to be the majority of the changes between releases. Due to the difficulty in auditing this, I consider this part of the software supply chain problem and something to be discouraged. Unless there's actually reason to change code (eg. some genuine refactoring a human thinks is actually needed, a bug fix or new feature, a tool exposed a real bug, or at least some identifiable issue that might turn into a bug), it should be left alone.

Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates.

Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push directly to NPM, which would mean that any malware injector would need to first compromise the source code repository. Which, to be fair, wouldn't necessarily have stopped this worm from propagating entirely, but would have slowed its progress considerably.

This isn't a "sacrifice all of NPM's DX and decentralization" question. This is "a marginally more manual DX only when you're at a scale where you should be release-managing anyways."

Can you point me to Go's centralized package repository?

Just wondering: while this is less of an attack surface, it's still a surface?

Unfortunately most people don't want old software that doesn't support newer hardware so most people don't end up using Debian stable.

If you ask these people, distributions are terrible and need to die.

Python even removed PGP signatures from Pypi because now attestation happens by microsoft signing your build on the github CI and uploading it directly to pypi with a never expiring token. And that's secure, as opposed to the developer uploading locally from their machine.

In theory it's secure because you see what's going in there on git, but in practice github actions are completely insecure so malware has been uploaded this way already.

At the end of the day, it’s all a URL.

You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.

Benefit from this feature.

However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so.

What's especially concerning is I see this take in the security industry: mitigations put in place to target e.g. NPM, but are then completely absent for PyPi or Crates. It's bizarre not only because it leaves those ecosystems wide open, but also because the mitigation measures would be very similar (so it would be a minimal amount of additional effort for a large benefit).

Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code.

What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This has to be baked into packages and package management.

At some point people need to realize and go back to writing vanilla js, which will be very hard.

The rust ecosystem is also the same. Too much dependence on packages.

An example of doing it right is golang.

Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.

There is a difference, but it's not an order of magnitude and neither is a true island.

Granted, deciding not to use JS on the server is reasonable in the context of this article, but for the client htmx is as much a js lib with (dev) dependencies as any other.

https://github.com/bigskysoftware/htmx/blob/master/package.j...

https://github.com/vuejs/core/blob/main/package.json

While npm is a huge and easy target, the general problem exists for all package repositories. Hopefully a supply chain attack mitigation strategy can be better than hoping attackers target package repositories you aren't using.

While there's a culture prevalent in Javascript development to ignore the costs of piling abstractions on top of abstractions, you don't have to buy into it. Probably the easiest thing to do is count transitive dependencies.

This works for deps of deps as well, so anything in your node_modules has access to this hook.

It's a terrible idea and something that ought to be removed or replaced by something much safer.

You all really need to stop using this term when it comes to OSS. Supply chain implies a relationship, none of these companies or developers have a relationship with the creators other than including their packages.

Call it something like "free code attacks" or "hobbyist code attacks."

I can't think of an instance where I ran npm install and didn't run some process shortly after that imported the packages.

These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends.

Additionally I really like to go mod vendor my snapshot of dependencies which is great for short term fixes, but it won't fix the cause in the long run.

However, the go ecosystem is just as vulnerable here because of lack of signing off package updates. As long as there's no verification possible end-to-end when it comes to "who signed this package" then there's no way this will get better.

Additionally most supply chaib attacks focussed on the CI/CD infrastructure in the past, because they are just as broken with just as many problems. There needs to be a better CI/CD workflow where signing keys don't have to be available on the runners themselves, otherwise this will just shift the attack surface to a different location.

In my opinion the package managers are somewhat to blame here, too. They should encourage and mandate gpg signatures, and especially in git commits when they rely on git tags for distribution.

There are plenty of people in the community who would help reduce the number of dependencies, but it really requires the maintainers to make it a priority. Otherwise the only way to address it is to switch to another solution like oxlint.

As in any random major project with focus on not having dependencies? SQLite comes to mind.

What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands?

I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.

Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actually go publish for a while until after publishing, allowing security scanners to do their thing.

You realize my point right? People are taught to not reinvent the wheel at work (mostly for good reasons) so that's what they do, me and you included.

You ain't gonna be bothered to write html and manual manipulation, the people that will give you libraries to do so won't be bothered reimplementing parsers and file watchers, file watcher writers won't be bothered reimplementing file system utils, file system utils developers won't be bothered reimplementing structured cloning or event loops, etc, etc.

I myself just the other day had the task of converting HTML to markdown, because I don't remember whether it was Jira or Github APIs that returns comments as HTML and despite it being mostly few hours of work that would get us 90% there everybody was in favor of pulling a dependency to do so (with its own dependencies) and thus further exposing our application to those risks.

Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.

Adding dependencies comes with advantages and downsides. You need to strike a balance between them. External libraries can help implement things that you better don't implement yourself, so the answer is certainly not "no dependencies". But there are downsides and risks, and the risks grow with the number of dependencies.

In the world of NPM, people think those simple truths don't apply to them and the downsides and risks of dependencies can be ignored. Then you end up with thousands of transitive dependencies.

They're wrong and learn it the hard way now.

I would argue that is only one of the many issues with the JS/TS/NPM ecosystem. Many of the other problems have been normalized. The constant security issues are highly visible.

It's just javascript being javascript.

NPM packages are used by huge Electron apps like Discord, Slack, VS Code, the holy grail would be to somehow slip something inside them.

Its users don't check who the email is from

Community is very happy to pick up helper libraries and by the time you get all the way up the tree in a react framework you have hundreds or even thousands of packages.

If you’re sensible you can be fine just like any other ecosystem, but limited because one wrong package and you’ve just ballooned your dependency tree by hundreds which lowers the value of the ecosystem.

Node doesn’t have a standard library and until recently not even a test runner which certainly doesn’t help.

If your sensible with node or Deno* you’ll somewhat insulated from all this nonsense.

*Deno has linting,formatting,testing & a standard library which is a massive help (and a permission system so packages can’t do whatever they want)

Its less a technical but rather a moral hurdle. Its probably a bunch of teenagers behind it like how it was with the Mirai Botnet.

Use pnpm and whitelist just what you need. It disables all scripts by default.

The malware could have been a JS code injected into the module entry point itself. As soon as you execute something that imports the package (which, you did install for a reason) the code can run.

I don't think that many people sandbox their development environments.

Something like, only packages with attestations/signed releases and OIDC-only workflow should allow these scripts.

Worm could propogate through the code itself but I think it would be quite a bit less effective.

Modern node package managers such as yarn and pnpm allow you to prevent post installs entirely.

Today most of the time you need to make an exception for a package is when a module requires native compilation or download of a pre-built binary. This has become rare though.

https://github.com/freakynit/simple-npm-sandbox

Disclaimer: I am not Docker expert. Please review the script (sandbox.js) and raise any potential issues or suggestions.

Thanks..

Do not let code to have access to things it's not supposed to access.

It's actually that simple. If you implemented a function which formats a string, it should not have access to `readFile`, for example.

Retrofitting it into JS isn't possible, though, as language is way too dynamic - self-modifying code, reflection, etc, means there's no isolation between modules.

In a language which is less dynamic it might be as easy as making a white-list for imports.

This is something I'm trying to polish for my system now, but the idea is: yarn (and bundler and others) needs to talk only to the repositories. That means yarn install is only allowed outbound connections to localhost running a proxy for packages. It can only write in tmp, its caches, and the current project's node_packages. It cannot read home files beyond specified ones (like .yarnrc). The alias to yarn strips the cloud credentials. All tokens used for installation are read-only. Then you have to do the same for the projects themselves.

On Linux, selinux can do this. On Mac, you have to fight a long battle with sandbox-exec, but it's kinda maybe working. (If it gained "allow exec with specified profile", it would be so much better)

But you may have guessed from the description so far - it's all very environment dependent, time sink-y, and often annoying. It will explode on issues though - try to touch ~/.aws/credentials for example and yarn will get killed and reported - which is exactly what we want.

But internally? The whole environment would have to be redone from scratch. Right now package installation will run any code it wants. It will compile extensions with gyp which is another way of custom code running. The whole system relies on arbitrary code execution and hopes it's secure. (It will never be) Capabilities are a fun idea, but would have to be seriously improved and scoped to work here.

When declaring dependencies, you'd also declare the permissions of those dependencies. So a package like `tinycolor` would never need network or disk access.

Clojars (run by volunteers AFAIK) been doing signatures since forever, not sure why it's so difficult for Microsoft to follow their own yearly proclamation of "security is our top concern".

Stuff like intents "this is a math library, it is not allowed to access the network or filesystem".

At a higher level, you have app sandboxing, like on phones or Apple/Windows store. Sandboxed desktop apps are quite hated by developers - my app should be allowed to do whatever the fuck it wants.

For one, NPM has a really sprawling ecosystem where it's normal to have many dependencies.

I remember that I once tried to get started with angular, and I did an "init" for an empty project and "compile", and suddenly had half a gigabyte of code lying in my directory.

This means that there is a high number of dependencies that are potential targets for a supply chain attack.

I just took a look at our biggest JS/Typescript project at work, it comes in at > 1k (recursive) NPM dependencies. Our biggest Python project has 78 recursive dependencies. They are of comparable size in terms of lines of code and total development time.

Why? Differences in culture, as well as python coming with more "batteries included", so there's less need for small dependencies.

Common Lisp is not worth it - you are unlikely to hit any high-value production target, there are not many uses and they are tech-savy. Good for us, the 5 remaining users. Also, Quicklisp is not rolling-release, it is a snapshot done one or two times a year.

Nothing much came of it, I don't know.

This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?