Here's my `npm` command these days.
It reduces the attack surface drastically.
alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm'
- No access to my env vars
- No access to anything outside my current directory (usually a JS project).
- No access to my .bashrc or other files.
At work, we're currently looking into firejail and bubblewrap a lot though and within the ops-team, we're looking at ways to run as much as possible, if not everything through these tools tbh.
Because the counter-question could be: Why would anything but ssh or ansible need access to my ssh keys? Why would anything but firefox need access to the local firefox profiles? All of those can be mapped out with mount namespaces from the execution environment of most applications.
And sure, this is a blacklist approach, and a whitelist approach would be even stronger, but the blacklist approach to secure at least the keys to the kingdom is quicker to get off the ground.
firejail, bubblewrap, direct chroot, sandbox-run ... all have been mentioned in this thread.
There is a gazillion list of tools that can give someone analysis paralysis.
Here's my simple suggestion: all of your backend team already knows (or should) learn Docker for production deployments.
So, why not rely on the same?
It might not be the most efficient, but then dev machines are mostly underutilized anyway.
> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.
Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier?
- Switch all projects to `pnpm`? That means switching CI, and deployment processes as well
- Change the way *you* run `npm` on your machine and let your colleagues know to do the same
I don’t get your argument here. 10 isn’t a huge number in my book but I don’t know of course what else that entails.
I would opt for a secure process change over a soft local workflow restriction that may or may not be followed by all individuals. And I would definitely protect my CI system in the same way than local machines. Depending on the nature of CI these machines can have easy access rights. This really depends how you do CI and how lacks security is.
Am I missing something? Don't you also need to change how CI and deployment processes call npm? If my CI server and then also my deployment scripts are calling npm the old insecure way, and running infected install scripts/whatever, haven't I just still fucked myself, just on my CI server and whatever deployment system(s) are involved? That seems bad.
Your machine has more projects, data, and credentials than your CI machine, as you normally don't log into Gmail on your CI. So, just protecting your machine is great.
Further, you are welcome to use this alias on your CI as well to enhance the protection.
Attacking your CI machines means to poison your artifacts you ship and systems they get deployed to, get access to all source it builds and can access (often more than you have locally) and all infrastructure it can reach.
CI machines are very much high-value targets of interest.
> Further, you are welcome to use this alias on your CI as well to enhance the protection.
Yes, but if I've got to configure that across the CI fleet as well as in my deploy system(s) in order to not get, and also be distributing malware, what's the difference between having to do that vs switching to pnpm in all the same places?
Or more explicitly, your first point is invalid. Whether you ultimately choose to use docker to run npm or switch to pnpm,
it doesn't count to half-ass the fix and only tell your one friend on the team to switch, you have to get all developers to switch AND fix your CI system, AND also your deployment system (s) (if they are exposed).
This comment proffers no option on which of the two solutions should be preferred, just that the fix needs to made everywhere.
You do the backward logic here. I would go for a single person to deal with pnpm migration and CI rather than instruct other 10 for everyone to hopefully do the right thing. And think about it when the next person comes in... so I'd go for the first option for sure.
And npm can be configured to prevent install scripts to be run anyways:
> Consider adding ignore-scripts to your .npmrc project file, or to your global npm configuration.
But I do like your option to isolate npm for local development purposes.
pnpm doesn't execute lifecycle scripts by default, so it avoids the particular attack vector of "simply downloading and installing an NPM package allows it to execute malicious code."
As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.
> That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?
I won't execute that code directly on my machine.
I will always execute it inside the Docker container.
Why do you want to run commands like `vite` or `eslint` directly on your machine? Why do they need access to anything outside the current directory?
I get this but then in practice the only actually valuable stuff on my computer is... the code and data in my dev containers. Everything else I can download off the Internet for free at any time.
This kind of mentality, and "seems a bit excessive to sandbox a command that really just downloads arbitrary code", is why the JS ecosystem is so prone to credential theft. It's actually insane to read stuff like that said out loud.
Right but the opposite mentality winds up putting so much of the eggs in the basket of the container that it defeats a lot of the purpose of the container.
pnpm has lots of other good attributes: it is much faster, and also keeps a central store of your dependencies, reducing disk usage and download time, similar to what java/mvn does.
I've tried use pnpm to replace npm in my project, it really speed up when install dependencies on host machine, but much slower in the CI containers, even after config the cache volume. Which makes me come back to npm.
This folk-wisdom scapegoating of post-install scripts needs to stop or people are going to get really hurt by the false sense of security it's creating. I can see the reasoning behind this, I really do, it sounds convincing but it's only half the story.
If you want to protect your machine from malicious dependencies you must run everything in a sandbox all the time, not just during the installation phase. If you follow that advice then disabling post-install scripts is pointless.
The supply chain world is getting more dangerous by the minute and it feels like I'm watching a train derail in slow motion with more and more people buying into the idea that they're safe if they just disable post-install scripts. It's all going to blow up in our collective faces sooner or later.
You're right, it's not just about post-install scripts nor NPM and JavaScript. This is a deep fundamental issue in software development practices across most programming language ecosystems. And not only open-source, since proprietary code is often even worse about vetting dependencies. More eyes are better, therefore open source (or source available) is a prerequisite for security.
Improving NPM's processes, having more companies auditing packages, changing the way NPM the tool works - that's all good but far from enough, it doesn't actually address the root vulnerability, which is that we're way too comfortable running other people's arbitrary code.
Containerization and strict permissions system by default seem to be where we're headed.
There are so many vectors for this attack to piggyback off from.
If I had malicious intentions, I would probably typo squat popular plugins/lsps that will execute code automatically when their editor runs. A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via a docker command.
> A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via a docker command.
Running `npm` inside Docker does not solve this problem.
However, running `npm` inside Docker does not make this problem worse either.
That's why I said running `npm` inside Docker reduces the attack surface of the malicious NPM packages.
I think this approach is harmful because it gives people a false sense of security and makes them complacent by making them feel like they're "doing something about it even if it's not perfect". It's like putting on 5 different sets of locks and bolts on your front door while leaving the back door unlocked and wide open during the night.
Done is better than perfect, and a 100% secure system doesn't exist. Given how prolific those supply-chain attacks are, any mitigation (even if imperfect) seems to be good step toward protecting yourself and your assets
This isn't just "imperfect", it's so deeply flawed that the next minor "mutation" of supply chain attack tactics is guaranteed to wipe you out if you rely on it. It's just a matter of time, it could be tomorrow, next month, maybe a year from now.
Setting up a fully containerized development environment doesn't take a lot of effort and will provide the benefits you think you're getting here - that would be the "imperfect but good enough for the moment" kind of solution, this is just security theater.
Every time I make this point someone wants to have the "imperfect but better than nothing" conversation and I think that shows just how dangerous the situation is becoming. You can only say that in good conscience if you follow it up with "better than nothing ... until I figure out how to containerize my environment over the weekend"
Unfortunately, the current way of how things work is, like you said, "deeply flawed". You will not change it in a few months, not even in a few years too.
What you can do, however, is to adapt to current threats, the same way adversaries adapt to countermeasures. Fully secure setups do not exist, and even if one existed, it would probably become obsolete very quickly. Like James Mickens said, whatever you do, you still can be "Mossad'ed upon". Should we give up implementing security measures then?
Thinking about security in a binary fashion and gatekeeping it ("this is not enough, this is will not protect you against X and Y") is, _in my opinion_, very detrimental.
Sorry, what I'm proposing here is far from binary but yes, I am gatekeeping the bare minimum. It has to be gatekept otherwise I'm afraid we'll enter a state of mass industry delusion where everyone thinks they're safe, "doing something", even "following industry best practices", but in reality all we're doing is: [1]
If a supply chain attack would be a serious incident for you then you need to take meaningful actions to protect yourself. I'm trying to hold "you" (proponents of this idea) accountable because I don't want you to rationalize all of these actions that leave you wide open to future attacks in known, preventable ways and then pretend nobody could've seen this coming when it blows up in our face.
It's not "good enough" - it's negligence because you know that the hole is there, you know that the hackers know about it, you know how trivial it is to exploit, and yet we're arguing whether leaving this known vector open is "good enough" instead of taking the obvious next step.
Containers are very far away from "fully secure" setup, they suffer from escape vulnerabilities far more often than VMs, but their benefit is that they're lightweight and minimally obtrusive (especially for web development) and these days the integration with IDEs is so good you probably won't even notice the difference after a few days of adjusting to the new workflow.
You end up trading a bit of convenience for a lot of security - you're going to be reasonably well protected for the foreseeable future because the likelihood of someone pulling off a supply chain attack and burning a container escape 0-day on it is really low.
That should be good enough for most and if your developer machine needs more protection than this, I'll take a guess and say that your production security requirements are such that they require security review of all your dependencies before using them anyway.
With a VM you would get even more security but you would have to sacrifice a lot more convenience, so given the resistance to the less intrusive option this isn't even worth discussing right now.
The above simple alias may work for node/npm, but it doesn't generalize to many other programs available on the local system, with resources that would need to be mounted into the container ...
> The above simple alias may work for node/npm, but it doesn't generalize for many other programs that are available on the local system, with resources that would somehow have to get mounted into the container ...
Thanks.
You are right, running inside Docker won't always work for local commands.
But I am not even using local commands.
Infact, I have removed `yarn`, `npm`, and several similar tools already from my machine.
That'll still allow access to env vars, and interact with other processes owned by the same user.
At the very least, you really need to add process isolation / namespacing as well - at which point it's going to be easier to just use the sandboxing / containerisation tool of your choice to manage it all for you.
Not sure how secure this really is, because it's fairly easy to break out of a Docker container with the default settings (due to the fact that the kernel is shared between containers and the host, unlike with VMs). Rootless Docker (or better, Podman) would improve security greatly.
There have been quite a few exploits over the years, with the most recent public CVE 2 years ago [1].
Your specific setup uses `--net=host` and this opens you up to potential vulnerabilities (see [2]).
You also shouldn't forget that containers have unrestricted network access bu default anyway. Even if your device is safe, they may be able to infect other vulnerable devices on your network.
I always wondered why people found it acceptable to just run npm on their systems for anything they do, and have it download anything on any build.
Coming from "make" with repeatable and predictable builds, I was appalled that you run this thing and you have no idea what it will download and what it will produce. Could be something different the next time you run it! Who knows!
I also found it bizarre that even for things that just generate CSS, you are expected to integrate it into your npm thing. I mean, generating CSS from a configuration is a function. It's a make recipe. Why does it need to be an npm library dependency with all the associated mess? I managed to work around it for a number of packages by freezing entire npm setups inside docker containers, which gave me reproducible builds — but it's a losing battle.
> Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade?
TBH, I never updated some of the setups. What's the point? Their job was to generate a CSS. Why would I want to upgrade dependencies or inspect that setup?
> arcane docker setups
I take issue with "arcane" — I have much more "arcane" setups than these :-)
Downloading things that you don't know about its common for every modern package manager out there, from maven, to nuget, to pip and npm. This is the new norm and there are reasons for it.
I don't think the old C/C++ way of relying on distro package managers would allow for the fast ecosystems people work nowadays.
Things are changing though, and people are pushing for more secure package managers with the same feature set as the old ones, which is possible.
I think this is the missing piece on the first wondering part of your comment. But I don't think we should be bashing the means without understanding the reasons
'Npm install thing' is easier than programming or even auditing imported code.
Too lazy to write, too cheap to pay for it, that's half of open source.
Now what's going to dominate stackoverflow answers, thoughtful articles on how to program? Or gratis npm/uv installable libraries that hide the actual solution details in between tests and polyfills and readmes, that end up just download another dependency while contributing enough lines of code so that the author can safely put it in their resume and grift over the oss ecosystem to get a cushy 300k/yr job at an extended faang where they are in charge of an ad pixel tracker or yet another one of those wallet things that are just an IO proxy for money but they get to keep some comission if they spend enough money on ads to convince someone to use the thing once and then it becomes their main neo(not) bank* forever.
*for regulatory reasons we must not call it a bank, but it's a bank
The entire Front end dev seems like trust me bro Wild West to me. All feels like endless layers of duct tape. Which I guess in a way it is given the evolution of browsers
I think part of the reason is the embrace of an "each package should do exactly one thing" by many in the community, often taken to a ridiculous extreme. Possibly better now after left-pad and other similar incidents.
I've seen gnarly code everywhere, from kernel drivers to desktop applications to web apps. At the end of the day this describes most of computing imho.
>When you run npm install, npm doesn't just download packages. It executes code. Specifically, it runs lifecycle scripts defined in package.json - preinstall, install, and postinstall hooks.
What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer?
> What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer?
The paradigm itself has been in package managers since DEB and RPM were invented (maybe even Solaris packages before that? it's been a minute since I've Sun'd); it's not the same as NPM, a more direct comparison is the Arch Linux AUR - and the AUR has been attacked to try and inject malware all year (2025) just like NPM. As of the 26th (5 days ago) uploads are disabled as they get DDOSed again. https://status.archlinux.org/ (spirit: it's the design being attacked, pain shared between AUR and NPM as completely disparate projects).
More directly to an example: the Linux kernel package. Every Linux distribution I'm aware of runs a kernel package post-install script which runs arbitrary (sic) commands on your system. This is, of course, to rebuild any DKMS modules, build a new initrd / initramfs, update GRUB bootloader entries, etc. These actions are unique outputs to the destination system and can't be packaged.
I have no data in front of me, but I'd speculate 70% (?) of DEB/RPM/PKG packages include pre / post install/uninstall scriptlets, it's very common in the space and you see it everywhere in use.
Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago they ended up adding downloadable builds for the most common platforms, but for anything else the expectation still was (and is, I guess) to build sources at install time.
Believe such build tools and processes should be run inside a container environment. Maybe once all OS have native, cheap and lean containers and permit dead simple container execution of scripts, this will be possible.
People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done." I hope we can get to a world where such hooks are no longer required one day.
Hard. In npm land you install React and 900 other dependencies come with it. And how ok are you reviewing every single one of those scripts and manually running them? Not that it is good that this happens but realistically most people would just say “run all” and let it run instead of running each lifecycle script by hand.
My solution is to bypass React entirely. I'd much rather have a smaller, possibly less functional or pretty front end than to have to worry about this stuff continuously. I would not get any work done. There is no way I'm going to take on board 900 dependencies which I will then inflict on the visitors to my website.
I am people and I don’t want to download 900 dependencies. But if I want to use React or Vue or anything but the most trivial JS libraries or frameworks I am held hostage by the fact that their dependencies have dependencies.
Surely there are ways to just stick to absolute basics and you can get quite far with what is built in or some very small libraries, but I guess it depends on where you would be most productive.
rpm and dpkg both provide mechanisms to run scripts on user machines (usually used to configure users and groups on the user machine), so this aspect is not an NPM-specific. Rust has the same thing with build.rs (which is necessary to find shared C libraries for crates that link with them) so there is a legitimate need for this that would be hard to eliminate.
Personally, I think the issue is that it is too easy to create packages that people can then pull too easily. rpm and dpkg are annoying to write for most people and require some kind of (at least cursory) review before they can be installed on user's systems from the default repos. Both of these act as barriers against the kinds of lazy attacks we've seen in the past few months. Of course, no language package registry has the bandwidth to do that work, so Wild West it is!
rpm and dpkg generally install packages from established repos that vet maintainers. It's not much but having to get one or two other established package authors to vouch for you and having to have some community involvement before you can publish to distro repos is something.
There's nothing inherently wrong with that. The problem is npm allows any random person to upload packages. It's completely untrusted. Contrast that with Linux distributions which have actual maintainers who take responsibility for their packages. They don't generally allow malware to make it into the official software repositories. In many cases they went as far as meeting each other in person just to set up a decentralized root of trust with PGP. It's so much better and more trustworthy.
The truth is npm, pip, rubygems, cargo and all the other programming language package managers are just fancier versions of the silly installation instructions you often find in README files that tell people to curl some script and pipe it into bash.
Even when random people are allowed to contribute (AUR, PPAs) there seems to be more scrutiny and fewer incidents. Possibly because they are secondary to the main repos and possibly because the people who use them are made aware of the risks.
NPM etc. are a bit like Arch would be if everything was in AUR.
With PPAs or COPR (or third party repositories, e.g. slack) you have to explicitly enable each repository too. Even if a repository is enabled by package you are prompted the first time a new repository is used (actually I don't know if that's true when gpgcheck is disabled? If not this would be an easy fix in apt/dnf)
It’s just security theater in the end. You can just as easily put all that stuff in the package files since a package is installed to run code. You have that code then do all the sketchy stuff.
What’s needed is an entitlements system so a package you install doesn’t do runtime stuff like install crypto mining software. Even then…
A package, especially a javascript package, is not necessarily installed to run code, at least not on the machine installing the package. Many packages will only be run in the browser, which is already a fairly safe environment compared to running directly on the machine like lifecycle scripts would.
So preventing lifecycle scripts certainly limits the number of packages that could be exploited to get access to the installing machine. It's common for javascript apps to have hundreds of dependencies, but only a handful of them will ever actually run as code on the machine that installed them.
True… I do a lot of server or universal code. But don’t trust browser code either. Could be connecting to MetaMask and stealing crypto, running mining software, or injecting ads.
And with node you get files and the ability run arbitrary code on arbitrary processes.
I would expect to be able to download a package and then inspect the code before I decide to import/run any of the package files. But npm by default will run arbitrary code in the package before developers have a chance to inspect it, which can be very surprising and dangerous.
PHP composer does the same, in config.allow-plugins.<package> in composer.json. The default behavior is to prompt, with an "always" option to add the entry to composer.json. It's baffling that npm and yarn just let the scripts run with nary a peep.
Finally sane solution. When I was thinking about package manager design, I also thought that there should be no scripts, the package manager should just download files and that's all.
The objection is to the redundant, flowery prose overall, and the overall inaccuracy. (Of course the installer "doesn't just download packages"; installation at minimum would also involve unpacking the archive and putting the files in the right place....)
In about as much text, we could explain far better why and how NPM's behaviour is risky:
> When you install a package using `npm install`, NPM may also run arbitrary code from the package, from multiple hook scripts specified in `package.json`, before you can even audit the code.
A) maintainers don’t know any better and connect things with string and gum until it most works and ship it
B) people who are smart, but naive and think it will be different this time
C) package manager creators who think they’re creating something that hasn’t been done before, don’t look at prior art or failures, and fall into all of the same holes literally every other package manager has fallen into and will continue to fall into because no one in this industry learns anything.
Many front end tools are written in a faster language. For example, the next version of TypeScript compiler, SASS, SWC (minifier), esbuild (bundler used by Vite), Biome (formatter and linter), Oxc (linter, formatter and minifier), Turbopack (bundler), dprint (formatter), etc.
They use proinstall script to fetch pre-built binaries, or compile from source if your environment isn't directly supported.
Notable times this has bitten me include compiling image compression tools for gulp and older versions of sass, oh and a memorable one with openssl. Downloading a npm package should ideally not also require messing around with c compilation tools.
I feel super uneasy developing Software with Angular, Vue or any framework using npm. The amount of dependencies these frameworks take is absolutely staggering. And just by looking at the dependency tree and thousands of packages in my node_modules folder, it is a disaster waiting to happen. You are basically one phishing attack on a poor open source developer away from getting compromised.
To me the entire JavaScript ecosystem is broken. And a typo in your “npm -i” is sufficient to open up yourself for a supply-chain attack. Could the same happen with NuGet or Maven? Sure!
But at least in these languages and environments I have a huge Standard Library and very few dependencies to take. It makes me feel much more in control.
Of course, this only works so long as the sandbox is secure.
There have been attempts to do this kind of sandboxing before. Java and .NET both used to have it. Both dropped it because it turns out that properly sandboxing stuff is hard.
Go kinda solves this by using repo links instead of package names. This forces you to go through the repo and copy paste the url (instead of manually typing it out), but it's not bulletproof I guess.
Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else.
When I build backend in flask or Django, I specifically type the python packages that I need. But front end development seems like a Pandora box of vulnerabilities
All package ecosystems that allow unvetted code being published are affected, it just happens that npm is by far the most popular one, so it gets all the news.
Oh man you pick the one other language that followed the JavaScript model?! How about C, Java, Go, Lisp, C#, C++, D… and new ones like Odin that are explicitly against package managers for this very reason.
When you start writing with C, where do you get your stdio.h file? Do you write it yourself, or inspect it line by line every time or do you trust the installation package you just ran?
Hm... if you use something like Debian it's quite difficult to get your package installed in the distro. People do review everything that goes in.
I find it incredibly silly to compare something like that to npm, where every kid has dozens of packages installed that anyone using npm can end up downloading and no one is really reviewing anything.
I agree one is more difficult than the other, but I feel the principal is the same. Whilst anything is built using other modules, there is always risk those modules will be compromised.
What can we do about it indeed!? I guess its either fully digitally detox or accept the fact that if you use modern technology then somebody is watyching what you do.
But it is. Both C/C++ and Go are not at all like this.
I don’t know about Python but Rust ecosystem tends attract enthusiasts who make good single purpose packages but that are abandoned because maintainers move on, or sometimes forked due to minor disagreements similar to how Linux/unix is fragmented with tribal feuds.
M'yea, good luck finding such occurrence with NuGet or Maven for example. I would rephrase your "anywhere else".
NPM is a terrible ecosystem, and trying to defend its current state is a lost cause. The energy should be focused on how to fix that ecosystem instead of playing dumb telling people "it's all ok, look at other, also poorly designed, systems".
Don't forget that Rust's Cargo got heavily inspired by NPM, which is not something to brag about.[0]
> "Rust has absolutely stunning dependency management," one engineer
enthused, noting that Rust's strategy
took inspiration from npm's.
What's wrong with micro dependencies? Isn't it better to download only the code you need? Also it makes refactoring easier, and enforces better architecture.
Larger attack surface - you just need one of those N dependencies to fall for a spear phishing attack and you're cooked. Larger N is necessarily worse.
It depends on the software being written, but if it's a product your business sells or otherwise has an essential dependency on, then the best model available right now is vendoring dependencies.
You still get all the benefits of standing on top of libraries and frameworks of choice, but you've introduced a single point of entry for externally authored code - there are many ways you can leverage that to good effect (vuln scans, licence audits, adding patch overlays etc etc) and you improved the developer experience - when they check out the code, ALL of the code to build and run the project is already present, no separate npm install step.
You can take this model quite a bit further and buy some really useful capabilities for a development team, like dependency upgrades because they're a very deliberate thing now, you can treat them like any other PR to your code base - you can review the changes of each upgrade easily.
There's challenges too - maybe your npm dep builds a native binary as part of it, you now need to provide that build infra / tooling, and very likely you also want robust build artifact and test caching to save wasting lots of time.
Rust has a really big and comprehensive stdlib, especially compared to languages like C or JavaScript. It just decided that certain things won't be solved in the standard lib because there is no obviously-right solution and evolving towards a good solution is much easier in packages than in the stdlib, because the stdlib isn't versioned.
Some of the gaps feel huge, like no random, no time/date handling, and no async runtime. But but for most of them there are canonical packages that 95% of the ecosystem uses, with a huge amount of eyeballs on them. And sometimes a better solution does emerge, like jiff slowly replacing chrono and time for time/date handling.
Obviously this isn't the best solution from a security perspective. There would be less potential for supply chain attacks if everything was in the standard library. But that has to be weighed against the long-term usability of the language
I come from a JavaScript background, and I've got to admit that the ecosystem is designed in a way that is really prone to attack.
It is like the xz incident, except that each dependency you pull is maintained by a random guy on the internet. You have to trust every one of them to be genuine and that they won't fall into any social engineering attacks.
Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.
No language ecosystem is but NPM/Node still encourages this idea (borrowed elsewhere and interpreted poorly) that everything must be its own tiny package and that it's acceptable to author libraries consisting of thousands of transitive dependencies from potentially dubious sources. Just this week I saw one (unmaintained dependency of a popular package) which consisted of a list of a dozen SQL operators. Anywhere else you would just write the damn code, maybe add a comment that these are the SQL-92 operators and be done with it literally forever. But in Node land that would be viewed as an antipattern which only another package can fix. It's a security and maintenance nightmare that can only be explained by laziness and outright stupidity.
It's a misconception that NPM or Node encourage this, because they don't. There are a few package authors that are doing it that way (some even paid by download count), but that's their opinion.
Recently there is a trend towards minimal-dependency packages and I would certainly recommend auditing every package for its dependencies before using it.
Here's my black pill: Node in general is not safe.
The blurring of the client-server lines is a security risk. Very easy to expose the wrong thing; the language appeals to people who know 1 language (which correlates with lack of experience).
In my personal experience node projects developed under my supervision had very basic client-server boundary vulns 66.67% of the time. Empirically it's not great.
> As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else.
Oh, absolutely, there is no question about it. Fewer dependencies means less headache; and if you can get the number of your dependencies to zero, then you have won the internet.
> Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts for installed dependencies, such as `postinstall` and `node-gyp` builds. These scripts represent a potential security risk, as they can execute arbitrary code on your machine.
Hmmm, it still has a pretty extensive default list of permitted npm packages, which wouldn't necessarily be a problem if there were a way to disable it, but I can't seem to find it.
the latter is what i was getting at yeah. updated list of standard library-esque functions implemented in native code so the need to reach to npm for a dependency happens far less often.
Keep in mind that the vast majority of the 86,000 downloads are probably automated downloads by tools looking for malicious code, or other malicious tools pulling every new package version looking for leaked credentials.
When I iterate with new versions of a package that I’ve never promoted anywhere, each version gets hundreds of downloads in the first day or two of being published.
86,000 people did not get pwnd, possibly even zero.
As TFA says, they're targeting package names that are somewhere in LLM training data but don't actually exist, so are being hallucinated by LLMs. And there's now a large number of folks with zero clue busy vibe-coding their killer app with no idea that bad things can happen.
I would not be surprised to find that 80%+ of those 86,000 people got pwned.
As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project.
Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot to infiltrate because I’m not sophisticated enough to stop it.
> As a hobbyist how do I stay protected and in the loop for breaches like this?
For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe.
The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladder but not nearly as bad as the user-submitted madness outside Linux).
But it seems like your question is about front end web development, and that's not my world and I have no advice beyond sympathy.
> occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot
Pretty much that's the problem exactly. Distributing software is hard. It's a lot of work at a bunch of different levels of the process, and someone needs to commit to doing it. If you aren't willing to commit your time and resources, don't distribute it in a consumable way (obviously you can distribute what you built with it, and if it's appropriately licensed maybe someone else will come along and productize it).
NPM thought they could hack that overhead and do better, but it turns out to have been a moved-too-fast-and-broke-things situation in hindsight.
> PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe.
One obvious further mitigation for Python is to configure your package installer to require pre-built wheels, and inspect the resulting environment prior to use. Of course, wheels can contain all sorts of compiled binary blobs and even the Python code can be obfuscated (or even missing, with just a compiled .pyc file in its place); but at least this way you are protected from arbitrary code running at install time.
Having spent a year trying to develop against dependencies only provided by a debian release, it is really painful in practice. At some point you're going to need something that is not packaged, or newer than the packaged version in your release.
It really depends on what you're doing. But yes, if you want to develop in "The NPM Style" where you suck down tiny things to do little pieces of what you need (and those things suck down tiny things, ad infinitum) then you're naturally exposed to the security risks inherent with depending on an unaudited soup of tiny things.
You don't get secure things for free, you have to pay for that by doing things like "import and audit software yourself" or even "write simple utilities from scratch" on occasion.
They did, and no one is perfect. But Debian is the best.
FWIW, the subject at hand here isn't accidentally introduced security bugs (which affect all software and aren't well treated by auditing and testing). It's deliberately malicious malware appearing as a dependency to legitimate software.
So the use case here isn't Heartbleed, it's something like the xz-utils trojan. I'll give you one guess as to who caught that.
Somewhat controversial these days, but treat every single dependency as a potential security nightmare, source of bugs, problem that you will have to solve in the future. Use dependencies carefully and as a last resort.
Vendoring dependencies (copying the package code into your project rather than using the package manager to manage it) can help - it won't stop a malicious package, but it will stop a package from turning malicious.
You can also copy the code you need from a dependency into your code (with a comment giving credit and a link to the source package). This is really useful if you just need some of the stuff that the package offers, and also forces you to read and understand the package code; great practice if you're learning.
Inspecting 10 layers of dependencies individually to install a popular tool or an lsp server is going to work once or twice. Eventually either complacency or fatigue sets in and the attacker wins.
I think we need a different solution that fixes the dependency bloat or puts more safeguards around package publishing.
The same goes for any other language with excessive third-party dependency requirements.
Why would attitudes change? The impact is diffused across a wide enough populace (precisely because ecosystems with weak community norms around dependency security are extremely popular) that the rate of “shaping up in response to a painful lesson” may remain lower than the rate of newcomers joining the community or the rate of new insecure dependencies proliferating to serve new needs brought about by new use cases brought about by growing popularity of a platform.
That’s not to say it’s hopeless. Rather, it’s more likely that widespread improvement will need to be centrally orchestrated rather than organic in response to hacks.
Use dependencies that are fairly popular and pick a release that's at least a year old. Done. If there was something wrong with it, someone would've found it by now. For a hobbyist, that's more than sufficient.
Don't do development on your local machine. Full stop. Just don't.
Do development, all of it, inside VMs or containers, either local or remote.
Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling.
This has the added benefit of not only sandboxing your code, but also making your dev environments repeatable.
If you are using GitHub, use codespaces. If you are using gitlab, workspaces. If you are using neither, check out tools like UTM or Vagrant.
That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.
The way to sell it isn't vague security somethings, but in making it easier to reproduce the build environment "from scratch". If you build the Dockerfile as you go, then you don't waste hours at the end trying to figure out what you did to get it to build and run in the first place.
its not particularly painful to develop in a container. Maybe docker is a nuisance (although I know people do do develop within docker) but something like firejail or bubblewrap is pretty easy to use.
Taking this more seriously than it perhaps deserves: if that’s true, why isn’t widespread adoption of this approach growing?
Whether or not it’s a good idea, “realistic” implies practicality, which could presumably be measured by whether people find it worthwhile to do the thing.
I suppose it depends on what you're protecting, who's out there to get you, and how boring and time consuming it is to clean up after a breach (can't that take weeks or months), etc.
Aren't you're a bit asking "When X transportation method isn't used by everyone, can it really be any good?" :-)
When I had a Macbook from work, I set up an Arch Linux VM using their basic VM image [1], and followed these steps (it may differ, since is quite old): https://www.youtube.com/watch?v=enF3zbyiNZA
Then, I removed the graphical settings, as I was aiming to use SSH instead of emulated TTY that comes ON by default with UTM (at that time).
Finally, I set up some basic scripting to turn the machine on and SSH into it as soon as sshd.service was available, which I don't have now, but the script finished with this:
(fish shell)
while not ssh -p 2222 arch@localhost; sleep 2; end;
Later it evolved in something like this:
virsh start arch-linux_testing && virsh qemu-monitor-command --hmp arch-linux_testing 'hostfwd_add ::2222-:22' && while not ssh -p 2222 arch@localhost; sleep 2; end;
I also removed some unnecessary services for local development:
It works incredibly well with Linux VMs, my daily driver. I plug in a USB keyboard, external monitor and Can't Believe It's Not Linux. Only occasionally when I need to use the laptop screen/keyboard does macOS bother me and remind of it real self.
There's around 10-15% performance penalty for VMs (assuming you use arm64 guests), but the whole system is just so much faster and well built than anything Intel-based to day, that it more than compensates.
For Windows, it's lacking accelerated video drivers, but VMWare Fusion is an ok free alternative - I can totally play AAA games from last decade. Enjoy it until broadcom kills it.
I started using UTM last week on my Macbook just to try out NixOS + sway and see if I could make environment that I liked using (inspired by the hype around Omarchy).
Pretty soon I liked using the environment so much that I got my work running on it. And when I change the environment, I can sync it to my other machine.
Though NixOS is particularly magical as a dev environment since you have a record of everything you've done. Every time I mess with postgres hb_conf or nginx or pcap or on my local machine, I think "welp, I'll never remember that I did that".
With remote development (vscode and remote extension in jetbrains with ssh to VM) performance is good with headless VM in UTM. Although it always (?) uses performance cores on Apple Silicon Macs, so battery drain is a problem
I used to have a separate account on my box for doing code for other people, one for myself and another for surfing the web. Since I have an Apple TV hooked up to one of my monitors I don’t have a ton of reasons for hopping credentials between accounts so I think I’ll be going back to at least that.
The fact I use nvm means a global install won’t cross accounts.
There are some operating systems, like FreeBSD, where you use the system’s package manager and not a million language specific package managers.
I still maintain pushing this back to library authors is the right thing to do instead of making this painful for literally millions of end-users. The friction of getting a package accepted into a critical mass of distributions is the point.
Recently I switched to Bun in part because many dependencies are already included (db driver, s3 client, etc) that you'd need to download with Node or Deno.
(1) Start by not using packages that have stupid dependencies
Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages. Those 2 things, a library that provides some functionality, and a CLI command that lets you use the library from the command line, SHOULD NEVER BE MIXED.
The library should be its own package without the bloat of the command line crap
(2) Choose low dependency packages
Example: commander has no dependencies, minimist now has no dependencies. Some other command line parsers used to have 10-20 dependencies.
(3) Stop using packages when you can do it yourself in 1-2 lines of JS
You don't need a package to copy files. `fs.copyFileSync` will copy a file for. `fs.cpSync` will copy a tree, `child_process.spawn` will spawn a process. You don't need some package to do these things. There's plenty of other examples where you don't need a package.
> Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages.
After your little rant you point out Commander has zero dependencies. So I don’t know what’s up with you.
If the library you’re building has anything with application lifecycle, particularly bootstrapping, then having a CLI with one dependency is quite handy for triage. Most especially for talking someone else through triage when for instance I was out and there was a production issue.
Which is why half the modules I worked on at my last place ended up with a CLI. They are, as a rule, read mostly. Which generally doesn’t require an all caps warning.
Does every module need one of those? No. But if your module is meant as a devDependency, odds are good it might. And if it’s bootstrapping code, then it might as well.
Running things in containers and VMs reduces the damage. One service on your homelab being compromised is a lot better than your entire homelab server getting compromised.
Neither is a security guarantee, but it does add a substantial extra barrier.
I'm not sure about NPM specifically, but in general: Pick a specific version and have your build system verify the known good checksum for that version. Give new packages at least 4 weeks before using them, and look at the git commits of the project, especially for lesser-known packages.
If you're on Linux, I've tried to build an easy yet secure way to isolate your system from your coding projects with containers. See https://github.com/evertheylen/probox
As 'numbsafari said below, you should no longer user your host for dev..this includes all those cool AI assistant tools. You need to containerize all the things with runpod or docker
Because these are fetching dependencies in the lifecycle hooks, even if they are legitimate at the moment there is no guarantee that it will stay that way. The owner of those dependencies could get compromised, or themselves be malicious, or be the package owner waiting to flip the switch to make existing versions become malicious. It's hard to see how the lifecycle hooks on install can stay in their current form.
Cybersecurity professionals are police officers and detectives first, technologists second. They are supposed to catch criminals who abuse technology. I find it distasteful to blame a tool and an entire community for things that criminals are responsible for.
There is nothing about Go, or Cargo, or Nuget, or any of the other systems that prevents criminals from committing crimes. Some cleverness can slow them down, or block certain roads to exploiting these systems, but managing risk in a supply chain is essential no matter which technology ecosystem is used.
Let's stop name-calling and throwing shade at specific tools and communities and get better at educating new-comers to the trade, and shaming and ostracizing the cyber-criminals who are causing the problems.
Just this year Microsoft removed 300 NuGet packages by mistake as they were trying to automate defenses. They got pretty bad press after that so you will get bad comments one way or the other.
NPM ecosystem is very open it is not a bug it is a feature. There are of course issues from being open but NPM already has a lot of security features in place.
> Many of the dependencies used names that are known to be “hallucinated” by AI chatbots. Developers frequently query these bots for the names of dependencies they need. LLM developers and researchers have yet to understand the precise cause of hallucinations or how to build models that don’t make mistakes. After discovering hallucinated dependency names, PhantomRaven uses them in the malicious packages downloaded from their site.
I found it very interesting that they used common AI hallucinated package names.
Happy I keep a mirror of my deps, that I have to "manually" update. But also, the download numbers are not really accurate for actual install count - for example each test run could increment.
I wonder what could one do if he wants to use NPM for programming with a very popular framework (like Angular or Vue) and stay safe. Is just picking a not very recent version of the top level framework (Angular, etc.) enough? Is it possible to somehow isolate NPM so the code it runs, like those postinstall hooks, doesn't mess with your system, while at the same time allowing you to use it normally?
One option to make it a little safer is to add ignore-scripts=true to a .npmrc file in your project root. Lifestyle scripts then won't run automatically. It's not as nice as Pnpm or Bun, though, since this also prevents your own postinstall scripts from running (not just those of dependencies), and there's no way to whitelist trusted packages.
The npm ecosystem's approach to supply chain security is criminally negligent. For the critical infrastructure that underpins the largest attack surface on the Internet you would think that this stuff would be priority zero. But nope, it's failing in ways that are predictable and were indeed predicted years ago. I'm not closely involved enough with the npm community to suggest what the next steps should be but something has to change, and soon.
Is there a way to detect/filter dependencies that use HTTP URLs as dependency specifiers as part of an NPM install? Since you can send specific requesters different payloads, I can see how this would bypass most of the normal scanning tools.
I am surprised that anyone in this year runs scripts from random people from Github without sandboxing. As a wise proverb says, a peasant won't cross himself until the thunder bursts out. Spend a couple hours setting up a sandbox and be safer.
This ultimately needs to get addressed at the OS level. Why is a random JS file on disk allowed to read my browser cookies without my awareness? Why is a native extension downloaded from S3? This goes across all package managers (npm, pypi, cargo).
I think security controls on macOS have been trending in the right direction to tackle these types of things comprehensively with secure domains, sandboxing, etc. but there is always a war of how much friction is too much when it comes to security.
We saw the same thing with 2SV where people were vehemently against it, and now many are clamoring that it should be the only way to be able to do things like publish packages (I agree! I have no issue jumping through some extra hoops when I publish something a million people will install).
This might be a hot take but I think a lot of loud mouths with their personal preferences have been holding security in this space back for a while, and recently people seem to be getting tired of it and pushing through. The engineering leadership that won't just make these types of high impact security decisions because it might irritate a handful of highly opinionated workflows is unfortunate!
Really good internal security practices by the people who make the OS :) I don't think an attacker would be able to pull off disabling features like secure domains, secure enclave, etc. in macOS without anyone noticing seeing as it takes months of approvals, testing, etc. for a single build to even hit the beta channel.
Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that have been admitted to the depository, and you never just eagerly fetch other versions that purport to be updates right before build time. If there is an update, you can download a copy and admit it to your repo at the normal time that you verify that your program actually needs the update. Even if it sounds far-fetched, I imagine we could get by with a system like this.
You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.
No. I am literally describing bog standard use of an ordinary VCS/SCM where the code for e.g. Skia, sqlite, libpng, etc. is placed in a "third-party/" subdirectory. Except I'm deliberately using the words "admit" and "depository" here instead of "commit" and "repository" in keeping with the theme—of the widespread failure of people to use SCMs to manage the corresponding source code required to build their product/project.
Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed not just folks' ability to conceive of just using an SCM like Git or Mercurial to manage source the way that they're made for without introducing a second, half-assed, "registry"-dependent VCS into the mix, but also destroyed the ability to recognize when a comment on the subject is dripping in the most obvious, easily detectable irony.
Yeah, people invented the concept of packages and package management because they couldn’t conceive of vendoring (which is weird considering basically all package managers make use of it themselves) and surely not because package management has actual benefits.
Maybe in a perfect world, we’d all use a better VCS whose equivalent of submodules actually could do that job. We are not in that world yet.
Do you understand the reasons, and are you able to clearly articulate them? Are you able to describe the tangible benefits in the form of a set of falsifiable claims—without resorting to hand-waving or appeals to the perceived status quo or scoffing as if the reasons are self-evident and not in question or subject to scrutiny?
not really, because you can't easily see what changed when you get a new version. When you check in the third_party repo to your VSC, then when you get a new version, everything that changed is easily visible `git diff` before you commit the new changes. With a lockfile, the only diff is the hash changed.
Not if you use git submodules, which is how most people would end up using such a scheme in practice (and the handful of people that do this have ended up using submodules).
Go-style vendoring does dump everything into a directory but that has other downsides. I also question how effectively you can audit dependencies this way -- C developers don't have to do this unless there's a problem they're debugging, and at least for C it is maybe a tractible problem to audit your entire dependency graph for every release (of which there are relatively few).
Unfortunately IMHO the core issue is that making the packaging and shipping of libraries easy necessarily leads to an explosion of libraries with no mechanism to review them -- you cannot solve the latter without sacrificing the former. There were some attempts to crowd-source auditing as plugins for these package managers but none of them bore fruit AFAIK (there is cargo-audit but that only solves one part of the puzzle -- there really needs to be a way to mark packages as "probably trustworthy" and "really untrustworthy" based on ratings in a hard-to-gamify way).
The problem is that not enough people care about reviewing dependencies’ code. Adding what they consider noise to the diff doesn’t help much (especially if what you end up diffing is actually build output).
Now you have the opposite problem, where a vulnerability could be found in one of your dependencies but you don't get the fix until the next "normal time that you verify that your program actually needs the update".
This is how most software used to work before internet package managers, and it turns out that the same people who aren't good at checking their dependencies before automatically upgrading are also not good at constantly monitoring their dependencies for vulnerabilities.
Engineering used as a title should be regulated in the software industry; it was always a title reserved for a role that requires accountability. In software, it became used so casually without legal restriction that full stack developers started using it.
This is most often pushed on the person by their company. I don't have an Eng degree nor certification, but my company forces my title to be "... Engineer", which I dislike, but I've been told this is just how it is.
A day ago I got down voted to hell for saying that the JavaScript ecosystem has rotted the minds of developers and any tools that emulate npm should be shunned as much as possible - they are not solutions, they are problems.
I don't usually get to say 'I told you so' within 24 hours of a warning, but JS is special like that.
There's nothing really specially about the JS ecosystem that creates this problem. Plenty of others could fall in the same way, including C++ (see xz).
The problem is we've been coasting on an era where blind trust was good enough an programming was niche enough.
In c++, most people wouldn't publish a library that does the equivalent of (1 == value % 2). Even if they did, almost no one would use it. For npm, that library will not only exist, it will have several dependencies and millions of downloads
That increases the surface area, which is certainly bad. But that doesn't really mean the risk isn't similarly there for C++.
A few years back, the university of Minnesota was banned from the kernel (are they still banned?) for testing this exact theory. They tried to figure out how hard it would be to inject an intentional CVE into the kernel.
Of course, it's a risk with any dependency, but for a small number of dependencies you're more likely to be able to do some level of vetting.
The university of Minnesota would have had a much easier time not getting caught if there had been a tree of thousands of independently maintained dependencies
In practice this means that in C and C++ land you have large framework-style libraries (GLib, Boost, Qt etc), which are much easier to vet, and doing it ones gives you a whole lot of goodies at once with minimal dependencies.
You ain't wrong. Now we have industries that built software using less valuable labor that does not need to understand the technical layers underneath the application development environment. Not unlike the experience of someone who started driving a few weeks before their driving test versus someone who has been driving since the age of six.
Unpopular opinion: why not reduce the dependency on 3rd party packages? Why not reduce the number of dependencies so you can know what code you are using?
Here's my `npm` command these days. It reduces the attack surface drastically.
Ref: https://ashishb.net/programming/run-tools-inside-docker/That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?
Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.
At work, we're currently looking into firejail and bubblewrap a lot though and within the ops-team, we're looking at ways to run as much as possible, if not everything through these tools tbh.
Because the counter-question could be: Why would anything but ssh or ansible need access to my ssh keys? Why would anything but firefox need access to the local firefox profiles? All of those can be mapped out with mount namespaces from the execution environment of most applications.
And sure, this is a blacklist approach, and a whitelist approach would be even stronger, but the blacklist approach to secure at least the keys to the kingdom is quicker to get off the ground.
firejail, bubblewrap, direct chroot, sandbox-run ... all have been mentioned in this thread.
There is a gazillion list of tools that can give someone analysis paralysis. Here's my simple suggestion: all of your backend team already knows (or should) learn Docker for production deployments.
So, why not rely on the same? It might not be the most efficient, but then dev machines are mostly underutilized anyway.
> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.
Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier?
I find the second to be a lot easier.I don’t get your argument here. 10 isn’t a huge number in my book but I don’t know of course what else that entails. I would opt for a secure process change over a soft local workflow restriction that may or may not be followed by all individuals. And I would definitely protect my CI system in the same way than local machines. Depending on the nature of CI these machines can have easy access rights. This really depends how you do CI and how lacks security is.
I'll do soft local workflow restriction right away.
The secure process change might take anywhere from a day to months.
There are a great many extra perks to switching to pnpm though. We switched on our projects a while back and haven’t looked back.
Yeah, id just take the time to convert the 10 projects rather than try to get 50 people to chnage their working habots, plus new staff coming in etc.
Switch your projects once, done for all.
So, switching to pnpm does not entail any work habit changes?
Am I missing something? Don't you also need to change how CI and deployment processes call npm? If my CI server and then also my deployment scripts are calling npm the old insecure way, and running infected install scripts/whatever, haven't I just still fucked myself, just on my CI server and whatever deployment system(s) are involved? That seems bad.
Your machine has more projects, data, and credentials than your CI machine, as you normally don't log into Gmail on your CI. So, just protecting your machine is great.
Further, you are welcome to use this alias on your CI as well to enhance the protection.
Attacking your CI machines means to poison your artifacts you ship and systems they get deployed to, get access to all source it builds and can access (often more than you have locally) and all infrastructure it can reach.
CI machines are very much high-value targets of interest.
> Further, you are welcome to use this alias on your CI as well to enhance the protection.
Yes, but if I've got to configure that across the CI fleet as well as in my deploy system(s) in order to not get, and also be distributing malware, what's the difference between having to do that vs switching to pnpm in all the same places?
Or more explicitly, your first point is invalid. Whether you ultimately choose to use docker to run npm or switch to pnpm, it doesn't count to half-ass the fix and only tell your one friend on the team to switch, you have to get all developers to switch AND fix your CI system, AND also your deployment system (s) (if they are exposed).
This comment proffers no option on which of the two solutions should be preferred, just that the fix needs to made everywhere.
You do the backward logic here. I would go for a single person to deal with pnpm migration and CI rather than instruct other 10 for everyone to hopefully do the right thing. And think about it when the next person comes in... so I'd go for the first option for sure.
And npm can be configured to prevent install scripts to be run anyways:
> Consider adding ignore-scripts to your .npmrc project file, or to your global npm configuration.
But I do like your option to isolate npm for local development purposes.
> which one is easier?
> Switch all projects to `pnpm`?
Sorry; I am out of touch. Does pnpm not have these security problems? Do they only exist for npm?
pnpm doesn't execute lifecycle scripts by default, so it avoids the particular attack vector of "simply downloading and installing an NPM package allows it to execute malicious code."
As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.
Exactly so you should still execute all JS code in a container.
> That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?
I won't execute that code directly on my machine. I will always execute it inside the Docker container. Why do you want to run commands like `vite` or `eslint` directly on your machine? Why do they need access to anything outside the current directory?
I get this but then in practice the only actually valuable stuff on my computer is... the code and data in my dev containers. Everything else I can download off the Internet for free at any time.
No.
Most valuable data on your system for a malware author is login cookies and saved auth tokens of various services.
Maybe keylogging for online services.
But it is true that work and personal machines have different threat vectors.
Yes, but I'm willing to bet most workers don't follow strict digital life hygiene and cross contaminate all the time.
You don't have any stored passwords? Any private keys in your `.ssh/`? DB credentials in some config files? And the list goes on and on.
I don't store passwords (that always struck me as defeating the purpose) and my SSH keys are encrypted.
This kind of mentality, and "seems a bit excessive to sandbox a command that really just downloads arbitrary code", is why the JS ecosystem is so prone to credential theft. It's actually insane to read stuff like that said out loud.
Right but the opposite mentality winds up putting so much of the eggs in the basket of the container that it defeats a lot of the purpose of the container.
It's weird that it's downvoted because this is the way
maybe i'm misunderstanding the "why run anything on my machine" part. is the container on the machine? isn't that running things on your machine?
is he just saying always run your code in a container?
> is the container on the machine?
> is he just saying always run your code in a container?
yes
> isn't that running things on your machine?
in this context where they're explicitly contrasted, it isn't running things "directly on my machine"
it annoys me that people fully automate things like type checkers and linting into post commit or worse entirely outsourced to CI.
Because it means the hygiene is thrown over the fence in a post commit manner.
AI makes this worse because they also run them "over the fence".
However you run it, i want a human to hold accountability for the mainline committed code.
I run linters like eslint on my machine inside a container. This reduces attack surface.
How does this throw hygiene over the fence?
Yes in a sibling reply, i was able to better understand your comment to mean "run stuff on my machine in a container"
pnpm has lots of other good attributes: it is much faster, and also keeps a central store of your dependencies, reducing disk usage and download time, similar to what java/mvn does.
> command that really just downloads arbitrary code you are going to execute immediately afterwards anyways?
By default it directly runs code as part of the download.
By isolation there is at least a chance to do some form of review/inspection
> That seems a bit excessive to sandbox a command that
> really just downloads arbitrary code you are going to
> execute immediately afterwards anyways?
I don't want to stereotype, but this logic is exactly why javascript supply chain is in the mess its in.
I've tried use pnpm to replace npm in my project, it really speed up when install dependencies on host machine, but much slower in the CI containers, even after config the cache volume. Which makes me come back to npm.
This folk-wisdom scapegoating of post-install scripts needs to stop or people are going to get really hurt by the false sense of security it's creating. I can see the reasoning behind this, I really do, it sounds convincing but it's only half the story.
If you want to protect your machine from malicious dependencies you must run everything in a sandbox all the time, not just during the installation phase. If you follow that advice then disabling post-install scripts is pointless.
The supply chain world is getting more dangerous by the minute and it feels like I'm watching a train derail in slow motion with more and more people buying into the idea that they're safe if they just disable post-install scripts. It's all going to blow up in our collective faces sooner or later.
You're right, it's not just about post-install scripts nor NPM and JavaScript. This is a deep fundamental issue in software development practices across most programming language ecosystems. And not only open-source, since proprietary code is often even worse about vetting dependencies. More eyes are better, therefore open source (or source available) is a prerequisite for security.
Improving NPM's processes, having more companies auditing packages, changing the way NPM the tool works - that's all good but far from enough, it doesn't actually address the root vulnerability, which is that we're way too comfortable running other people's arbitrary code.
Containerization and strict permissions system by default seem to be where we're headed.
Exactly for JS code, run all inside the container, all the time.
I have been doing it for weeks now with no issues.
There are so many vectors for this attack to piggyback off from.
If I had malicious intentions, I would probably typo squat popular plugins/lsps that will execute code automatically when their editor runs. A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via a docker command.
> A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via a docker command.
Running `npm` inside Docker does not solve this problem. However, running `npm` inside Docker does not make this problem worse either.
That's why I said running `npm` inside Docker reduces the attack surface of the malicious NPM packages.
I think this approach is harmful because it gives people a false sense of security and makes them complacent by making them feel like they're "doing something about it even if it's not perfect". It's like putting on 5 different sets of locks and bolts on your front door while leaving the back door unlocked and wide open during the night.
Done is better than perfect, and a 100% secure system doesn't exist. Given how prolific those supply-chain attacks are, any mitigation (even if imperfect) seems to be good step toward protecting yourself and your assets
This isn't just "imperfect", it's so deeply flawed that the next minor "mutation" of supply chain attack tactics is guaranteed to wipe you out if you rely on it. It's just a matter of time, it could be tomorrow, next month, maybe a year from now.
Setting up a fully containerized development environment doesn't take a lot of effort and will provide the benefits you think you're getting here - that would be the "imperfect but good enough for the moment" kind of solution, this is just security theater.
Every time I make this point someone wants to have the "imperfect but better than nothing" conversation and I think that shows just how dangerous the situation is becoming. You can only say that in good conscience if you follow it up with "better than nothing ... until I figure out how to containerize my environment over the weekend"
Unfortunately, the current way of how things work is, like you said, "deeply flawed". You will not change it in a few months, not even in a few years too.
What you can do, however, is to adapt to current threats, the same way adversaries adapt to countermeasures. Fully secure setups do not exist, and even if one existed, it would probably become obsolete very quickly. Like James Mickens said, whatever you do, you still can be "Mossad'ed upon". Should we give up implementing security measures then?
Thinking about security in a binary fashion and gatekeeping it ("this is not enough, this is will not protect you against X and Y") is, _in my opinion_, very detrimental.
Sorry, what I'm proposing here is far from binary but yes, I am gatekeeping the bare minimum. It has to be gatekept otherwise I'm afraid we'll enter a state of mass industry delusion where everyone thinks they're safe, "doing something", even "following industry best practices", but in reality all we're doing is: [1]
If a supply chain attack would be a serious incident for you then you need to take meaningful actions to protect yourself. I'm trying to hold "you" (proponents of this idea) accountable because I don't want you to rationalize all of these actions that leave you wide open to future attacks in known, preventable ways and then pretend nobody could've seen this coming when it blows up in our face.
It's not "good enough" - it's negligence because you know that the hole is there, you know that the hackers know about it, you know how trivial it is to exploit, and yet we're arguing whether leaving this known vector open is "good enough" instead of taking the obvious next step.
Containers are very far away from "fully secure" setup, they suffer from escape vulnerabilities far more often than VMs, but their benefit is that they're lightweight and minimally obtrusive (especially for web development) and these days the integration with IDEs is so good you probably won't even notice the difference after a few days of adjusting to the new workflow.
You end up trading a bit of convenience for a lot of security - you're going to be reasonably well protected for the foreseeable future because the likelihood of someone pulling off a supply chain attack and burning a container escape 0-day on it is really low.
That should be good enough for most and if your developer machine needs more protection than this, I'll take a guess and say that your production security requirements are such that they require security review of all your dependencies before using them anyway.
With a VM you would get even more security but you would have to sacrifice a lot more convenience, so given the resistance to the less intrusive option this isn't even worth discussing right now.
How can you not see the nuance?
[1] https://i.imgur.com/Zj6rwEK.jpeg
> alias npm=...
I use sandbox-run: https://github.com/sandbox-utils/sandbox-run
The above simple alias may work for node/npm, but it doesn't generalize to many other programs available on the local system, with resources that would need to be mounted into the container ...
> The above simple alias may work for node/npm, but it doesn't generalize for many other programs that are available on the local system, with resources that would somehow have to get mounted into the container ...
Thanks. You are right, running inside Docker won't always work for local commands. But I am not even using local commands.
Infact, I have removed `yarn`, `npm`, and several similar tools already from my machine.
It is best to run them inside Docker.
> I use sandbox-run: https://github.com/sandbox-utils/sandbox-run
How does this work if my local command is a Mac OS binary? How will it run inside Docker container?
Or use ‘chroot’. Or run it as a restricted owner with ‘chown’. Your grandparents solutions to these problems still work.
That'll still allow access to env vars, and interact with other processes owned by the same user.
At the very least, you really need to add process isolation / namespacing as well - at which point it's going to be easier to just use the sandboxing / containerisation tool of your choice to manage it all for you.
Not sure how secure this really is, because it's fairly easy to break out of a Docker container with the default settings (due to the fact that the kernel is shared between containers and the host, unlike with VMs). Rootless Docker (or better, Podman) would improve security greatly.
Can you show an example of how can a malicious package break out of docker?
There have been quite a few exploits over the years, with the most recent public CVE 2 years ago [1].
Your specific setup uses `--net=host` and this opens you up to potential vulnerabilities (see [2]).
You also shouldn't forget that containers have unrestricted network access bu default anyway. Even if your device is safe, they may be able to infect other vulnerable devices on your network.
[1]: https://docs.docker.com/security/security-announcements/#doc... [2]: https://github.com/0xn3va/cheat-sheets/blob/main/Container/E...
[dead]
That definitely helps and worth doing. On Mac though I guess you need to move the entire development to containers due to native dependencies.
My primary dev environment is containers, but you can do a hell of a lot with nix on a mac.
Won't that still download malicious packages that are dep?
Yeah but those deps won't access your browser cookies and tour secret keys that are outside the current directory.
Doesn't Docker run as `root` by default, and alter the permission of your folder by taking ownership and making it as `root:root` ?
Just tested it and apparently it's not the case, neat!
This will break native dependencies when the host platform is not the same as the container platform.
My host is Mac OS. My container platform is Linux. Can you share an example where this approach will cause a failure?
You should probably put some quotes around `$PWD`:
...Does this always work? I don't use much JS. Doesn't NPM sometimes build against system libs, which could be different in the container?> You should probably put some quotes around `$PWD`:
Yeah, fair point.
> Doesn't NPM sometimes build against system libs, which could be different in the container?
Yes, and I run all JS inside a container.
> triple-backtick code blocks
If only :(
I always wondered why people found it acceptable to just run npm on their systems for anything they do, and have it download anything on any build.
Coming from "make" with repeatable and predictable builds, I was appalled that you run this thing and you have no idea what it will download and what it will produce. Could be something different the next time you run it! Who knows!
I also found it bizarre that even for things that just generate CSS, you are expected to integrate it into your npm thing. I mean, generating CSS from a configuration is a function. It's a make recipe. Why does it need to be an npm library dependency with all the associated mess? I managed to work around it for a number of packages by freezing entire npm setups inside docker containers, which gave me reproducible builds — but it's a losing battle.
> entire npm setups inside docker containers
Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade?
Also both NPM and PNPM already freeze dependencies for you by default without any arcane docker setups.
> Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade?
TBH, I never updated some of the setups. What's the point? Their job was to generate a CSS. Why would I want to upgrade dependencies or inspect that setup?
> arcane docker setups
I take issue with "arcane" — I have much more "arcane" setups than these :-)
makefiles /can/ do whatever you like. They can download anything on build.
Downloading things that you don't know about its common for every modern package manager out there, from maven, to nuget, to pip and npm. This is the new norm and there are reasons for it.
I don't think the old C/C++ way of relying on distro package managers would allow for the fast ecosystems people work nowadays.
Things are changing though, and people are pushing for more secure package managers with the same feature set as the old ones, which is possible.
I think this is the missing piece on the first wondering part of your comment. But I don't think we should be bashing the means without understanding the reasons
> freezing entire npm setups inside docker containers, which gave me reproducible builds
How does that work when enevitably those npm packages are shown to have vulnerabilites?
'Npm install thing' is easier than programming or even auditing imported code.
Too lazy to write, too cheap to pay for it, that's half of open source.
Now what's going to dominate stackoverflow answers, thoughtful articles on how to program? Or gratis npm/uv installable libraries that hide the actual solution details in between tests and polyfills and readmes, that end up just download another dependency while contributing enough lines of code so that the author can safely put it in their resume and grift over the oss ecosystem to get a cushy 300k/yr job at an extended faang where they are in charge of an ad pixel tracker or yet another one of those wallet things that are just an IO proxy for money but they get to keep some comission if they spend enough money on ads to convince someone to use the thing once and then it becomes their main neo(not) bank* forever.
*for regulatory reasons we must not call it a bank, but it's a bank
The entire Front end dev seems like trust me bro Wild West to me. All feels like endless layers of duct tape. Which I guess in a way it is given the evolution of browsers
This is true for every moser package manager out there: pip, cargo, gradle and the lot. It is not about front end dev
it seems a lot worse with NPM for some reason, but the underlying weaknesses apply to language package managers in general too.
I think it is worse with npm because there are more people using it and more people know about it.
Lowering the barrier to entry is not paying off, for sure.
I think part of the reason is the embrace of an "each package should do exactly one thing" by many in the community, often taken to a ridiculous extreme. Possibly better now after left-pad and other similar incidents.
I've seen gnarly code everywhere, from kernel drivers to desktop applications to web apps. At the end of the day this describes most of computing imho.
>When you run npm install, npm doesn't just download packages. It executes code. Specifically, it runs lifecycle scripts defined in package.json - preinstall, install, and postinstall hooks.
What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer?
Quote is from the researchers report https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-i...
edit: I was thinking of this other case that spawned terminals, but the question stands: https://socket.dev/blog/10-npm-typosquatted-packages-deploy-...
> What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer?
The paradigm itself has been in package managers since DEB and RPM were invented (maybe even Solaris packages before that? it's been a minute since I've Sun'd); it's not the same as NPM, a more direct comparison is the Arch Linux AUR - and the AUR has been attacked to try and inject malware all year (2025) just like NPM. As of the 26th (5 days ago) uploads are disabled as they get DDOSed again. https://status.archlinux.org/ (spirit: it's the design being attacked, pain shared between AUR and NPM as completely disparate projects).
More directly to an example: the Linux kernel package. Every Linux distribution I'm aware of runs a kernel package post-install script which runs arbitrary (sic) commands on your system. This is, of course, to rebuild any DKMS modules, build a new initrd / initramfs, update GRUB bootloader entries, etc. These actions are unique outputs to the destination system and can't be packaged.
I have no data in front of me, but I'd speculate 70% (?) of DEB/RPM/PKG packages include pre / post install/uninstall scriptlets, it's very common in the space and you see it everywhere in use.
Right every library will want to run ldconfig for example.
Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago they ended up adding downloadable builds for the most common platforms, but for anything else the expectation still was (and is, I guess) to build sources at install time.
Believe such build tools and processes should be run inside a container environment. Maybe once all OS have native, cheap and lean containers and permit dead simple container execution of scripts, this will be possible.
Google's OS, Android, has sandboxes. It's some Linux problem that they do not want to backport it.
It just has Linux user IDs. They're in every Linux.
I think that was long time ago, because this doesn't allow to request permissions in runtime.
Permissions are not granted through Linux itself. Permissions are something checked by separate processes when you connect with those processes.
how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?
People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done." I hope we can get to a world where such hooks are no longer required one day.
yes that's why npm is for them. I'd rather download the libraries that I need one by one.
But most users would do that without inspecting it at all, and a fair number would prefix it with “sudo” out of habit.
But that’s at least a conscious and explicit action the user chooses to make and is explicitly aware of making.
That's fine, and it's still better than doing it on install.
you can always add --am-an-idiot as a switch to npm install.
[dead]
Hard. In npm land you install React and 900 other dependencies come with it. And how ok are you reviewing every single one of those scripts and manually running them? Not that it is good that this happens but realistically most people would just say “run all” and let it run instead of running each lifecycle script by hand.
My solution is to bypass React entirely. I'd much rather have a smaller, possibly less functional or pretty front end than to have to worry about this stuff continuously. I would not get any work done. There is no way I'm going to take on board 900 dependencies which I will then inflict on the visitors to my website.
the only way I'd use react in a project is to download the react.js build. I don't see why people want to download 900 dependencies.
I am people and I don’t want to download 900 dependencies. But if I want to use React or Vue or anything but the most trivial JS libraries or frameworks I am held hostage by the fact that their dependencies have dependencies.
Surely there are ways to just stick to absolute basics and you can get quite far with what is built in or some very small libraries, but I guess it depends on where you would be most productive.
rpm and dpkg both provide mechanisms to run scripts on user machines (usually used to configure users and groups on the user machine), so this aspect is not an NPM-specific. Rust has the same thing with build.rs (which is necessary to find shared C libraries for crates that link with them) so there is a legitimate need for this that would be hard to eliminate.
Personally, I think the issue is that it is too easy to create packages that people can then pull too easily. rpm and dpkg are annoying to write for most people and require some kind of (at least cursory) review before they can be installed on user's systems from the default repos. Both of these act as barriers against the kinds of lazy attacks we've seen in the past few months. Of course, no language package registry has the bandwidth to do that work, so Wild West it is!
rpm and dpkg generally install packages from established repos that vet maintainers. It's not much but having to get one or two other established package authors to vouch for you and having to have some community involvement before you can publish to distro repos is something.
I agree, that is what I talk about in the second paragraph! ;)
You see, when you treat everything as a "product", this is what you end up with.
Running a C compiler on everyone's machines to avoid a bit of work is extremely dumb.
Modern internet is build on premise of repeatedly running megabytes of javascript on everyone's machines to avoid a bit of work.
There's nothing inherently wrong with that. The problem is npm allows any random person to upload packages. It's completely untrusted. Contrast that with Linux distributions which have actual maintainers who take responsibility for their packages. They don't generally allow malware to make it into the official software repositories. In many cases they went as far as meeting each other in person just to set up a decentralized root of trust with PGP. It's so much better and more trustworthy.
The truth is npm, pip, rubygems, cargo and all the other programming language package managers are just fancier versions of the silly installation instructions you often find in README files that tell people to curl some script and pipe it into bash.
Even when random people are allowed to contribute (AUR, PPAs) there seems to be more scrutiny and fewer incidents. Possibly because they are secondary to the main repos and possibly because the people who use them are made aware of the risks.
NPM etc. are a bit like Arch would be if everything was in AUR.
With PPAs or COPR (or third party repositories, e.g. slack) you have to explicitly enable each repository too. Even if a repository is enabled by package you are prompted the first time a new repository is used (actually I don't know if that's true when gpgcheck is disabled? If not this would be an easy fix in apt/dnf)
pnpm v10 disables all lifecycle scripts by default and requires the user to whitelist packages.
https://github.com/orgs/pnpm/discussions/8945
It’s just security theater in the end. You can just as easily put all that stuff in the package files since a package is installed to run code. You have that code then do all the sketchy stuff.
What’s needed is an entitlements system so a package you install doesn’t do runtime stuff like install crypto mining software. Even then…
A package, especially a javascript package, is not necessarily installed to run code, at least not on the machine installing the package. Many packages will only be run in the browser, which is already a fairly safe environment compared to running directly on the machine like lifecycle scripts would.
So preventing lifecycle scripts certainly limits the number of packages that could be exploited to get access to the installing machine. It's common for javascript apps to have hundreds of dependencies, but only a handful of them will ever actually run as code on the machine that installed them.
True… I do a lot of server or universal code. But don’t trust browser code either. Could be connecting to MetaMask and stealing crypto, running mining software, or injecting ads.
And with node you get files and the ability run arbitrary code on arbitrary processes.
I would expect to be able to download a package and then inspect the code before I decide to import/run any of the package files. But npm by default will run arbitrary code in the package before developers have a chance to inspect it, which can be very surprising and dangerous.
npm used to do that. bun never did. No idea about the past for pnpm or yarn.
PHP composer does the same, in config.allow-plugins.<package> in composer.json. The default behavior is to prompt, with an "always" option to add the entry to composer.json. It's baffling that npm and yarn just let the scripts run with nary a peep.
One of the many reasons there is no good reason to use npm; pnpm is better in every way.
Bun also doesn't execute lifestyle scripts by default, except for a customizable whitelist of trusted dependencies:
https://bun.com/docs/guides/install/trusted
"Trusted" dependencies are poor solution, the good solution is either never run scripts, or run them inside qemu.
Finally sane solution. When I was thinking about package manager design, I also thought that there should be no scripts, the package manager should just download files and that's all.
Also, you can now pin versions in that whitelist
Swift Package Manager[0] executes a Swift script. The Package.swift file[1] (the manifest) is actually an executed source file.
I assume that it's heavily sandboxed, though, so it may be difficult to leverage.
[0] https://docs.swift.org/swiftpm/documentation/packagemanagerd...
[1] https://developer.apple.com/documentation/packagedescription
> doesn't just download packages. It executes code. Specifically, it
It pains me to remember that the reason LLMs write like this is because many humans did in the training data.
That whole koi blog post is sloppy AI garbage, even if it's accurate. So obnoxious.
Is the objection the small sentence that could have been a clause?
The objection is to the redundant, flowery prose overall, and the overall inaccuracy. (Of course the installer "doesn't just download packages"; installation at minimum would also involve unpacking the archive and putting the files in the right place....)
In about as much text, we could explain far better why and how NPM's behaviour is risky:
> When you install a package using `npm install`, NPM may also run arbitrary code from the package, from multiple hook scripts specified in `package.json`, before you can even audit the code.
OK but have you seen how many projects' official installation instructions are some form of curl | bash?
Both post-install scripts and curl|bash scripts are just scapegoats of supply chain security with similar faulty reasoning.
In most cases to use a library you just need to download files and place them into a directory.
I seem to recall Husky at one point using lifecycle hooks to install the git hooks configured in your repository when running NPM install.
Playwright does it too. Or at least, I’ve worked a place that used npm install hooks to setup husky and install playwright browser binaries
One use case is downloading of binaries. For example mongo-memory-server [0] will download the mongoDB binary after you have installed it.
[0] https://www.npmjs.com/package/mongodb-memory-server
why would i want that though, compared to downloading that binary in the install download?
the npm version is decoupled from the binary version, when i want them locked together
I think it falls into a few buckets:
A) maintainers don’t know any better and connect things with string and gum until it most works and ship it
B) people who are smart, but naive and think it will be different this time
C) package manager creators who think they’re creating something that hasn’t been done before, don’t look at prior art or failures, and fall into all of the same holes literally every other package manager has fallen into and will continue to fall into because no one in this industry learns anything.
And now optional dependencies negate the need for this. Your package manager can just download platform-specific binaries automatically https://docs.npmjs.com/cli/v7/configuring-npm/package-json#o...
Many front end tools are written in a faster language. For example, the next version of TypeScript compiler, SASS, SWC (minifier), esbuild (bundler used by Vite), Biome (formatter and linter), Oxc (linter, formatter and minifier), Turbopack (bundler), dprint (formatter), etc.
They use proinstall script to fetch pre-built binaries, or compile from source if your environment isn't directly supported.
Notable times this has bitten me include compiling image compression tools for gulp and older versions of sass, oh and a memorable one with openssl. Downloading a npm package should ideally not also require messing around with c compilation tools.
There is the "--ignore-scripts" option and had no issue using it for now.
I feel super uneasy developing Software with Angular, Vue or any framework using npm. The amount of dependencies these frameworks take is absolutely staggering. And just by looking at the dependency tree and thousands of packages in my node_modules folder, it is a disaster waiting to happen. You are basically one phishing attack on a poor open source developer away from getting compromised.
To me the entire JavaScript ecosystem is broken. And a typo in your “npm -i” is sufficient to open up yourself for a supply-chain attack. Could the same happen with NuGet or Maven? Sure!
But at least in these languages and environments I have a huge Standard Library and very few dependencies to take. It makes me feel much more in control.
Deno solves this, it's not a JavaScript Issue, it's a Node.JS / NPM issue.
How does Deno solve this? Genuine question by the way. I'm not trying to be snarky.
It provides a runtime, that sandboxes your application and requires you to give explicit permissions for file system operations and network requests.
This limits the attack surface, when it comes to installing malicious dependencies, that npm happily installs for you.
So yes, I was wrong and my previous comment a hyperbole. A big problem is npm, and not JavaScript.
My point about the staggering amount of dependencies still holds though.
Of course, this only works so long as the sandbox is secure.
There have been attempts to do this kind of sandboxing before. Java and .NET both used to have it. Both dropped it because it turns out that properly sandboxing stuff is hard.
Go kinda solves this by using repo links instead of package names. This forces you to go through the repo and copy paste the url (instead of manually typing it out), but it's not bulletproof I guess.
Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else.
When I build backend in flask or Django, I specifically type the python packages that I need. But front end development seems like a Pandora box of vulnerabilities
All package ecosystems that allow unvetted code being published are affected, it just happens that npm is by far the most popular one, so it gets all the news.
It's no different anywhere else. I just downloaded jj (rust), it installed 470+ packages
When I downloaded wan2gp (python) it installed it install 211 packages.
Oh man you pick the one other language that followed the JavaScript model?! How about C, Java, Go, Lisp, C#, C++, D… and new ones like Odin that are explicitly against package managers for this very reason.
When you start writing with C, where do you get your stdio.h file? Do you write it yourself, or inspect it line by line every time or do you trust the installation package you just ran?
Your OS. glibc / musl.
Exactly, you are trusting an OS or library which could very much be maliciously interfered with.
I would be willing to bet attacks on linux upstream libraries are already happening in the same way as the js ecosystem.
Hm... if you use something like Debian it's quite difficult to get your package installed in the distro. People do review everything that goes in. I find it incredibly silly to compare something like that to npm, where every kid has dozens of packages installed that anyone using npm can end up downloading and no one is really reviewing anything.
I agree one is more difficult than the other, but I feel the principal is the same. Whilst anything is built using other modules, there is always risk those modules will be compromised.
What makes you think that this is the case?
And yeah I'm trusting my OS (Linux) and the libraries that is in their repository.
We could go deeper than that. What about hardware? None of it is open source.
Where does it end? What can we do about it?
This is why Huwawei equipment was disallowed to be part of Western Europes 5g rollout.
https://www.euronews.com/next/2024/08/12/eleven-eu-countries...
What can we do about it indeed!? I guess its either fully digitally detox or accept the fact that if you use modern technology then somebody is watyching what you do.
[dead]
> It's no different anywhere else.
But it is. Both C/C++ and Go are not at all like this.
I don’t know about Python but Rust ecosystem tends attract enthusiasts who make good single purpose packages but that are abandoned because maintainers move on, or sometimes forked due to minor disagreements similar to how Linux/unix is fragmented with tribal feuds.
All languages use libraries that come from somewhere.
Even your OS upstream packages could be tainted at this point.
Go is like this...
M'yea, good luck finding such occurrence with NuGet or Maven for example. I would rephrase your "anywhere else".
NPM is a terrible ecosystem, and trying to defend its current state is a lost cause. The energy should be focused on how to fix that ecosystem instead of playing dumb telling people "it's all ok, look at other, also poorly designed, systems".
Don't forget that Rust's Cargo got heavily inspired by NPM, which is not something to brag about.[0]
> "Rust has absolutely stunning dependency management," one engineer enthused, noting that Rust's strategy took inspiration from npm's.
[0]https://rust-lang.org/static/pdfs/Rust-npm-Whitepaper.pdf
[dead]
One of the biggest things that pushes me away from Rust is the reliance on micro dependencies. It's a terrible model.
What's wrong with micro dependencies? Isn't it better to download only the code you need? Also it makes refactoring easier, and enforces better architecture.
Larger attack surface - you just need one of those N dependencies to fall for a spear phishing attack and you're cooked. Larger N is necessarily worse.
It depends on the software being written, but if it's a product your business sells or otherwise has an essential dependency on, then the best model available right now is vendoring dependencies.
You still get all the benefits of standing on top of libraries and frameworks of choice, but you've introduced a single point of entry for externally authored code - there are many ways you can leverage that to good effect (vuln scans, licence audits, adding patch overlays etc etc) and you improved the developer experience - when they check out the code, ALL of the code to build and run the project is already present, no separate npm install step.
You can take this model quite a bit further and buy some really useful capabilities for a development team, like dependency upgrades because they're a very deliberate thing now, you can treat them like any other PR to your code base - you can review the changes of each upgrade easily.
There's challenges too - maybe your npm dep builds a native binary as part of it, you now need to provide that build infra / tooling, and very likely you also want robust build artifact and test caching to save wasting lots of time.
Is this bait? The whole context is malicious software being installed en masse via NPM micro dependencies.
Dependency management is work. And almost nobody does this work seriously because it has become unrealistic to do, which is the big concern here.
You now have to audit the hundreds of dependencies. Each time you upgrade them.
Rust is compiled and source code doesn't weigh that much, you could have the compiler remove dead code.
And sometimes it's just better to review and then copy paste small utility functions once.
> Rust is compiled and source code doesn't weigh that much, you could have the compiler remove dead code.
I get the impression that one driver to make microdependencies in rust is that code does weigh a lot because the rust compiler is so slow.
For a language with a focus on safety, it's a pretty bad choice
They should just be part of the stdlib of the language.
Rust has a really big and comprehensive stdlib, especially compared to languages like C or JavaScript. It just decided that certain things won't be solved in the standard lib because there is no obviously-right solution and evolving towards a good solution is much easier in packages than in the stdlib, because the stdlib isn't versioned.
Some of the gaps feel huge, like no random, no time/date handling, and no async runtime. But but for most of them there are canonical packages that 95% of the ecosystem uses, with a huge amount of eyeballs on them. And sometimes a better solution does emerge, like jiff slowly replacing chrono and time for time/date handling.
Obviously this isn't the best solution from a security perspective. There would be less potential for supply chain attacks if everything was in the standard library. But that has to be weighed against the long-term usability of the language
No, I'd much rather a trusted source, like the language developers themselves, provide as much as possible.
And those last two points have absolutely nothing to do with micro dependencies one way or the other.
https://thecodelesscode.com/case/119
I come from a JavaScript background, and I've got to admit that the ecosystem is designed in a way that is really prone to attack.
It is like the xz incident, except that each dependency you pull is maintained by a random guy on the internet. You have to trust every one of them to be genuine and that they won't fall into any social engineering attacks.
Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.
Definitely, and you should be aware of the risk and think about and assess your dependencies.
Having a large standard library does reduce the number of dependencies, and you can go a long way using only well known dependencies.
No language ecosystem is but NPM/Node still encourages this idea (borrowed elsewhere and interpreted poorly) that everything must be its own tiny package and that it's acceptable to author libraries consisting of thousands of transitive dependencies from potentially dubious sources. Just this week I saw one (unmaintained dependency of a popular package) which consisted of a list of a dozen SQL operators. Anywhere else you would just write the damn code, maybe add a comment that these are the SQL-92 operators and be done with it literally forever. But in Node land that would be viewed as an antipattern which only another package can fix. It's a security and maintenance nightmare that can only be explained by laziness and outright stupidity.
It's a misconception that NPM or Node encourage this, because they don't. There are a few package authors that are doing it that way (some even paid by download count), but that's their opinion.
Recently there is a trend towards minimal-dependency packages and I would certainly recommend auditing every package for its dependencies before using it.
Here's my black pill: Node in general is not safe.
The blurring of the client-server lines is a security risk. Very easy to expose the wrong thing; the language appeals to people who know 1 language (which correlates with lack of experience).
In my personal experience node projects developed under my supervision had very basic client-server boundary vulns 66.67% of the time. Empirically it's not great.
> As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else.
Oh, absolutely, there is no question about it. Fewer dependencies means less headache; and if you can get the number of your dependencies to zero, then you have won the internet.
Sounds like... C.
this is one of the less talked about benefits of using bun
How does Bun avoid this? Or is it more that Bun provides things that you'd otherwise need a dependency for (eg: websockets)?
From a link mentioned elsewhere in the thread:
> Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts for installed dependencies, such as `postinstall` and `node-gyp` builds. These scripts represent a potential security risk, as they can execute arbitrary code on your machine.
https://bun.com/docs/guides/install/trusted
I've also found the Bun standard library is a nice curated set of features that reduces dependencies.
Hmmm, it still has a pretty extensive default list of permitted npm packages, which wouldn't necessarily be a problem if there were a way to disable it, but I can't seem to find it.
the latter is what i was getting at yeah. updated list of standard library-esque functions implemented in native code so the need to reach to npm for a dependency happens far less often.
Keep in mind that the vast majority of the 86,000 downloads are probably automated downloads by tools looking for malicious code, or other malicious tools pulling every new package version looking for leaked credentials.
When I iterate with new versions of a package that I’ve never promoted anywhere, each version gets hundreds of downloads in the first day or two of being published.
86,000 people did not get pwnd, possibly even zero.
Or it's some poor idiot's CI repeatedly downloading them, and for a zombie project that no one will ever use.
When I published a library it got about 300 downloads a week for the first few and then dropped down to about 100. That would be a lot of weeks.
> Many of the dependencies used names that are known to be “hallucinated” by AI chatbots.
There’s more here than that.
As TFA says, they're targeting package names that are somewhere in LLM training data but don't actually exist, so are being hallucinated by LLMs. And there's now a large number of folks with zero clue busy vibe-coding their killer app with no idea that bad things can happen.
I would not be surprised to find that 80%+ of those 86,000 people got pwned.
As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project.
Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot to infiltrate because I’m not sophisticated enough to stop it.
Where do I start?
> As a hobbyist how do I stay protected and in the loop for breaches like this?
For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe.
The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladder but not nearly as bad as the user-submitted madness outside Linux).
But it seems like your question is about front end web development, and that's not my world and I have no advice beyond sympathy.
> occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot
Pretty much that's the problem exactly. Distributing software is hard. It's a lot of work at a bunch of different levels of the process, and someone needs to commit to doing it. If you aren't willing to commit your time and resources, don't distribute it in a consumable way (obviously you can distribute what you built with it, and if it's appropriately licensed maybe someone else will come along and productize it).
NPM thought they could hack that overhead and do better, but it turns out to have been a moved-too-fast-and-broke-things situation in hindsight.
> PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe.
One obvious further mitigation for Python is to configure your package installer to require pre-built wheels, and inspect the resulting environment prior to use. Of course, wheels can contain all sorts of compiled binary blobs and even the Python code can be obfuscated (or even missing, with just a compiled .pyc file in its place); but at least this way you are protected from arbitrary code running at install time.
Having spent a year trying to develop against dependencies only provided by a debian release, it is really painful in practice. At some point you're going to need something that is not packaged, or newer than the packaged version in your release.
It really depends on what you're doing. But yes, if you want to develop in "The NPM Style" where you suck down tiny things to do little pieces of what you need (and those things suck down tiny things, ad infinitum) then you're naturally exposed to the security risks inherent with depending on an unaudited soup of tiny things.
You don't get secure things for free, you have to pay for that by doing things like "import and audit software yourself" or even "write simple utilities from scratch" on occasion.
That's when you join debian :)
Didn't Debian ship a uniquely weak version of OpenSSL for years? HeartBleed perhaps?
IME Debian is falling behind on security fixes.
They did, and no one is perfect. But Debian is the best.
FWIW, the subject at hand here isn't accidentally introduced security bugs (which affect all software and aren't well treated by auditing and testing). It's deliberately malicious malware appearing as a dependency to legitimate software.
So the use case here isn't Heartbleed, it's something like the xz-utils trojan. I'll give you one guess as to who caught that.
As a hobyist (or profesionally) you can also write code without dependencies outside of node itself.
Somewhat controversial these days, but treat every single dependency as a potential security nightmare, source of bugs, problem that you will have to solve in the future. Use dependencies carefully and as a last resort.
Vendoring dependencies (copying the package code into your project rather than using the package manager to manage it) can help - it won't stop a malicious package, but it will stop a package from turning malicious.
You can also copy the code you need from a dependency into your code (with a comment giving credit and a link to the source package). This is really useful if you just need some of the stuff that the package offers, and also forces you to read and understand the package code; great practice if you're learning.
Inspecting 10 layers of dependencies individually to install a popular tool or an lsp server is going to work once or twice. Eventually either complacency or fatigue sets in and the attacker wins.
I think we need a different solution that fixes the dependency bloat or puts more safeguards around package publishing.
The same goes for any other language with excessive third-party dependency requirements.
Agree.
It's going to take a lot of people getting pwned to change these attitudes though
Why would attitudes change? The impact is diffused across a wide enough populace (precisely because ecosystems with weak community norms around dependency security are extremely popular) that the rate of “shaping up in response to a painful lesson” may remain lower than the rate of newcomers joining the community or the rate of new insecure dependencies proliferating to serve new needs brought about by new use cases brought about by growing popularity of a platform.
That’s not to say it’s hopeless. Rather, it’s more likely that widespread improvement will need to be centrally orchestrated rather than organic in response to hacks.
Local proxies that can work offline also helps. Though not as much as vendoring.
Use dependencies that are fairly popular and pick a release that's at least a year old. Done. If there was something wrong with it, someone would've found it by now. For a hobbyist, that's more than sufficient.
Don't do development on your local machine. Full stop. Just don't.
Do development, all of it, inside VMs or containers, either local or remote.
Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling.
This has the added benefit of not only sandboxing your code, but also making your dev environments repeatable.
If you are using GitHub, use codespaces. If you are using gitlab, workspaces. If you are using neither, check out tools like UTM or Vagrant.
That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.
You are right, if it's a pain no one is going to do it. So the thing that needs to happen is to make it not a pain.
The way to sell it isn't vague security somethings, but in making it easier to reproduce the build environment "from scratch". If you build the Dockerfile as you go, then you don't waste hours at the end trying to figure out what you did to get it to build and run in the first place.
its not particularly painful to develop in a container. Maybe docker is a nuisance (although I know people do do develop within docker) but something like firejail or bubblewrap is pretty easy to use.
It is a realistic solution.
Taking this more seriously than it perhaps deserves: if that’s true, why isn’t widespread adoption of this approach growing?
Whether or not it’s a good idea, “realistic” implies practicality, which could presumably be measured by whether people find it worthwhile to do the thing.
I suppose it depends on what you're protecting, who's out there to get you, and how boring and time consuming it is to clean up after a breach (can't that take weeks or months), etc.
Aren't you're a bit asking "When X transportation method isn't used by everyone, can it really be any good?" :-)
Are people actually using UTM to do local development?
Im genuinely curious because I casually looked into it so that i could work on some hobby stuff over lunch on my work machine.
However I just assumed the performance wouldn't be too great.
Would love to hear how people are setup…
When I had a Macbook from work, I set up an Arch Linux VM using their basic VM image [1], and followed these steps (it may differ, since is quite old): https://www.youtube.com/watch?v=enF3zbyiNZA
Then, I removed the graphical settings, as I was aiming to use SSH instead of emulated TTY that comes ON by default with UTM (at that time).
Finally, I set up some basic scripting to turn the machine on and SSH into it as soon as sshd.service was available, which I don't have now, but the script finished with this:
(fish shell)
Later it evolved in something like this: I also removed some unnecessary services for local development: And done, performance was really good and I could develop on seamlessly.[1]: https://gitlab.archlinux.org/archlinux/arch-boxes/-/packages...
It works incredibly well with Linux VMs, my daily driver. I plug in a USB keyboard, external monitor and Can't Believe It's Not Linux. Only occasionally when I need to use the laptop screen/keyboard does macOS bother me and remind of it real self.
There's around 10-15% performance penalty for VMs (assuming you use arm64 guests), but the whole system is just so much faster and well built than anything Intel-based to day, that it more than compensates.
For Windows, it's lacking accelerated video drivers, but VMWare Fusion is an ok free alternative - I can totally play AAA games from last decade. Enjoy it until broadcom kills it.
I started using UTM last week on my Macbook just to try out NixOS + sway and see if I could make environment that I liked using (inspired by the hype around Omarchy).
Pretty soon I liked using the environment so much that I got my work running on it. And when I change the environment, I can sync it to my other machine.
Though NixOS is particularly magical as a dev environment since you have a record of everything you've done. Every time I mess with postgres hb_conf or nginx or pcap or on my local machine, I think "welp, I'll never remember that I did that".
With remote development (vscode and remote extension in jetbrains with ssh to VM) performance is good with headless VM in UTM. Although it always (?) uses performance cores on Apple Silicon Macs, so battery drain is a problem
I used to have a separate account on my box for doing code for other people, one for myself and another for surfing the web. Since I have an Apple TV hooked up to one of my monitors I don’t have a ton of reasons for hopping credentials between accounts so I think I’ll be going back to at least that.
The fact I use nvm means a global install won’t cross accounts.
[flagged]
There are some operating systems, like FreeBSD, where you use the system’s package manager and not a million language specific package managers.
I still maintain pushing this back to library authors is the right thing to do instead of making this painful for literally millions of end-users. The friction of getting a package accepted into a critical mass of distributions is the point.
Avoid dependencies with less than 1M downloads per week. Prefer dependencies that have zero dependencies like Hono or Zod.
https://npmgraph.js.org/?q=hono
https://npmgraph.js.org/?q=zod
Recently I switched to Bun in part because many dependencies are already included (db driver, s3 client, etc) that you'd need to download with Node or Deno.
(1) Start by not using packages that have stupid dependencies
Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages. Those 2 things, a library that provides some functionality, and a CLI command that lets you use the library from the command line, SHOULD NEVER BE MIXED.
The library should be its own package without the bloat of the command line crap
(2) Choose low dependency packages
Example: commander has no dependencies, minimist now has no dependencies. Some other command line parsers used to have 10-20 dependencies.
(3) Stop using packages when you can do it yourself in 1-2 lines of JS
You don't need a package to copy files. `fs.copyFileSync` will copy a file for. `fs.cpSync` will copy a tree, `child_process.spawn` will spawn a process. You don't need some package to do these things. There's plenty of other examples where you don't need a package.
> Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages.
After your little rant you point out Commander has zero dependencies. So I don’t know what’s up with you.
If the library you’re building has anything with application lifecycle, particularly bootstrapping, then having a CLI with one dependency is quite handy for triage. Most especially for talking someone else through triage when for instance I was out and there was a production issue.
Which is why half the modules I worked on at my last place ended up with a CLI. They are, as a rule, read mostly. Which generally doesn’t require an all caps warning.
Does every module need one of those? No. But if your module is meant as a devDependency, odds are good it might. And if it’s bootstrapping code, then it might as well.
> should have it's dev shamed
Oh I feel embarrassed right now. But not for me.
Running things in containers and VMs reduces the damage. One service on your homelab being compromised is a lot better than your entire homelab server getting compromised.
Neither is a security guarantee, but it does add a substantial extra barrier.
I'm not sure about NPM specifically, but in general: Pick a specific version and have your build system verify the known good checksum for that version. Give new packages at least 4 weeks before using them, and look at the git commits of the project, especially for lesser-known packages.
If you're on Linux, I've tried to build an easy yet secure way to isolate your system from your coding projects with containers. See https://github.com/evertheylen/probox
As 'numbsafari said below, you should no longer user your host for dev..this includes all those cool AI assistant tools. You need to containerize all the things with runpod or docker
shamless plug but here's a list of things you could follow to mitigate risks from npm: https://github.com/bodadotsh/npm-security-best-practices
Alternate article with more detailed description of exploit: https://www.bleepingcomputer.com/news/security/phantomraven-...
Because these are fetching dependencies in the lifecycle hooks, even if they are legitimate at the moment there is no guarantee that it will stay that way. The owner of those dependencies could get compromised, or themselves be malicious, or be the package owner waiting to flip the switch to make existing versions become malicious. It's hard to see how the lifecycle hooks on install can stay in their current form.
"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
Cybersecurity professionals are police officers and detectives first, technologists second. They are supposed to catch criminals who abuse technology. I find it distasteful to blame a tool and an entire community for things that criminals are responsible for.
There is nothing about Go, or Cargo, or Nuget, or any of the other systems that prevents criminals from committing crimes. Some cleverness can slow them down, or block certain roads to exploiting these systems, but managing risk in a supply chain is essential no matter which technology ecosystem is used.
Let's stop name-calling and throwing shade at specific tools and communities and get better at educating new-comers to the trade, and shaming and ostracizing the cyber-criminals who are causing the problems.
Just this year Microsoft removed 300 NuGet packages by mistake as they were trying to automate defenses. They got pretty bad press after that so you will get bad comments one way or the other.
NPM ecosystem is very open it is not a bug it is a feature. There are of course issues from being open but NPM already has a lot of security features in place.
This has been going on for years now.
I have used Node, I would not go near the NPM auto install Spyware service.
How is it possible that people keep this service going, when it has been compromised so regularly?
How's it possible that people keep using it?
> Many of the dependencies used names that are known to be “hallucinated” by AI chatbots. Developers frequently query these bots for the names of dependencies they need. LLM developers and researchers have yet to understand the precise cause of hallucinations or how to build models that don’t make mistakes. After discovering hallucinated dependency names, PhantomRaven uses them in the malicious packages downloaded from their site.
I found it very interesting that they used common AI hallucinated package names.
Happy I keep a mirror of my deps, that I have to "manually" update. But also, the download numbers are not really accurate for actual install count - for example each test run could increment.
I wonder what could one do if he wants to use NPM for programming with a very popular framework (like Angular or Vue) and stay safe. Is just picking a not very recent version of the top level framework (Angular, etc.) enough? Is it possible to somehow isolate NPM so the code it runs, like those postinstall hooks, doesn't mess with your system, while at the same time allowing you to use it normally?
One option to make it a little safer is to add ignore-scripts=true to a .npmrc file in your project root. Lifestyle scripts then won't run automatically. It's not as nice as Pnpm or Bun, though, since this also prevents your own postinstall scripts from running (not just those of dependencies), and there's no way to whitelist trusted packages.
The npm ecosystem's approach to supply chain security is criminally negligent. For the critical infrastructure that underpins the largest attack surface on the Internet you would think that this stuff would be priority zero. But nope, it's failing in ways that are predictable and were indeed predicted years ago. I'm not closely involved enough with the npm community to suggest what the next steps should be but something has to change, and soon.
Is there a way to detect/filter dependencies that use HTTP URLs as dependency specifiers as part of an NPM install? Since you can send specific requesters different payloads, I can see how this would bypass most of the normal scanning tools.
Is the solution to this problem Golang style package management where you specify the git repo?
probably no:
https://github.com/evilsocket/opensnitch/discussions/1290
that malware campaign is still active.
Any string can be typosquatted unfortunately.
Even worse, LLM hallucinations can be squatted to the same effect.
I am surprised that anyone in this year runs scripts from random people from Github without sandboxing. As a wise proverb says, a peasant won't cross himself until the thunder bursts out. Spend a couple hours setting up a sandbox and be safer.
This ultimately needs to get addressed at the OS level. Why is a random JS file on disk allowed to read my browser cookies without my awareness? Why is a native extension downloaded from S3? This goes across all package managers (npm, pypi, cargo).
I think security controls on macOS have been trending in the right direction to tackle these types of things comprehensively with secure domains, sandboxing, etc. but there is always a war of how much friction is too much when it comes to security.
We saw the same thing with 2SV where people were vehemently against it, and now many are clamoring that it should be the only way to be able to do things like publish packages (I agree! I have no issue jumping through some extra hoops when I publish something a million people will install).
This might be a hot take but I think a lot of loud mouths with their personal preferences have been holding security in this space back for a while, and recently people seem to be getting tired of it and pushing through. The engineering leadership that won't just make these types of high impact security decisions because it might irritate a handful of highly opinionated workflows is unfortunate!
Whats to stop OS builds from being infiltrated either upstream or in build tooling?
Really good internal security practices by the people who make the OS :) I don't think an attacker would be able to pull off disabling features like secure domains, secure enclave, etc. in macOS without anyone noticing seeing as it takes months of approvals, testing, etc. for a single build to even hit the beta channel.
"No way to prevent this" - Only ecosystem where this consistently happens.
Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that have been admitted to the depository, and you never just eagerly fetch other versions that purport to be updates right before build time. If there is an update, you can download a copy and admit it to your repo at the normal time that you verify that your program actually needs the update. Even if it sounds far-fetched, I imagine we could get by with a system like this.
You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.
No. I am literally describing bog standard use of an ordinary VCS/SCM where the code for e.g. Skia, sqlite, libpng, etc. is placed in a "third-party/" subdirectory. Except I'm deliberately using the words "admit" and "depository" here instead of "commit" and "repository" in keeping with the theme—of the widespread failure of people to use SCMs to manage the corresponding source code required to build their product/project.
Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed not just folks' ability to conceive of just using an SCM like Git or Mercurial to manage source the way that they're made for without introducing a second, half-assed, "registry"-dependent VCS into the mix, but also destroyed the ability to recognize when a comment on the subject is dripping in the most obvious, easily detectable irony.
Yeah, people invented the concept of packages and package management because they couldn’t conceive of vendoring (which is weird considering basically all package managers make use of it themselves) and surely not because package management has actual benefits.
Maybe in a perfect world, we’d all use a better VCS whose equivalent of submodules actually could do that job. We are not in that world yet.
Do you understand the reasons, and are you able to clearly articulate them? Are you able to describe the tangible benefits in the form of a set of falsifiable claims—without resorting to hand-waving or appeals to the perceived status quo or scoffing as if the reasons are self-evident and not in question or subject to scrutiny?
This is exactly what Swift Package Manager does. No drama in the Swift Package world AFAIK.
Does the lockfile not solve this?
not really, because you can't easily see what changed when you get a new version. When you check in the third_party repo to your VSC, then when you get a new version, everything that changed is easily visible `git diff` before you commit the new changes. With a lockfile, the only diff is the hash changed.
Not if you use git submodules, which is how most people would end up using such a scheme in practice (and the handful of people that do this have ended up using submodules).
Go-style vendoring does dump everything into a directory but that has other downsides. I also question how effectively you can audit dependencies this way -- C developers don't have to do this unless there's a problem they're debugging, and at least for C it is maybe a tractible problem to audit your entire dependency graph for every release (of which there are relatively few).
Unfortunately IMHO the core issue is that making the packaging and shipping of libraries easy necessarily leads to an explosion of libraries with no mechanism to review them -- you cannot solve the latter without sacrificing the former. There were some attempts to crowd-source auditing as plugins for these package managers but none of them bore fruit AFAIK (there is cargo-audit but that only solves one part of the puzzle -- there really needs to be a way to mark packages as "probably trustworthy" and "really untrustworthy" based on ratings in a hard-to-gamify way).
The problem is that not enough people care about reviewing dependencies’ code. Adding what they consider noise to the diff doesn’t help much (especially if what you end up diffing is actually build output).
What is "this"?
this = deps getting updated when you don't want or don't expect them to
Huh? "Just use git" is kind of nonsensical in the context of this discussion.
Oh, okay.
Now you have the opposite problem, where a vulnerability could be found in one of your dependencies but you don't get the fix until the next "normal time that you verify that your program actually needs the update".
If a security issue is found that creates the "normal time".
That is, when a security issue is found, regardless of supply chain tooling one would update.
That there is a little cache/mirror thing in the middle is of little consequence in that case.
And for all other cases the blessed versions in your mirror are better even if not latest.
This is how most software used to work before internet package managers, and it turns out that the same people who aren't good at checking their dependencies before automatically upgrading are also not good at constantly monitoring their dependencies for vulnerabilities.
You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.
Also, Gentoo dating back to 2003.
And today.
So, vendoring?
Well in the Java world, Maven had custom repositories which did this for the last 20+ years.
That is exactly what I do.
When people ask me what's so wrong with lowering the bar of entry for engineering, I point to things like this.
Engineering used as a title should be regulated in the software industry; it was always a title reserved for a role that requires accountability. In software, it became used so casually without legal restriction that full stack developers started using it.
This is most often pushed on the person by their company. I don't have an Eng degree nor certification, but my company forces my title to be "... Engineer", which I dislike, but I've been told this is just how it is.
I dub thee "node payload manager."
A day ago I got down voted to hell for saying that the JavaScript ecosystem has rotted the minds of developers and any tools that emulate npm should be shunned as much as possible - they are not solutions, they are problems.
I don't usually get to say 'I told you so' within 24 hours of a warning, but JS is special like that.
There's nothing really specially about the JS ecosystem that creates this problem. Plenty of others could fall in the same way, including C++ (see xz).
The problem is we've been coasting on an era where blind trust was good enough an programming was niche enough.
There's a culture of micro-dependencies.
In c++, most people wouldn't publish a library that does the equivalent of (1 == value % 2). Even if they did, almost no one would use it. For npm, that library will not only exist, it will have several dependencies and millions of downloads
That increases the surface area, which is certainly bad. But that doesn't really mean the risk isn't similarly there for C++.
A few years back, the university of Minnesota was banned from the kernel (are they still banned?) for testing this exact theory. They tried to figure out how hard it would be to inject an intentional CVE into the kernel.
[1] https://www.bleepingcomputer.com/news/security/linux-bans-un...
Of course, it's a risk with any dependency, but for a small number of dependencies you're more likely to be able to do some level of vetting.
The university of Minnesota would have had a much easier time not getting caught if there had been a tree of thousands of independently maintained dependencies
In practice this means that in C and C++ land you have large framework-style libraries (GLib, Boost, Qt etc), which are much easier to vet, and doing it ones gives you a whole lot of goodies at once with minimal dependencies.
Lower barrier to entry - JS allows newbies to roll up on CodePen and see the result of code without understanding the execution environment.
You ain't wrong. Now we have industries that built software using less valuable labor that does not need to understand the technical layers underneath the application development environment. Not unlike the experience of someone who started driving a few weeks before their driving test versus someone who has been driving since the age of six.
Unpopular opinion: why not reduce the dependency on 3rd party packages? Why not reduce the number of dependencies so you can know what code you are using?
Because then I would have to test, write, and maintain that code—and it becomes susceptible to leaky abstractions!
You have a choice, reinvent the wheel or use someone elses wheel.
I’ve wondered this for so long, I questioned my own sanity.
js is a fucking disaster
"It's always NPM."
Eh sometimes it's pypi