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

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.

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.

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)

It's just javascript being javascript.

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?

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.

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

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.

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.

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.

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

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

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.

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

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.

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.

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

Have fun, seems like a misguided reason to do that though.

A. A package hosted somewhere using a language was compromised!

B. I am not going to program in the language anymore!

I don't see how B follows A.

HTMX is JavaScript.

Unless you meant your own JavaScript.

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.

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.

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.

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.

And it runs a post-install: node install.js

So I do really have to trust it or read all the code.

Those are the workspace dependencies, not the dependencies of the specific crates you may use within the project. You have to actually look closer to find that out, most of `swc-` crates have shallow dependency trees.

Benefit from this feature.

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

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.

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

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

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

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.

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.

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

1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package.

So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though that's not their primary purpose but many people use the like that) and the security implications of pulling in lots of random dependencies without any audit.

Developing towards a stable base like Debian would not be a pancea, but alliviate the problems by at least placing another audit layer in between.

The reason these compromised packages typically don't make it in to e.g. Debian is because this all tends to be discovered quite quickly, before the package maintainer has a chance to update it.

I don't know how you avoid this problem

Linux distros can't even provide all the apps users want, that's why freshmeat existed and we have linuxbrew, flatpak, Ubuntu multiverse, PPA, third party Debian repositories, the openSUSE Buildservice, the AUR, ...

There is no community that has the capacity to audit and support multiple branches of libraries.

https://lintian.debian.org/

Linux distros could still stand to improve here in a bunch of ways, and it seems that a well-designed package ecosystem truly doesn't need such hooks at the level of the package manager at all. But this kind of auditing is one of the useful functions of downstream software distros for sure.

The problem with this approach is that frameworks tend to "expire" pretty quickly and you can't run anything for too long on Debian until the framework is obsolete. What I mean by obsolete is Debian 13 ships with Golang 1.24, A year from now it's gonna be Golang 1.26 - that is not being made available in trixie. So you have to find an alternative source for the latest golang deb. Same with PHP, Python etc. If you run them for 3 years with no updated just some security fixes here and there, you're gonna wake up in a world of hurt when the next stable release comes out and you have to do en-masse updates that will most likely require huge refactoring because syntax, library changes and so on.

And Javascript is a problem all by itself where versions come up every few months and packages are updated weekly or monthly. You can't run any "modern" app with old packages unless you accept all the bugs or you put in the work and fix them.

I am super interested in a solution for this that provides some security for packages pushed to NPM (the most problematic repository). And for distributions to have a healthy updated ecosystem of packages so you don't get stuck who knows for how long on an old version of some package.

And back to Debian, trixie ships with nginx 1.26.3-3+deb13u1. Why can't they continuously ship the latest stable version if they don't want to use the mainline one?

Finding the balance of that seems to me like it'd be incredibly difficult.

Joking aside, I don't think there ever really was a lack of initiatives by entities (communities, companies, whatever) to create some sort of standard library (we typically tend to call them frameworks). There's just simply too much diversity, cultures and subcultures within the whole JavaScript sphere to ever get a global consensus on what that "standard" library then should look like. Not to mention the commercial entities with very real stakes in things they might not want to relinquish to some global unity consensus (as it may practically hurt their current bottom line).

Debian is a common community effort to create a “distro” of curated and safe dependencies one can install safely.

If you want stable, tested versions of software, only getting new versions every few years:

https://packages.debian.org/stable/javascript/

If you want the newer versions of software, less tested, getting new versions continuously:

https://packages.debian.org/unstable/javascript/

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

I've never tried any of them but there's also a few wrappers specifically to do that, such as: https://github.com/berstend/node-safe

Otherwise you're down to docker or virtualisation or creating one system user per project...

No direct relation to the specific attack on debug/chalk/error-ex/etc that happened 7 days ago.

The article states that this is the same attackers that got control of the "nx" packages on August 27th, which didn't really get a lot of traction on HN when it happened: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...

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

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.

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.

And then vendors from Socket, Aikido, and Step all seem to have detected it via their upstream malware detection feeds - Socket and Aikido do AI code analysis, and Step does eBPF monitoring of build pipelines. I think this was widespread enough it was noticed by several people.

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

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.

Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed.

Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc...

Like, there is the post install script issue or course, but I feel like these attacks could have been just as (or almost as) effective in other programming languages, but I feel like we always only hear about npm packages.

https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0...

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.

PyPI's attestations do nothing to prevent this either. A package built from a compromised repository will be happily attested with malicious code. To my knowledge wheels are not required.

But it still doesn't stop infected developer machines to silently update code and wait for the next release patiently.

It would require the diligence of those developers to check every line of code that goes out with a release... which is a lot to ask for someone who fell for a fishing email.

I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators.

"Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually pretty sensible.

It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature that you need to use.

The only time this philosophy has bitten me was in an older project where I had to convince a PM who built some node project on their machine that the vulnerability warnings were not actually issues that affected our project.

Edit: because I don't want to reply to three things with the same comment - what are you using for dependencies where a) you require frequent updates and b) those updates are really hard?

Like for example, I've avoided updating node dependencies that have "vulnerabilities" because I know the vuln doesn't affect me. Rarely do I need to update to support new features because the dependency I pick has the features I need when I choose to use it (and if it only supports partial usage, you write it yourself!). If I see that a dependency frequently has bugs or breakages across updates then I stop using it, or freeze my usage of it.

https://docs.renovatebot.com/configuration-options/#minimumr...

https://docs.renovatebot.com/presets-default/#enablevulnerab...

It's common among grizzled software engineering veterans to say "Check in the source code to all of your dependencies, and treat it as if it were your own source code." When you do that, version upgrades are actual projects. There's a full audit trail of who did what. Every build is reproducible. You have full visibility into all code that goes into your binary, and you can run any security or code maintenance tools on all of it. You control when upgrades happen, so you don't have a critical dependency break your upcoming project.

For Python's uv, you can do something like:

> uv lock --exclude-newer $(date --iso -d "2 days ago")

Perhaps I’m just ignorant of web development, but why not? We do so with our desktop software.

The problem with this approach is you need a certain number of guinea pigs on the bleeding edge or the outcome is the same (just delayed). There is no way for anyone involved to ensure that balance is maintained. Reducing your surface area is a much more effective strategy.

The signal desktop app is an electron app. Presumably it has the same problem.

Does anyone know of any reasonable approaches to using npm securely?

“Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”.

Use NPM Package Cooldown Check

The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.

https://pnpm.io/blog/releases/10.16

https://github.com/crev-dev/

You can do it:

https://github.blog/changelog/2025-07-01-dependabot-supports...

https://docs.renovatebot.com/configuration-options/#minimumr...

https://www.stepsecurity.io/blog/introducing-the-npm-package...

And larger dependencies that can be trusted in larger blocks. I'll bet half of a given projects dependencies are there to "gain experience with" or be able to name drop that you've used them.

Less is More.

We used to believe that. And then W3C happened.

You can do this with npm (since version 6.9.0).

To only get registry deps that are over a week old:

    $ npm install --before="$(date -v -7d)"

That's the secret lots of enterprises have relied on for ages. Don't be bleeding edge, let the rest of the world gineau pig the updates and listen for them to sound the alarm if something's wrong. Obviously you do still need to pay attention to the occasional, major, hot security issues and deal with them in a swift fashion.

Another good practice is to control when your updates occur - time them when it's ok to break things and your team has the bandwidth to fix things.

This is why I laughed hard when Microsoft moved to aggressively push Windows updates and the inevitable borking it did to people's computers at the worst possible times ("What's that you said? You've got a multi-million dollar deliverable pitch tomorrow and your computer won't start due to a broken graphics driver update?). At least now there's a "delay" option similar to what you described, but it still riles me that update descriptions are opaque (so you can't selectively manage risk) and you don't really have the degree of control you ought to.

I think Github's Dependabot can help you here. You can also host your own little instance of DependencyTrack and keep up to date with vulnerabilities.

There are no real solutions to the problem, except for reducing exposure somewhat by limiting yourself to a mostly frozen subset of packages that are hopefully vetted more stringently by more people.

You need an EDR and code repo scanner. Exploring this as a technical problem of the infrastructure will accomplish. The people that create these systems are long gone and had/have huge gaps in their capabilities to stop creating these problems.

For example, whenever a new version of a package is released, it's published to the repository but not allowed to be installed for at least 48 hours, and this gives time to any third-party observers to detect a malware early.

But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving ecosystem like Node.js though.

The closest thing I can think of (and this isn't strictly what you described) is reliance on dependabot, snyk, CodeQL, etc which if anything probably contributes to change management fatigue that erodes careful review.

Some other vendors do AI scanning

I doubt anyone would want to touch js packages with manual review.

    ~$ npm view @ctrl/tinycolor --json | grep 4.1.1
       "4.1.1": "2025-09-15T19:52:46.624Z",

Unfortunately, eval is still used in a lot of code, so disabling it isn't trivially viable, and with eval present, detecting fetch calls and such statically becomes the halting problem.

Or setup a caching proxy, whatever is easier for your org. I've had good experience with nexus previously, it's pretty heavy but very configurable, can introduce delays for new versions and check public vulnerability databases for you.

It's purely an efficiency problem though, nothing to do with security, which is covered by lock files.

NPM gets a lot of traffic, there might be other package managers out there, in different languages, that may have been infected in the past and simply don't get the same amount of eyeballs.

In general, I agree with the idea that writing everything yourself results in a higher quantity of low quality software with security issues and bugs, as well as a waste of developers' time. That said, clearly supply chain attacks are a very real threat that needs to be addressed. I just don't think eliminating package managers is a good solution.

https://lobste.rs/s/zvdtdn

These security problems happen much less often in other ecosystems. There is nothing even remotely as bad as NPM.

E.g. malware might be executed when you test code which uses the library, or when you run a dev server, or on a deployed web site.

The entire stack is built around trusting a code, letting it do whatever it wants. That's the problem.

Pardon my ignorance, but couldn't a malicious actor just redefine $PWD before calling a npm script?

Dangerous times we live in.

The "blind" auto updating to latest versions seems to be also an issue here, simply you cannot trust it enough as there is (seemingly) no security vetting process (I mean if you get obfuscated gibberish pushed into a relatively sanely written codebase it should ring some alarms somewhere).

Normally you'd run tests after releasing new versions of your website but you cannot catch these infected parts if they don't directly influence the behavior of your functionality.

But also, npm was very much (like js you could argue) vibed into existence in many ways, eg with the idea of a lock file (eg reproducible builds) _at all_ taking a very long time to take shape.

Some people had their crypto wallets drained I guess, but as far as I am concerned nothing of any real value was lost.

One could argue that your field saw exploits that did far more damage, no?

> Using CVE reports as a weapon

https://www.youtube.com/watch?v=GDdlRiThDeg