Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't.
Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)
- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer)
- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally
All are open source / free.
If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
This feels like a very very small group of people; and people who really could do with opening the file and adding the line.
I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption.
So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
Every one of those has a different opinion about how to spell "cooldown".
On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown directive in them. How do I do that with a cooldown?" (Where N is unknowable, because of course it is.)
> The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
This statement makes very little sense to me. I've worked on several of what are likely the largest JS monorepos in the world, and they all define a specific version of a specific runtime and package manager you should be using.
An extra $15 of labor is well worth the cost of not having to change my own oil. They will do it efficiently and won't break anything. The cost of messing up one time immediately cancels out a lifetime of DIY savings, and they are equipped to do it right.
> Changing your own car's oil is actually not that hard
It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance.
> Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers.
Exactly. Using a QR code app required specific knowledge of the app, an internet connection, some time, knowledge of how and when to use it, and something to use it with - the barrier of which surpassed the convenience gained from the QR code.
> So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
I'm struggling to find a non-contrived group of people who:
- do not know how to open and edit a file on their system
That group of people is the loosely affiliated people called "vibe coders". Even to get them to install depsguard is a challenge. I just ask them to point Claude to depsguard or cooldowns and follow the instructions (to save the tokens, of course Claude can figure it what needs to be done on its own)
The issue is that Claude Code also will be super happy to npm install axios / tanstack etc unless you explicitly tell it to add cooldowns.
> a place where you have sufficient access to the vehicle to drain it
Probably the only valid argument for people who park on the street.
> the right equipment
One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, borrow from a friend. If you can't afford $65 once to save money in the long run while owning a car, you probably should've bought a cheaper car.
> the right disposal solutions
Every oil change requires a jug of oil to be purchased. You can drain your used oil into this jug and then dispose of it along with your other household hazardous waste. This is not hard.
> Most people who have cars do not have that.
I might believe this for a place to do an oil change, maybe. I struggle to believe most, but I would believe many. Aside from that, if you don't have those things, you are choosing not to have them.
Which is kind of the point. None of these things are hard, at all. The majority of car owners 100 years ago could adjust their own timing, clean distributor points, replace belts, etc. because if they couldn't, they'd be calling for a tow truck every few hundred miles. Those are all harder, and things have only gotten easier with time. If you can't do them, you are choosing not to, because there's an even easier solution - spending more money and getting someone else to do it for you.
In ~300k km worth of diy oil changes, I’ve yet to change a crush washer, and yet to have a drain plug leak.
I always replace them on friends’ Toyotas, because they seem more important, but on every car I’ve owned it hasn’t mattered. And if you take the least amount of effort to google “how to change oil on ________” (fill in the blank for your year, make, model), some forum or video will probably tell you exactly what steps to take, including whether or not changing a washer is necessary.
Costs me 15 cents per washer delivered, why bother risk it? The world doesn't need more cancerous used motor oil on the ground.
After downloading a service manual and doing many things myself it became very apparent that mechanics barely bother to do work the right way despite it coming at virtually zero extra effort.
It's quite rare to see them use a torque wrench on many bolts and if you ask them why "they know it by feel", cool, but why not use a torque wrench to the proper specs anyway? It's not any harder.
My favorite way to do it is in the auto parts store parking lot. They will help you cart your full drain pan back to their oil recycling receptacle and some will even prop the back door open for you to walk it straight there. The bonus being if you do happen to spill a bit you're not stuck having to power wash your own driveway. I've got a process down to where I can pull it off with one pair of nitrile gloves, one rag, and one trash bag, to keep any residue from the drain pan staining anything.
> Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid.
My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.
In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.
Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well.
That's where the lockfile comes in, it pins the dependencies of the dependencies.
Lockfiles serve multiple purposes. For example, some include hashes so you aren't served altered packages from the package registry. I agree with you otherwise, though.
The lockfile also handles the first-order dependencies, though. Pinning them in the manifest doesn't enforce this -- the lockfile does. And yes, I agree that the lockfile _also_ handles pinning dependencies-of-dependencies.
Yeah imo that is bad advice. In my experience, lockfiles do as designed and exact pinning in the high-level manifest makes it extremely hard to do periodic updates because you end up spending hours tinkering with pins to try to find the right combo instead of letting the package manager automatically resolve everything for you.
You end up with ancient dependencies because you add friction to periodic refreshes instead of running `package-manage refresh-lockfile` (whatever the relevant command is for your package manager)
> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown,
by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.
what is the difference between these two things from the point of view of how much work you have to do?
- checking every update of every dependency to see if is a relevant urgent security update
- checking every update of every dependency to see if it turns out to be a supply chain exploit
am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.
It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
I believe the point is that if you delay patches until X days after release, usually someone will catch it and the maintainer or the package manager will pull the infected release. Thus, by you doing nothing and waiting X days, you protect yourself by never even getting the bad release. Then on the flip side, you just keep up with urgent security updates and push bad ones through faster after vetting them.
The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check if not force an update.
How often do you update your lockfiles? Where ever I have worked, it's once a year or whenever we get a critical CVE (in which case we only update the offending package and it's dependencies if required). Unless an attack is happening every day the chances of getting hit is slim.
I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
You have a lot more faith than I do that companies paying security researchers will not try to cut corners by directing the researchers they employ or hire to look at stuff that they aren't even about to install.
Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down
This is what serious software distribution platforms do. Developers may think that they are special and they would never install malware, but that's just not the case.
No, it will stop working. The whole point of min age is letting someone else taste the food before you, so you are not poisoned. (except maybe scanners but they can't detect everything and the payloads will highly likely to remain dormant when it detected it's within a scanning env).
BTW it will only get much worse because popular AI coding harness (e.g. OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.
You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not.
And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here.
I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.
I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
Caching proxies are a decent middle ground like Artifactory. AWS might support that (maybe only on certain repo types?)
Generally you can also configure rules in your internal package cache about what to do if a package is missing from the cache/hasn't been pulled yet. They also commonly integrate automaticaly CVE tracking and pull statistics so they give a nice "heads up" what everyone is using even if it's a local PoC
As an added bonus, they can also lower bandwidth bills like in expensive cloud environments when you can co-locate the proxy close to CI/build machines.
> Hope it's ok I hijack this thread again about setting up cooldowns...
In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities).
It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature".
Then, for a start, a security fix becomes easier to audit (both by security researchers and by the tools security researchers are using).
And then a cooldown can be used for the regular releases (e.g. non security-related bug fixes, perfs improvements, new functionalities, etc.) but no cooldown (or a much smaller countdown) for security fixes.
Something has to be said about a system like Debian where you can have an extremely stable server and you can configure unattended upgrades to only apply security fixes but nothing else.
Such new package releases are easier to audit by security researchers.
In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers.
That bit that's getting less conversation is the tools on the package maintainer side:
IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise.
The bug here isn't that we need to better authenticate already-trusted upstreams for packages, it's that the upstreams cannot be trusted as the sole source for security at all. Upstreams are a bunch of hackers[1] who aren't really interested in, nor will ever be good at, solid release engineering practices.
But some people are! The solution in the Linux world (and the one that saved us from xz-utils) is that there is a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. These people have different eyes, different consumer requirements and different quality metrics. And they catch bugs and malfesance that the upstreams aren't prepared to do.
NPM (and cargo/PyPI et. al.) continues to think it can short circuit this requirement for human labor. It can't.
[1] In NPM's particular ecosystem, a bunch of web jockeys used to extremely fast release processes, loose compatibility requirements, and extreme reliance on reuse. This really explains why we see this with node packages more than Python or Rust: older and more conservative programmers just don't have as many rakes to step on.
> The solution in the Linux world ... is that there is a second level of human beings...
AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it.
The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.
> Certainly it's only by pure luck that no malefactors have infiltrated the [pinko commie Linux hippy commune]
Yeah... no. Sorry, that's a wild misunderstanding of the economics of the Linux ecosystem, modern libertarian thought and the employment status of people with write access to the packaging layers.
> ... a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users.
> The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.
That was also what I was thinking aloud a moment ago. And there would be a business opportunity, too. Perhaps not like RHEL et al. full-blown stuff per se, but say smaller scale guarantees with different pricing; web, AI, scientific computing, and whatnot. At the pace things are progressing, I'd guess you might even get desktop etc. users on board (for nominal pricing).
But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit of that layer of review.
They make their money from getting paid by other companies though, don't they? It's hard for me not to imagine that companies in general will see "testing stuff a day later" as a way to cut costs or not paying out as much for bounties because of claims that no one was actually affected yet
> Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise.
Mandating that the final binary is compiled without having any access to any test file though would have prevented the xz-utils backdoor as it was conceived though.
A proper packaging setup would first verify that all the tests are passing and happen in an isolated environment. And that isolated environment either returns which tests failed or gives the green light.
When the greenlight is given (that all tests are passing), another environment should first delete all files related to tests and then build (in a bit-for-bit reproducible way btw and we're basically here already so that's good) the final binary / package.
If you prepare your final package in an environment that has access to test files, there are simply way too many ways obfuscated binary data can be hidden in test cases / test files.
I'm not saying the NSA (sorry, Jia Tan) wouldn't have tried something else but I think we should really move to build/packaging that discards non essential data/files before compiling.
P.S: note that as a side-effect of reproducible builds... If we have reproducible builds and if we add, later on, a builder/packager that discards tests files and ends up with a final package that's not bit-for-bit identical to the package created while having access to the test files during the build, we've just detected a backdoor hidden inside test files (like the XZ utils one). As a really mindboggling food for thoughts: if we were to recompile all the Debian binary packages that are already reproducible today (95% of them), but while discarding all tests files before the build, we may catch other backdoors.
> Mandating that the final binary is compiled without having any access to any test file
It would, but I'm not seeing that as a suggestion? That was a very clever side channel for hiding the build-time payload. It wasn't remotely the "root cause" of the exploit, which was that a malicious actor got write access to the release process of trusted software. I mean, if you can do that, you can surely find other clever ways to hide your junk.
To wit: you're not wrong, you're just stuck on minutiae. By all means make the case, but at best you're proposing a small constant factor optimization.
My read is that there's a crowd that is unimpressed with mechanistic changes when in their view there is a cultural issue.
From the outside looking in, web dev has this frantic wild west energy to it. Mutability, dynamic typing, standards changing constantly, frameworks changing constantly, continuous delivery, CDNs, live A/B campaigns, large numbers of dependencies, sensitive user data spread out across a lot of infrastructure.
I'm not saying that's an accurate view and I don't think "I told you so" is the right attitude, but I can understand the place it comes from.
According to [1] "All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised."
So the malicious package would have gotten the happy little green star, with users assured it was "Built and signed with provenance."
No deep dependency graph, so easy to audit and inspect. Stable development process, so easier to manage the flow of updates. And I believe a more cautious ecosystem. Not everyone is rushing to create or adopt new libraries, especially for what could have been a single file. So most libraries are about solving a domain, not just one single algorithm.
> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
I mean it keeps happening lmao. You can track npm attacks these on a calendar. Someone made a npm parody of the classic "no way to avoid this" The Onion article.
It's great there's work to stop it all but also... it keeps happening. I find it funny in a "here we go again" way.
>> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
> … the classic "no way to avoid this" The Onion article
But isn't point of The Onion article that A) the US has >50x as many incidents as the rest of the developed world combined [1], and yet B) acts like there is "no way to avoid this". Does NPM have >50x as many incidents as the rest of established languages combined? Is NPM claiming there is "no way to avoid this" or are they putting in place things like automatic install delays?
While all the major js package managers already support install delays, none of the big local C#/dotnet/nuget apps do (Visual Studio/Rider/nuget/dotnet/VS Code). https://github.com/NuGet/Home/issues/14657
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days).
I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package.
None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
It works because there are multiple companies doing it and double checking the results.
For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends.
There is still a lot of human analysis that occurs in making the call that an attack is occurring.
Yeah, this is the part that I don't get. If the solution is "security testing should come before people install it", why is the big push to have people intentionally add this artificial delay to install later rather than moving the security testing earlier to before the release? If you want to make people not drive on the road until the pavement dries, you don't try to convince everyone to push back their workday by an hour; you just lay the asphalt an hour earlier.
Then the ... malware will just add delays? Or do they really do manual in-depth analysis of all new code? Just running and seeing it do things is probably a lot easier.
Security scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for.
I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.
@exitb it is much more desirable for security scanning companies to compete to find issues in a timely manor. If npm blessed one as a gatekeeper to the whole system they would be between a rock and a hard place. Unable to priorities high impact packages over the long tail of packages no one uses without pissing people off. Unable to add experimental new detections that may be a little noisy at first due to the huge disruption it would cause. Be trivial to game as obscure packages could brute-force their way though then use the same hole on a mainstream package.
A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.
The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level.
There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period.
To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.
Thank you for the thorough response. I got the following from yours and other responses:
* The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread.
* This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well.
* Maybe NPM should run scanners before distributing malware?
* If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.
> Maybe NPM should run scanners before distributing malware?
I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited.
So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.
Look, nobody requested fully automated scanners that are never wrong. A scanner that asks the project owner to sign in with 2fa and confirm the release in case it's been flagged is going to be more than sufficient.
There's a really bad implicit assumption in there: Microsoft's scanners have solved the halting problem, so they can tell if a package update will ever flip to malicious mode, or has an intentionally inserted security hole in it.
Of course, this also assumes that Microsoft's internal scanners are much better than the scanners available to the attackers, since any reasonable attacker is going to just run their obfuscated code through a scanner as part of their CI job. (And maybe even use the MS scanner as an oracle by submitting fragments to NPM to see which pieces of their exploit chain get flagged.)
Waiting until everyone else canaries is much stronger, but even that doesn't work on a targeted attack.
Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.
Fair, I didn’t do a “as of this morning check”. Should’ve done better. It’s sad because I moved away exactly because this feature was missing and now I’m not going back.
There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.
I’m having a real problem at work with security theatre and the growing push to obsess over numbers of “vulnerabilities” in our projects. And then auto Dependabot PRs that encourage churn to fix issues that if an informed person actually reviews easily concludes it doesn’t affect us in the slightest.
A separate pathway to updates. At the moment there is a pressure to keep all the packages updated at all times. Every time a new version of a random package deep in the dependency tree gets published, you roll a dice: is it a bunch of bug fixes that I don’t care about or a vulnerability patch that need to apply immediately? Since it could be either most devs just auto pilot on updates. This creates an environment where newly introduced vulnerabilities get promoted rather quickly before the version matures. Sure, waiting a few days to update a package sounds great, but there is no guarantee that the vulnerability will be found quickly.
To give you a context, I get 20-30 PRs a week across all my repos with potentially hundreds of packages (non distinct) from dependabot. I give it a cursory look and try to get a summary of changes. Do I evaluate every single package update? Nope.
Huh? Sorry but both of your comments are frankly incoherent. I have deep experience maintaining large dependency graphs and empatjize with the frustration about CVEs in deep transitive deps, but I can't make head or tail of your "separate pathway".
Many places run analyzers on published code; many security users have reason to shorten the period. The default period becomes the period where white hats have a chance to detect it and stop it passing the threshold.
Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)
That’s my point. For whatever reason, npm isn’t doing it. All npm users adding a minimum package age is kind of like doing it as a collective, without npm’s help.
I think if they did it, then attackers would be able to iterate their attack against their own project, and once it passes the filters they could deploy for real.
I guess it could work better if it was enabled for only actual attack vectors projects.
I think you can set it on internal repos, but then you need to allow-list internal code. People act like this is simple + solved, but it's not. It turns into 100K-1M's of LLM tokens on a semi-regular basis, or "just hire a build infra team for your side project" pretty quickly.
> Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.
Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.
- Best practice for both reliability and security is to not immediately upgrade to latest versions. Only immediately upgrade to security-patched versions. If your software doesn't need a new version, you can remain on the old version.
- When a feature you're developing, or a transitive dependency, requires an upgraded version, you can upgrade to the latest stable version that satisfies the dependency. But as each of those then requires an additional transitive dependency to be upgraded, you have more and more components upgraded to "latest", and the attack surface widens. So there are two alternatives:
1) (preferred) Upgrade to the latest version of the next-to-latest minor version, within the oldest major version that is supported, if that is available. This is the least number of changes that provides the needed functionality.
2) Upgrade only to the oldest version that gives you the functionality you need. If this ends up being the first version of a new major or minor version, this can cause bugs (initial releases of new major/minor always has bugs), so in that case you might as well use the latest version of that major/minor version.
This all affects security by avoiding upgrading to the latest version. It affects reliability by minimizing the amount of changes between your current version and upgraded version (changes lead to bugs).
The argument against all that, and for always upgrading to the latest versions, is intended to make software development easier. You avoid all the complexity of picking versions or reading changelogs by using software that is probably (but not always) all compatible. But it makes reliability and security worse. So you need to choose: do you want security and reliability, or an easier time writing code?
it would be way easier if dependencies were a flat list and not a graph, aka peer in npm parlance. I believe that’s what go does. A library only need to say that it depends 1.x.x or 1.2.x and it’s up to the application to provide it. Conflict is handled manually.
The onus is on libraries developers to cleanup their act. Start vendoring code instead of depending on hundreds tiny libraries.
Most attacks are discovered 'pretty quickly' via scanning services and groups that monitor repositories. The problem is even an hour gap could mean tens of thousands of downloads and executions.
1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs.
2. Anywhere you have `npm install` or `npm test` or anything where code executes, that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern.
3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture.
(2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks.
There are some vendors in this space that you can and should evaluate as well.
Exactly, popular AI coding harness (OpenCode/KiloCode) downloads random npm packages in the background without you knowing. What's worse is the devs don't care.
lol yeah I thought of that as typing but figured I'd avoid the complexity. "latest version" means, give or take, whichever the latest one was that contained a bunch of new rules around supply chain stuff.
Should we instead of these cooldowns just run builds in isolated contexts?
I’m running a maven proxy locally. All builds happen inside containers. I only use public repos for python, npm, and go. So these builds happen also in containers but don’t need a repository proxy.
> Should we instead of these cooldowns just run builds in isolated contexts?
I'd suggest both. Cooldown for 1-2 days is very cheap and you likely won't even notice it, so it's quite harmless and from what I've seen even just 24 hours is enough to let security companies pick up malware.
It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.
I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.
Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.
I mean there’s nothing stopping you from committing node_modules to git (after running something like https://github.com/timoxley/cruft on it) and reviewing code changes on dependency updates.
I even managed to make that part of the workflow on one team I worked with but several other teams since thought it was a crazy idea. :)
But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation.
That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.
That might change the odds, but unless you fork diligently (and monkeypatch each and every future vulnerability) you might ship a compromised fork forever.
Software vulnerabilities are often not placed maliciously, and are present in the original source. If you don't patch them if discovered later, you'll be vulnerable to them.
Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go or Python projects generally only include a handful of external packages. Node projects on the other hand…
Hum... You should check your JavaScript numbers again.
I have never seen a project that uses npm and has only dozens of dependencies. Normal numbers are in the 10s of thousands (including different versions of some deps).
Built Packj [1] to audit dependencies easily from CLI.
1. Packj (https://github.com/ossillate-inc/packj) detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).
About a week ago, I uninstalled Node from my laptop, which felt great. :)
I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir.
Cooldowns and allow-listing of installer scripts are good additions to layered security, especially for CI. However, I think the fundamental thing that needs to change is the OS permissions model. The default of trusting third-party software with everything your user has access is no longer workable.
Are you using something like Bubblewrap/Firejail/Flatpak, or what does such a setup look like? I've been entertaining a similar idea for a while but haven't gotten to it
I'm using VSCode dev containers, powered by Podman on a Mac.
Most people would probably choose Docker over Podman but I'm weary of Docker and wanted to try something else. I would not consider myself an expert on containers but with the help of Claude I've been able to fight my way through various challenges:
* Persist a volume for Claude so that conversations don't get blown away with every container rebuild. An attacker may still be able to get a Claude token from me, which is something I'd like to tighten up in the future.
* Fix file permissions issues by running rootful inside the container. (The container process still runs on the host as an ordinary user. Since my threat model is "compromised dependency scanning for credentials in project dir and home dir" rather than "attacker escaping the container", I figured that was good enough to get started.)
* Work around architectural availability issues with precompiled PyPI libraries. This I punted on by choosing a different approach and eliminating the problematic dependency (by writing my hobbyist CAD 3d printing stuff using Blender extensions instead of CadQuery). I've gotten the impression that dependency compatibility with a container workflow is an ongoing challenge.
* Run a database in a docker-compose sidecar for integration testing.
For all the projects I'm containerizing I'm the solo dev with full control over the Git repo so I can make the call to add a `.devcontainer/devcontainer.json` config file. I haven't yet explored how to isolate projects I don't control.
I'll be honest, I have always found the "trusted" publishing concept quite suspect -- the boiled-down argument is that developers are too incompetent to manage their own keys. Yes, there are obviously problems with storing plaintext publishing keys and tokens in $HOME, but that isn't the only solution. You can use hardware keys for signing (I would wager a lot of open source maintainers have at least one Yubikey or NitroKey kicking around -- they used to give them away at conferences) and for upload tokens you can even just password-protect them or require them to log in each time.
The alternative proposal with "trusted" publishing is to grant all of GitHub's automated infrastructure the ultimate authority to publish things on your behalf automatically in a way that it is shown as being more "trusted" than the developer uploading it themselves! I'm honestly surprised that it took this long for supply-chain attackers to start targeting this obvious security hole -- I doubt any user of GitHub would argue that GitHub Actions are a parogon of security, and yet the strongly recommended deployment workflow for several language communities involved bolting it into the core of your release mechanisms! I think the OCID stuff is interesting and provides some nice properties but it doesn't prove that the GHA workload is actually trusted in the sense that "trusted publishing" means.
The arguments for adding speed bumps to auto-applying updates apply just as much to adding speed bumps to doing releases (arguably even more so -- even rapidly evolving libraries don't have hundreds of releases a week). Automating everything to the nth degree just expands the blast radius when stuff like this happens.
I do all runc releases manually and sign them with a PGP key stored in a hardware token that requires a pin for every signature attempt. Yes, it's a bit more cumbersome but it certainly would be harder to supply-chain hundreds of projects of every maintainer would need to manually publish them. For some other projects that need to publish to crates.io or PyPI I was honestly a little dismayed at how prominently they push for "trusted" publishing and how little support there is for making the "dumb" publishing flow more secure (they even visually display such releases as less trusted, and the only way to get more green checkmarks is to let GitHub take the wheel).
I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago
If supply-chain security is a concern yarn is the worst js package manager you can pick. It comes far down their priority list, below "just make things work without need for user input". Whatever you thought you configured will simply be ignored many times and that's considered a feature.
Go look in that projects issue tracker and commit log for changes to relevant configuration and you will know what I mean.
I don't follow your second sentence. Doesn't npm have the opposite problem of 'not invented here'? By adopting many external packages rather than developing in-house, npm projects tend to have large, complex dependency trees. It has long been the complaint that packages such as https://www.npmjs.com/package/is-windows create potential vulnerabilities and maintenance headaches, when writing the same piece of code directly is so simple.
One common fallacy of the NIH folk is that reinventing X package would take a lot of time.
But first, you will of course not remake every single feature, just the one you need.
And furthermore, when you code just one feature, you don't need to make any abstraction or additional function interfaces. So it's cheaper, and probably better integrated.
Another fallacy is that you'll make bugs and introduce vulnerabilities. Maybe, if you are a bad programmer, but you will also avoid a category of bugs where the vuln is introduced at the boundary of the integration between two different libraries that weren't designed to fit exactly together. (Many such cases)
One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime
I’ve always felt this automation shouldn’t exist at all, but should rather be selectively controlled via a hook. The hooks yarn offers out of the box for example can be used to run any code you need to after install. Putting the project owner in control instead of the dependency.
Nuget/.NET ecosystem just handles it so much better. Netvips assumes libvips is available and they provide packages for common platforms. No need to waste electricity rebuilding stuff, or install native build chains, build and test deps. Similar for Skia or Sqlite or whatever.
I absolutely don't. I even sometimes use "curl | bash" to install new things on my machine because most of the time it's easy and I tend to trust the authors.
My point was just that I don't think moving to pre-built binaries solves this issue.
It can usually also download a precompiled binary for the C++ shim that sits between node and libvips, but if your node / arch / etc. is not supported, it'll compile that (that's what the build.js file you linked does).
Bah, I think that these kind of vulnerabilities exist in any "packaging ecosystem" where the base language offer "ambient authorities"(any library can access your filesystem) which is .. all of them!
AFAIK only research languages do not provide these ambient authorities :-(
I am not a JS dev, but had to interact with the ecosystem some. It became so bad I won't install anything without it being in a Docker or Podman container.
I honestly don't understand how you could do JS on the backend in 2026. This language and ecosystem are so bad it's ridiculous. Almost all other options (yes, even PHP) are better.
On the browser at least you have the excuse that there's no other option (hoping Wasm will eventually kill JS for good, but we're not there yet).
> The affected packages are frontend libraries that are compiled and bundled into some container images during the Red Hat product build process.
So you might be affected if you deployed any Red Hat container images built after the compromise, I guess. (I doubt anyone besides Red Hat is using the affected packages directly.)
Chainguard based images, packages and libraries are first line of defense. Expensive? Yes. Foolproof? No. I think these types services will be mandatory in the near future.
How would that help? These are not general purpose, base system libraries, these are libraries specific to a product that uses them. Either you're not using them and hence they would not be installed in the first place, or you're using them because you have the product installed.
Though I would expect that Insights uses RPM packages to ship components and not the public NPM packages.
It will only get much worse because popular AI coding harness (OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.
Setting min age is useless if everyone is doing it. The whole point of setting min age is make someone else take the bait before you.
Can be mitigated, as the sibling comment points out, but even in the situation you described, the blast radius is reduced, especially for frontend libs.
Yes (assuming they're doing frontend dev and including the resources from the page). The code is fetched and executed from the browser, so It'll have to escape the browser sandbox to do something nefarious.
Same. I came back to do a little frontend work a couple of years ago and was horrified by the replacement of script tags with subresource integrity with npm and bundlers.
It’s difficult to determine which individuals are involved and even if you manage to do that they almost certainly live in countries without extradition.
I'm refactoring all my personal and research projects to utilize pure HTML/CSS without any dependency of JavaScript. This was always on the table but the cybersecurity risks from all programming languages and frameworks have increased due to AI.
I know of fundamental issues with JavaScript and see no reason why it's still standard on all web browsers.
The combined features that make npm particularly vulnerable:
1) Update by default. Manually updating your package references is annoying and does lead to other security issues as you don't automatically get latest, but it makes this risk much lower.
2) Code executed on install. Statically-typed languages don't run the code until you use them, and that might not happen on the developer machine at all for first run after upgrade, it might be a lower-priv test-server.
3) Culture of many tiny modules (this is good! It's the natural way to fight NIH! Yay modularity!) means many more points-of-failure for security for this kind of attack.
This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if another malicious security update happens again.
So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that.
Can someone give a tldr on why this happens so much with npm ? I can't recall seeing this with any other package manager. Is npm just the default used these days and therefore sees this more often?
In addition with my usual rant about the current situation with most devs that now want to use dependencies in prod almost the day that they are released, there is something else that I just realized.
A big part of the problem might be attributed to Github and the modern CI/CD frameworks.
Before, the source code was located somewhere, and the CI was usually located somewhere else, and slightly unrelated.
At first, the CI job was to build ("privately") the artefacts, and they were manually released and deployed by maintainers and owner of software projects.
Then, it became the norm to have the CI located within the VCS file and the VCS located source code controlling the CI. For example having "script"/"description" of the CI actions located within the VCS itself.
Then, Github killed the CI/CD software market by offering "actions" almost for free and totally integrated within Github that was already widely used.
But still, for a long time people were wary to put tokens and security keys in Github and "public" CI/CD jobs and services.
And then, a few years ago, it became the gold standard also...
You would look ridiculous to manually sign and deploy new releases with well guarded keys.
What is expected from you is to have all your aws, github, ... secret api keys loaded in Github, and have your deployment and infrastructure provisioning automated with ("public") github accounts. All to be deployable in a second of a change being pushed.
So, obviously, the moment a hacker get control of a Github account or Github API keys, it is game over for the entire infrastructure.
Here I only referenced Github, but the bad things that it taught us became the norm and now these patterns are replicated everywhere (Gitlab, ...)
All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.
I think this is a thought-terminating cliche, and false equivalences. Stating "This area where problems occur at a high rate is not a problem, as problems can happen elsewhere too" is a curt dismissal of a valid concern. It implies the course of action, rather than to address a high-problem area, is to ignore any solutions which aren't global, or equate it to lower-incidence areas.
You bring up a good point that this class of problem, or related ones can occur with other package managers. It was frustrating how long it took the Crates.io team (Rust manager) to address name squatting, in what appeared to be a "no perfect solution exists, so we won't act" line of reasoning.
It's the exact same logic people used for Apple computers back in the day. The idea that Macs didn't get viruses because they were inherently more secure.
But that wasn't true. It was purely a numbers game. Windows' popularity was so far off the charts that hackers naturally targeted Windows users instead of Mac users; it was just a better use of their time.
The same thing is happening here. Other package managers do get compromised, but the sheer frequency of npm incidents just reflects how overwhelmingly popular Node.js and web apps are right now. JavaScript simply has a much higher usage rate than most other languages.
It was a reply to "only package manager where this regularly happens". Anyone who thinks it can't happen to them just because they're writing Python instead of Javascript is in for a world of hurt.
The comment I replied to is a literal meme. That's as charitable as it gets. Nothing "thought-terminating" about it.
While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself.
Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than NPM which puts the malware in the trusted/default/automated path.
Depends on who 'you' are. I have one package I installed from the AUR and it's from a corporation that just repackages their builds. The problem is always who vets the packages. I trust the Arch team and I trust that one corporation. Also to use the AUR it's a different command, so I can't get surprised by an AUR package. It's not a pacman -Syu is going to pull in a new unknown to me AUR package.
Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?
They didn't back up their meme with real commentary because they have no real commentary to stand on:
They're spreading cheap disdain & scorn for npm ("only package manager" framing). But most other package management systems have similar abilities to run pretty un-sandboxed code.
One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and pointing to a different package repository URL.
If there's some change that must get out sooner, then there can be some fee to pay to npm to have their security team do their own review.
Critically, there must be time for someone to review before it's the default to be selected.
I'm sure there are issues with this, this was off my head, but it seems like a really easy step to at least stem the problem for now. And there are a bunch of ideas like this that would help, but NPM doesn't seem willing to take it seriously as an existential threat to the ecosystem, rather than taking trivial steps.
> Critically, there must be time for someone to review
By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here.
Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have nothing of the sort. PyPI, Rubygems, crates, npm, it doesn't matter. I can just make an account and push whatever I want.
These package managers are like this because that's what developers actually want. They don't want to deal with Linux distribution maintainers in order to get their software into the official repositories. They want to just run $packager push and have it out there with zero friction.
As discussed elsewhere in this forum, these exploits are being found by security companies in the first few days after they're published, that's just already too late. For example, the auditor who made the very post that we're discussing! For another, many security-focused AI companies have automated checks on NPM packages. Many people are implementing it on their end by having their client wait seven days before pulling new packages, but that's O(N) rather than O(1), and it's not evenly spread.
If no one reviews it and it still gets out, then we can address it then, but that seems much less likely.
Ideally, the solution is that all of these language package managers need to get serious and have maintainers, but lacking that, at least having the waiting period be built into the server instead of the client is a clear win.
That changes nothing. If you're downloading packages pushed by randoms, then it's vulnerable. There is no escaping it. Go's module index is filled with people's GitHub repositories. You have no idea what's inside those things unless you review the source yourself.
The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.
Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.
You can have a security solution but with large ecosystems like this it can’t be pushed to the ecosystem immediately and everyone will take longer to test and deploy.
Right now you could audit packages and make sure you don’t get the latest version
The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem.
We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library.
We should have rules that we install the latest that's older than three days.
We should be running "npm audit" and other stuff like Trivy.
It is the same for Crates.io and PyPI they also supply scripts without asking the user so opening an IDE will run them. For PyPI you need to even execute scripts to discover the dependencies!
> but NPM makes it dangerous to merely open a project up in an IDE.
It does not. Opening a project in an IDE has always been dangerous because there are about a thousand language server and analysis tools that run in the background. This is why IDEs ask you whether you trust the contents of a repository.
An even if some automated background execution initiated by the IDE doesn't get you, running `npm run test` 15 seconds later will.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of other security settings, like minimum age, no trust downgrade, etc etc.
All attackers can attack packages by updating how a package functions; but npm is particularly problematic as it runs non-sandbox scripts as the calling user. Putting not just your project at risk, but your entire machine/network.
And this stuff has been known about for YEARS, they've taken no action.
> since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly.
The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.
A lot of packages are pulled in to call minimal bits of the actual library. I obviously don't have any statistics on this but my instinct would say that for the average application only 5% of an average package is actually used.
So not running package installation scripts is a huge, massive problem.
So what? Packages can just put their backdoors in some initialisation code that is always used.
It is possible that not running package installation scripts could improve security, but for that you need really good sandboxing/compartmentalisation of library code, e.g. with CHERI, WASI component model, or if all of your code must run in a secure context it probably helps.
But those situations are unfortunately rare in my experience.
It doesn't matter how much of the package you use. Here, you can use literally 0% of Koa and get pwned by one of its transitive dependencies (koa > cookies > keygrip > tsscmp) by simply importing the parent package:
mkdir demo && cd demo
npm install --save koa@3.2.0
echo 'console.log("--- pwned by a transitive dependency ---")' >> node_modules/tsscmp/lib/index.js
node -e "import 'koa'"
Most of them? Ruby gems have hooks, Python has setup.py, deb, rpm have them too (relevant if you're installing from 3rd party sources). Elixir/Mix doesn't technically execute code on install, but your language server builds the dependencies as soon as you open the project, which can execute arbitrary code.
Either way it misses the point, nobody just fetches code and removing post-install scripts wouldn't change much because you're going to run `npm run something` 5 seconds after you run `npm install`.
>Putting not just your project at risk, but your entire machine/network.
Between average hackers and extortion groups, foreign governments and state sponsored actors and last but not least my own government, I don't think there's much room left for non-compromised supply chains these days. Treat everything that can run foreign code as potentially compromized and keep everything compartmentalized. If you keep your crypto wallets or private banking info on the same machine where you do development, you're asking to get shafted one day. Or if you keep your big corporate github keys on the same machine where you do private weekend projects. It doesn't matter what you use in particular, even if some vectors are currently more popular than others.
Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.
In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't handle it, I'm hand rolling it.
Dapper remains the only constant 3rd party dependency in my projects. I don't know how much longer this will last with LLM assistance. The frontier models are very good at writing repositories over arbitrary sql schemas with low level primitives now.
> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.
This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing small things (left pad) rather than larger utilit libraries maintained by a larger community.
A larger community contributing to a larger library would mean that a larger community feels responsible and checks it.
That small package mentality a trace to web usage: JavaScirpt code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
With server side Node.js this lead to tons of dependencies ... which is worsened by npm allowing to have multiple versions of the same package in parallel. So if something depends on leftpad 1.0 and something else in leftpad 1.1 both are fetched and both are available.
This has been improving recently; one large project built on several heavy libraries that I've been supporting since 2018 currently installs ~180 dependencies without loss of functionality compared to how it worked, and what it depended on, back in 2018.
IIRC 6 years ago the full dependency tree congealed into more than 2000 packages. One small example is React itself:
Another is switching from create-react-app with its hundreds of transitive dependencies to vite, which, according to the test I've ran just now, currently has 15. Etc.
> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
Which is another part of this entire insanity:
Browsers are already <<huge>>. They're also built by <<huge>> companies companies that collect <<tons>> of analytics.
You'd think at this point they could present a proposal for a rock solid extended JavaScript standard library that would be based on actual website usage and would be comparable to what Java, .NET offer, obviously only keeping the parts that would be applicable to the web.
It sounds crazy but I think the Chrome installer is 150MB and an entire decent stdlib these days would probably be 1-5MB...
The web api is actually extensive. I can understand complaints about it being not exactly approachable, and some wanting a cleaner abstraction, but there’s no way that it is small. Most issues is about people wanting to download a small library than just vendoring the small snippet of code.
The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.
That was circumvented once by CDNs hosting common libraries so that those would stay in browser cache, browser vendors then "broke" that by caching per origin. (So that an evil site can't detect whether a user had been on some target site before by testing whether assets are fetched from cache)
Issue probably is that the standards process is slow (unless it is a feature Google "needs") and full of bike shedding (which features and how exactly they'd look) and adaption of features by developers is slow.
JavaScript meanwhile should be stable enough as an environment to allow a broader standard library.
Luckily it is slowly getting better (see Temporal as new date library, replacing moment.js usage in many places)
How large a project do you typically use dotnet for?
IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.
> How large a project do you typically use dotnet for?
The largest dotnet project I am responsible for has around 50 megabytes of source files sitting on its main branch right now. If you include the generated WCF references it's probably closer to 100 megabytes.
But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.
Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'd see them in npm either. Since, they just don't care.
The biggest problem is not software but culture, not at npm, but in the js ecosystem.
The js ecosystem is simply a juicy targets, the attack surface is enormous.
The attacker can make their attack more sophisticated,
there will always be a maintainer that can seed the worm spread.
Meanwhile in the nuget ecosystem is way smaller and have way less mainteners involved for a single given dependency.
I'd go further and say that how JS and the web itself has been run over the years has predisposed it to this sort of thing.
JS didn't have a passable stdlib until ES6. It had bugs built into it because Eich was given a stupidly short time window to deliver the first version. Everyone (particularly MS) had (and still sort of do) their own way of interpreting the language. In spite of all of this it became the primary way of developing applications for public consumption.
This led to a bunch of people who wanted to be the 10x JS engineer to solve problems with their own libraries and technologies. None of them really talked, they just threw their packages on NPM's registry without second thought and some gained widespread use just by accident.
Google tried fixing some of this with Dart but chickened out at the last second. TypeScript was designed by someone competent but can't fix the larger cultural issues.
This is what happens when you put SV hubris and "moving fast and breaking things" over doing things the right way.
> Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.
I'm still trying to calibrate my take on this view.
If attacks are randomly chosen from the set of all potential vulnerabilities, without the attacker knowing which ones had been patched, then that logic clearly makes sense.
But in an adversarial situation where the attacker can guess which vulnerabilities you still have unpatched, or can try many different attack vectors, then having already patched some other vulnerabilities doesn't matter so much.
Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as.
It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed it somewhere where it would be dynamically loaded all the time.
Nearly every package manager I've ever used had post-install scripts.
You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs.
This worm spreads because npm install runs arbitrary scripts as you, automatically, just from resolving the tree. You don't have to build it, run it, or even import it. Opening the project in an IDE is enough.
apt/dnf scripts run on packages a maintainer signed and a distro gatekept. Not on whatever some rando pushed to a public scope 20 minutes ago that landed in your lockfile six levels deep.
"They both technically execute code" is true and beside the point. One runs signed code from a trusted path, the other runs unsigned code from the default automated path. That's the whole ballgame.
> You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs.
> You don't have to build it, run it, or even import it
If you just installed something with npm, chances are you'll be running it shortly, either as a tool or a library, probably minutes or seconds later. I imagine the use case of installing an npm package you don't plan on using or transitively importing, constitute a small portion of npm installs.
> apt/dnf scripts run on packages a maintainer signed and a distro gatekept
Unfortunately apt/dnf isn't much better here because random tutorials online suggest people add random repositories where the creator of any repository effectively has root access to anyone machine that adds it as a remote.
It's the exact same problem when random tutorials (and official pages) recommend to do a curl "URL" | bash to install something. Every time that I see it, I look it suspicious.
Most package managers with postinstall scripts are also heavily curated and have reputation systems. As you say, they run as root, so the high trust requirement is definitely warranted. Anyone can upload an npm package.
I think it’s just a bundle of issues. Deep graph of dependencies, distribution of minimized code (java has jars, but I don’t remember scripts), and nearly impossible to audit. With most projects in other ecosytems, you only have to interact with a few developer/orgs. But with npm, you add one library and you need to essentially trust 10s of entities on the internet.
That's why we don't let the developers run system package manager install scripts as root. We do let them run npm inside containers, which is still more access than I'd like them to have.
You mean directly on the machine? Not in a container? That would be a recklessly fast timeline. The configuration control board meets quarterly and it usually takes 4 or 5 meetings to clear a piece of software.
Not running lifecycle scripts by default is eventually going to be the default behavior. Late is worse (edit: I meant better) than not at all. https://github.com/npm/rfcs/pull/868
It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?
It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them.
It could add an optional key to package.json that allows someone to whitelist which packages can run install scripts.
It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI; (2) this hardened package status would be public, and (3) a developer could set a flag in their package.json that causes any npm action to act as if all non-hardened packages had frozen versions.
You realize that "dependency cooldowns" as a popular concept are extremely new, right? npm manages the installation of dependencies for millions upon millions of users across the globe.
> It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI;
Great, they did this.
> And so much more.
This shit takes time. Yes, they should have done this on day 1. Acting like any of this is easy to retrofit is just nuts though.
What is being said is that a new flag like '--minimum-release-age' would take, realistically speaking, tops 4 hours to implement (without AI assistance), plus a good 1 week of thorough testing, and maybe a 1 month period of progressive deployment. Come on, let's give it a total of 1.5 months, for good measure.
Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.
Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.
Not infra, but final product. I know, corporations move slow. But when there is a critical issue, and an actual desire to solve it from someone in a suit, suddenly turns out that the cogs were always able to speed up and move fast...
Regarding npm CLIENTS, PNPM is fundamentally different from (and superior to) npm or yarn.
Strongest possible recommendation to use pnpm.
It's also a good idea to use a private registry (eg via jfrog), acting as a proxy / pull-through cache, and point trad SAST and maybe AI scanners at it.
But dropping the npm client in favor of pnpm is a no-brainer. Speed, disk space, security, determinism, flexibility, fine-grained control over your dependency graph...
> allows all packages to run package supplied arbitrary code as the logged-in user after an update completes
As opposed to the completely untrusted package supplied arbitrary code that the logged in user executes when they actually use the package immediately after installing it?
The package might not ever be executed on the user's machine. Depending on your setup, it might only be ran on a server, where the data that can be exfiltrated is completely different.
Sure but like.. come on. Is that really a defense? Most packages are run on devs machines. And it's not like "Oh it's just running on my production server, what could go wrong there" is any better.
We should not dismiss that it is slightly better. Production servers vary rarely have creds to the source repository nor to other production servers running possibly more sensitive code where investing in a smaller supply chain was justified.
Why you are downloading code if you're not even using it to run tests ?
And if you run tests in CI/CD, or in a container, why you are downloading code locally ? Only thing that comes to mind is code completion but surely most people at least run unit tests locally before pushing the code out ?
MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.
NuGet is lock-by-default for the parent package, but with the move from packages.config to <PackageReference> it's no longer lock-by-default for dependencies.
It never made sense the other way. If I reference a package, logically I'm also referencing its dependencies at the version that the package uses. Forcing the user to also reference dependencies of dependencies of dependencies means the package reference lists aren't DRY.
But just the dependency list isn't sufficient to pick a specific version, thanks to dependency ranges. If Package A depends on Package B >= 1.0, and Package B has v1.0 and v1.1 available, it will use v1.0. But if Package B suddenly unlists v1.0, then future restores will change to v1.1.
Ah, I see the worry. A supply-chain attacker can use de-listing to force an upgrade to the malicious version if clients have dependency ranges that reach into the future.
I didn't know about that one.
In general, any dependency system that allows "you can silently upgrade to versions of the package that did not exist at the time the packagereference list was created" seems to be a vulnerability.
It's frustrating since this vuln seems trivially simple to fix, at a glance... although it would require an API change in PackageReference. Mandatory lockfiles by default, or getting rid of the floating versions misfeature. BindingRedirects let you override declared dependency versions anyways, they're not a blood pact.
It seems trivially simple until you have two dependencies with conflicting exact version requirements... So I don't think you can get rid of floating versions entirely. They did add NPM-style lockfiles for PackageReference, but currently not mandatory.
The version numbers for BindingRedirects are orthogonal to the package versions. You can have multiple package versions use the same AssemblyVersion so that applications don't need to create BindingRedirects. (e.g. Newtonsoft.Json - 13.0.0, and 13.0.1 in NuGet are both 13.0.0.0 for binding redirect purposes) And .NET Core/5+ don't need BindingRedirects at all!
Won't pinning a version lead to dependency hell, not to mention potentially using vulnerable versions if you don't a new version after it has some CVE fixes ?
i've been thinking about this as well. but having built a startup, i've learned that users don't care as long as they are given the value and most convenience. they don't really care much at security as much as we do. just look at openclaw? but maybe it's our job to make sure it is taken care of vs assuming the user cares and just make it look seamless.
Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory that works both on linux and windows!".
Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.
The industry is the process by which convenient crap like this gets standardized.
To meekly defend the indefensible here: it's not like rmdir on Linux (I won't speak for all Unixen) can cause loss of data, since it only removes empty directories.
Yep, but that could still cause issues (those entries could be used as signals, or be mount points for currently unmounted partitions, etc). rmdir anything that start with "/" should be an absolute no-go.
To say nothing about running a sequence of shell commands without the -e option.
> Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
Many package formats before NPM allowed for it, and frankly, it matters little, because if it can add code to your app it can run malicious code. The fact it executes on package install rather than when dev runs tests or the app matters little, and in general if environment is sandboxes, the package install is also ran in the same sandbox so disallowing it changes little.
so yes, every package manager can be hit, the reason is twofold
* JS is such a lowest common denominator it has that much more clueless users so just by scale every issue will be more common than in other languages
* extreme fragmentation leading to hundreds of packages needed for even small projects, which is again more chances for compromise
That usually has a separate maintainer checking things, not updating automatically and often being the author of those packaging scripts, as they are often distro specific.
Maybe NPM is scared to break a ton of packages? I also think action from NPM on the repo level is vital
I went through the package.json on my machine - seems like ~400 / 60000 or 0.7% have (pre|post)install. (That's not all of the scripts that run at install)
Seems to me like a backwards compatibility is a non argument since pnpm is popular enough to stand as existence proof that scripts can be, at least, opt-in
IMO - pre- and post- install scripts should just be abolished/deprecated. It should require a special dispensation from npm to even publish one. A better system for binaries (needed by esbuild) is probably needed.
Even saying "just use pnpm" isn't enough, we need to get the developer community to herd immunity and that isn't going to happen on an opt-in basis.
I would love for npm to sandbox as well. But I think the better way forward is just turn off scripts.
I agree that not running arbitrary installation scripts is the right default, but it's just an incremental improvement.
The practical difference between code that runs at installation and code that runs when the package is executed is, very typically, a small amount of time.
IMO, the hyperbole here hurts because it distracts from more effective efforts.
They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2].
I have; you specify one optional dependency per platform and set the requirements in each package. It works fine. A bunch of packages do this (e.g. esbuild). I don't know what your complaint is or what you're asking for.
Every package manager, by design, allows arbitrary code execution after the update completes. It is the entire purpose of a package manager. There is no point installing code that does not run.
On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution.
Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack.
Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.
Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that.
The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them.
That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.
Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.
That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.
Are scripts even necessary? I don't think e.g. mvn has any form of scripts¹, but if the dependency is compromised, you're likely to execute whatever compromised code is in there the next time you do mvn verify (or whatever). Slightly less wormable maybe, running tests or at least checking whether your thing still runs after upgrading package versions is really common, no?
¹ Annotation processors are a thing and somewhat similar to rust macros in function, but you need to set those up manually for each dependency, iirc.
But pulling a maven dependency DON'T run anything. You must download the repository that contains the POM.XML and run mvn with any goal that triggers the lifecycle.
Maven 4 aims to separate distribution and build poms. Currently, we generate distribution pom.xml for distribution using flatten plugin.
It's not the package manager, it's the repo and the cryptographic signatures that are trusted by the package manager and the users who choose to point their pacakge managers at those repos. The fundamental problem here is that people's risk assessment is treating a user named devioustiger12345 as having the same situation and story as Microsoft/Apple/Red Hat.
Non-profit Open Source distributions also and already package and verify open source packages (arguably often with a higher quality of analysis than Red Hat).
You pay red hat for compliance reasons (availability of a support you'll never call, mostly).
Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes?
All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with.
In fact, the entire situation has been exacerbated by coding agents because now practically everything happens on a single device that touches hundreds of different production systems with full production credentials.
Days since last malicious packages in NPM: 0 (evergreen)
Days since last malicious packages in PyPI: 30
Days since last malicious packages in Maven: 120
I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
Thanks for the link. However, a 7x size differential does not fully explain a 100x security incident differential -- although I'm sure it's part of it. Some of the root causes are very hard to address (e.g. a very limited standard library which encourages dependency explosions), some are just hard (e.g. established cultural norms around version pinning and upgrades, well-established reliance on install scripts) and some are easier (e.g. small tool improvements like min-release-age). I'm personally not going to touch npm with a ten foot pole in the next year or two, but I'd love to see significant improvement, so that I have that option again in 2 or 3 years. Stay safe!
The npm cli has bad defaults which you can turn off but they are there I presume for legacy reasons. The secure option is pnpm. The registry is fine.
Also on our comment about size differential ... it absolutely can.
If I jump from 2 meters hight it will be mildly uncomfortable. Jumping from 12 meters will result in severe injurious and possibly death. None of these things go linearly in real world conditions.
Devs and other people who have seen behind the scenes at large companies know that most security is at best shaky and mostly hand-waved
It’s not even really the fault of the people who pushed for these setups, it’s a seemingly simple business decision: build it in a way that looks secure, add some black-box process, and tell the overseers that the reason there are no attacks is because it’s bulletproof, and definitely not because no one has really tried
Then, when someone finally turns their attention to you and walks in: fire whoever needs to be fired, patch that specific hole, maybe spend a bunch of money on a different system, assure the overseers that it’s handled, and move on with business as usual
It’s cheaper in the long-run, it makes stockholders happy, it relieves the bosses and their bosses, and for the most part there are “no security holes”.
Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)
How to set them up?
- use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security
- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer)
- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally
All are open source / free.
If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
This feels like a very very small group of people; and people who really could do with opening the file and adding the line.
I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption.
So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
In what way is "edit your .npmrc" simple?!?
The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
Every one of those has a different opinion about how to spell "cooldown".
On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown directive in them. How do I do that with a cooldown?" (Where N is unknowable, because of course it is.)
> The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
This statement makes very little sense to me. I've worked on several of what are likely the largest JS monorepos in the world, and they all define a specific version of a specific runtime and package manager you should be using.
An extra $15 of labor is well worth the cost of not having to change my own oil. They will do it efficiently and won't break anything. The cost of messing up one time immediately cancels out a lifetime of DIY savings, and they are equipped to do it right.
> Changing your own car's oil is actually not that hard
It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance.
> Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers.
Exactly. Using a QR code app required specific knowledge of the app, an internet connection, some time, knowledge of how and when to use it, and something to use it with - the barrier of which surpassed the convenience gained from the QR code.
> So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
I'm struggling to find a non-contrived group of people who:
- do not know how to open and edit a file on their system
- do use npm
- would find installing pnpm or running `sudo install -d -m 0755 /etc/apt/keyrings; curl -fsSL https://depsguard.com/apt/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/depsguard.gpg; echo "deb [signed-by=/etc/apt/keyrings/depsguard.gpg] https://depsguard.com/apt stable main" | sudo tee /etc/apt/sources.list.d/depsguard.list >/dev/null; sudo apt update; sudo apt install depsguard` simpler
Of course, cooldowns.dev is a very long winded way of telling someone to run `npm config set min-release-age=3`, which is the simplest.
That group of people is the loosely affiliated people called "vibe coders". Even to get them to install depsguard is a challenge. I just ask them to point Claude to depsguard or cooldowns and follow the instructions (to save the tokens, of course Claude can figure it what needs to be done on its own)
The issue is that Claude Code also will be super happy to npm install axios / tanstack etc unless you explicitly tell it to add cooldowns.
Changing oil requires
> a place where you have sufficient access to the vehicle to drain it
Probably the only valid argument for people who park on the street.
> the right equipment
One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, borrow from a friend. If you can't afford $65 once to save money in the long run while owning a car, you probably should've bought a cheaper car.
> the right disposal solutions
Every oil change requires a jug of oil to be purchased. You can drain your used oil into this jug and then dispose of it along with your other household hazardous waste. This is not hard.
> Most people who have cars do not have that.
I might believe this for a place to do an oil change, maybe. I struggle to believe most, but I would believe many. Aside from that, if you don't have those things, you are choosing not to have them.
Which is kind of the point. None of these things are hard, at all. The majority of car owners 100 years ago could adjust their own timing, clean distributor points, replace belts, etc. because if they couldn't, they'd be calling for a tow truck every few hundred miles. Those are all harder, and things have only gotten easier with time. If you can't do them, you are choosing not to, because there's an even easier solution - spending more money and getting someone else to do it for you.
> One set of ramps ($40), or jack stands ($30)
Given the number of SUVs and trucks, many people don't even need these.
Good job, you forgot a new crush washer and now your oil pan will leak
In ~300k km worth of diy oil changes, I’ve yet to change a crush washer, and yet to have a drain plug leak.
I always replace them on friends’ Toyotas, because they seem more important, but on every car I’ve owned it hasn’t mattered. And if you take the least amount of effort to google “how to change oil on ________” (fill in the blank for your year, make, model), some forum or video will probably tell you exactly what steps to take, including whether or not changing a washer is necessary.
Costs me 15 cents per washer delivered, why bother risk it? The world doesn't need more cancerous used motor oil on the ground.
After downloading a service manual and doing many things myself it became very apparent that mechanics barely bother to do work the right way despite it coming at virtually zero extra effort.
It's quite rare to see them use a torque wrench on many bolts and if you ask them why "they know it by feel", cool, but why not use a torque wrench to the proper specs anyway? It's not any harder.
My favorite way to do it is in the auto parts store parking lot. They will help you cart your full drain pan back to their oil recycling receptacle and some will even prop the back door open for you to walk it straight there. The bonus being if you do happen to spill a bit you're not stuck having to power wash your own driveway. I've got a process down to where I can pull it off with one pair of nitrile gloves, one rag, and one trash bag, to keep any residue from the drain pan staining anything.
A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening
From that repo:
> Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid.
My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.
In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.
Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well.
That's where the lockfile comes in, it pins the dependencies of the dependencies.
Lockfiles serve multiple purposes. For example, some include hashes so you aren't served altered packages from the package registry. I agree with you otherwise, though.
The lockfile also handles the first-order dependencies, though. Pinning them in the manifest doesn't enforce this -- the lockfile does. And yes, I agree that the lockfile _also_ handles pinning dependencies-of-dependencies.
Yeah imo that is bad advice. In my experience, lockfiles do as designed and exact pinning in the high-level manifest makes it extremely hard to do periodic updates because you end up spending hours tinkering with pins to try to find the right combo instead of letting the package manager automatically resolve everything for you.
You end up with ancient dependencies because you add friction to periodic refreshes instead of running `package-manage refresh-lockfile` (whatever the relevant command is for your package manager)
> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown,
by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.
I don't agree that nobody is adopting them. Can you please elaborate?
- Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs
- pnpm just adopted 24 hours cooldown as default, based on community feedback.
what is the difference between these two things from the point of view of how much work you have to do?
- checking every update of every dependency to see if is a relevant urgent security update
- checking every update of every dependency to see if it turns out to be a supply chain exploit
am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.
It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
I believe the point is that if you delay patches until X days after release, usually someone will catch it and the maintainer or the package manager will pull the infected release. Thus, by you doing nothing and waiting X days, you protect yourself by never even getting the bad release. Then on the flip side, you just keep up with urgent security updates and push bad ones through faster after vetting them.
The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check if not force an update.
How often do you update your lockfiles? Where ever I have worked, it's once a year or whenever we get a critical CVE (in which case we only update the offending package and it's dependencies if required). Unless an attack is happening every day the chances of getting hit is slim.
Exactly.
theoretical question, do cooldowns still work if everyone has them?
Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.
I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
Because entire point of their work is to find the issues as fast as possible, and most importantly, before others.
You have a lot more faith than I do that companies paying security researchers will not try to cut corners by directing the researchers they employ or hire to look at stuff that they aren't even about to install.
Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down
It’s kind of insane this doesn’t happen in the publish pipeline by default.
This is what serious software distribution platforms do. Developers may think that they are special and they would never install malware, but that's just not the case.
No, it will stop working. The whole point of min age is letting someone else taste the food before you, so you are not poisoned. (except maybe scanners but they can't detect everything and the payloads will highly likely to remain dormant when it detected it's within a scanning env).
BTW it will only get much worse because popular AI coding harness (e.g. OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.
Kind of depends. If someone looses control of their credentials and notices someone using their account to post, it still might help.
As an embedded dev who’s used to locking to toolchains and deps for years at a time, web dev is a culture shock in so many ways.
There's literally no excuse - I'm still baffled.
You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not.
And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here.
I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.
I think the post you're replying to was commenting on "web dev is a culture shock in so many ways", not the concept of cooldowns overall.
I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
Caching proxies are a decent middle ground like Artifactory. AWS might support that (maybe only on certain repo types?)
Generally you can also configure rules in your internal package cache about what to do if a package is missing from the cache/hasn't been pulled yet. They also commonly integrate automaticaly CVE tracking and pull statistics so they give a nice "heads up" what everyone is using even if it's a local PoC
As an added bonus, they can also lower bandwidth bills like in expensive cloud environments when you can co-locate the proxy close to CI/build machines.
Nice work!
Is there a sensible way to add a cooldown to Docker/Podman image pulling?
> Hope it's ok I hijack this thread again about setting up cooldowns...
In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities).
It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature".
Then, for a start, a security fix becomes easier to audit (both by security researchers and by the tools security researchers are using).
And then a cooldown can be used for the regular releases (e.g. non security-related bug fixes, perfs improvements, new functionalities, etc.) but no cooldown (or a much smaller countdown) for security fixes.
Something has to be said about a system like Debian where you can have an extremely stable server and you can configure unattended upgrades to only apply security fixes but nothing else.
Such new package releases are easier to audit by security researchers.
> but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
I'm not letting gam gams anywhere near that shit. She can continue writing her own apps in assembly language - it's good for her brain health!
In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers.
That bit that's getting less conversation is the tools on the package maintainer side:
- MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing-...
- trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers
And as of recently, staged publishing, essentially combining the best of both those features: https://docs.npmjs.com/staged-publishing
Now you can: - Publish from CI, without static credentials
- AND require a maintainer to approve it using MFA before it actually goes live to the registry
If you want you can still use something like GitHub Actions Environments protection to require multiple approvals, or a time delay, on the CI side.
We need to encourage the community to adopt these publishing protections or this will continue to be an issue.
they need to make it required for everyone, and then they'll have done something
IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise.
The bug here isn't that we need to better authenticate already-trusted upstreams for packages, it's that the upstreams cannot be trusted as the sole source for security at all. Upstreams are a bunch of hackers[1] who aren't really interested in, nor will ever be good at, solid release engineering practices.
But some people are! The solution in the Linux world (and the one that saved us from xz-utils) is that there is a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. These people have different eyes, different consumer requirements and different quality metrics. And they catch bugs and malfesance that the upstreams aren't prepared to do.
NPM (and cargo/PyPI et. al.) continues to think it can short circuit this requirement for human labor. It can't.
[1] In NPM's particular ecosystem, a bunch of web jockeys used to extremely fast release processes, loose compatibility requirements, and extreme reliance on reuse. This really explains why we see this with node packages more than Python or Rust: older and more conservative programmers just don't have as many rakes to step on.
> The solution in the Linux world ... is that there is a second level of human beings...
AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it.
The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.
There is a version of that. It is called RedHat Enterprise Linux. : )
> Certainly it's only by pure luck that no malefactors have infiltrated the [pinko commie Linux hippy commune]
Yeah... no. Sorry, that's a wild misunderstanding of the economics of the Linux ecosystem, modern libertarian thought and the employment status of people with write access to the packaging layers.
> ... a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users.
> The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.
That was also what I was thinking aloud a moment ago. And there would be a business opportunity, too. Perhaps not like RHEL et al. full-blown stuff per se, but say smaller scale guarantees with different pricing; web, AI, scientific computing, and whatnot. At the pace things are progressing, I'd guess you might even get desktop etc. users on board (for nominal pricing).
But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit of that layer of review.
I don't understand why you're confident that those Github issues won't just end up coming later if literally everyone adds this cooldown
The security companies looking for and reporting the issues aren't going to use the cooldown too.
They make their money from getting paid by other companies though, don't they? It's hard for me not to imagine that companies in general will see "testing stuff a day later" as a way to cut costs or not paying out as much for bounties because of claims that no one was actually affected yet
> they very frequently get malicious npm packages taken down within a day of publishing
If I'm reading the secondarily-linked blog post correctly, this was live for 12 days before discovery.
> Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise.
Mandating that the final binary is compiled without having any access to any test file though would have prevented the xz-utils backdoor as it was conceived though.
A proper packaging setup would first verify that all the tests are passing and happen in an isolated environment. And that isolated environment either returns which tests failed or gives the green light.
When the greenlight is given (that all tests are passing), another environment should first delete all files related to tests and then build (in a bit-for-bit reproducible way btw and we're basically here already so that's good) the final binary / package.
If you prepare your final package in an environment that has access to test files, there are simply way too many ways obfuscated binary data can be hidden in test cases / test files.
I'm not saying the NSA (sorry, Jia Tan) wouldn't have tried something else but I think we should really move to build/packaging that discards non essential data/files before compiling.
P.S: note that as a side-effect of reproducible builds... If we have reproducible builds and if we add, later on, a builder/packager that discards tests files and ends up with a final package that's not bit-for-bit identical to the package created while having access to the test files during the build, we've just detected a backdoor hidden inside test files (like the XZ utils one). As a really mindboggling food for thoughts: if we were to recompile all the Debian binary packages that are already reproducible today (95% of them), but while discarding all tests files before the build, we may catch other backdoors.
> Mandating that the final binary is compiled without having any access to any test file
It would, but I'm not seeing that as a suggestion? That was a very clever side channel for hiding the build-time payload. It wasn't remotely the "root cause" of the exploit, which was that a malicious actor got write access to the release process of trusted software. I mean, if you can do that, you can surely find other clever ways to hide your junk.
To wit: you're not wrong, you're just stuck on minutiae. By all means make the case, but at best you're proposing a small constant factor optimization.
My read is that there's a crowd that is unimpressed with mechanistic changes when in their view there is a cultural issue.
From the outside looking in, web dev has this frantic wild west energy to it. Mutability, dynamic typing, standards changing constantly, frameworks changing constantly, continuous delivery, CDNs, live A/B campaigns, large numbers of dependencies, sensitive user data spread out across a lot of infrastructure.
I'm not saying that's an accurate view and I don't think "I told you so" is the right attitude, but I can understand the place it comes from.
> - MFA for publishing: <a href="https://docs.npmjs.com/requiring-2fa-for-package-publishing-" rel="nofollow">https://docs.npmjs.com/requiring-2fa-for-package-publishing-</a>...
> - trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers</i>
According to [1] "All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised."
So the malicious package would have gotten the happy little green star, with users assured it was "Built and signed with provenance."
[1] https://lwn.net/Articles/1075742/
Why doesn't Java seem to have anything close to this issue? Isn't it a solved problem?
No deep dependency graph, so easy to audit and inspect. Stable development process, so easier to manage the flow of updates. And I believe a more cautious ecosystem. Not everyone is rushing to create or adopt new libraries, especially for what could have been a single file. So most libraries are about solving a domain, not just one single algorithm.
Same thing with C, Perl, PHP,…
> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
I mean it keeps happening lmao. You can track npm attacks these on a calendar. Someone made a npm parody of the classic "no way to avoid this" The Onion article.
It's great there's work to stop it all but also... it keeps happening. I find it funny in a "here we go again" way.
>> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
> … the classic "no way to avoid this" The Onion article
But isn't point of The Onion article that A) the US has >50x as many incidents as the rest of the developed world combined [1], and yet B) acts like there is "no way to avoid this". Does NPM have >50x as many incidents as the rest of established languages combined? Is NPM claiming there is "no way to avoid this" or are they putting in place things like automatic install delays?
While all the major js package managers already support install delays, none of the big local C#/dotnet/nuget apps do (Visual Studio/Rider/nuget/dotnet/VS Code). https://github.com/NuGet/Home/issues/14657
[1] https://edition.cnn.com/2018/05/21/us/school-shooting-us-ver...
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days).
https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
What happens when everyone adopts this policy? You just change it to two weeks?
You rely on the security companies scanning the packages.
Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.
I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package.
None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
It works because there are multiple companies doing it and double checking the results.
For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends.
There is still a lot of human analysis that occurs in making the call that an attack is occurring.
Yeah, this is the part that I don't get. If the solution is "security testing should come before people install it", why is the big push to have people intentionally add this artificial delay to install later rather than moving the security testing earlier to before the release? If you want to make people not drive on the road until the pavement dries, you don't try to convince everyone to push back their workday by an hour; you just lay the asphalt an hour earlier.
Then the ... malware will just add delays? Or do they really do manual in-depth analysis of all new code? Just running and seeing it do things is probably a lot easier.
Security scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for.
I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.
@exitb it is much more desirable for security scanning companies to compete to find issues in a timely manor. If npm blessed one as a gatekeeper to the whole system they would be between a rock and a hard place. Unable to priorities high impact packages over the long tail of packages no one uses without pissing people off. Unable to add experimental new detections that may be a little noisy at first due to the huge disruption it would cause. Be trivial to game as obscure packages could brute-force their way though then use the same hole on a mainstream package.
Always one day more than people on HN tell you. If something is compromised you will hear people complaining here that three days is not enough.
A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.
Would be nice if cargo had a cooldown flag and could respect lockfiles by default.
min-publish-age in cargo is coming:
https://github.com/rust-lang/rfcs/blob/master/text/3923-carg...
The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level.
There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period.
To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.
Thank you for the thorough response. I got the following from yours and other responses:
* The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread.
* This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well.
* Maybe NPM should run scanners before distributing malware?
* If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.
> Maybe NPM should run scanners before distributing malware?
I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited.
So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.
Look, nobody requested fully automated scanners that are never wrong. A scanner that asks the project owner to sign in with 2fa and confirm the release in case it's been flagged is going to be more than sufficient.
There's a really bad implicit assumption in there: Microsoft's scanners have solved the halting problem, so they can tell if a package update will ever flip to malicious mode, or has an intentionally inserted security hole in it.
Of course, this also assumes that Microsoft's internal scanners are much better than the scanners available to the attackers, since any reasonable attacker is going to just run their obfuscated code through a scanner as part of their CI job. (And maybe even use the MS scanner as an oracle by submitting fragments to NPM to see which pieces of their exploit chain get flagged.)
Waiting until everyone else canaries is much stronger, but even that doesn't work on a targeted attack.
This will never happen unless it's made the default. Most people will always stick with the defaults.
Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.
uv supports the same for any Python developers out there: https://docs.astral.sh/uv/concepts/resolution/#dependency-co...
And somehow poetry doesn’t in 2026.
so? nobody uses it anymore
I don't use poetry anymore but do check the updates before claiming such things
https://python-poetry.org/blog/announcing-poetry-2.4.0/
May 3rd 2026. Release too new, didn't read.
Fair, I didn’t do a “as of this morning check”. Should’ve done better. It’s sad because I moved away exactly because this feature was missing and now I’m not going back.
pip has recently added a similar option, i.e.
`pip install --uploaded-prior-to P7D pre-commit`
https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-upl...
Sadly I haven't seen that Visual Studio/Rider/dotnet/VS Code have such a feature for the C#/dotnet/nuget ecosystem.
Yep, a bummer. The devs don't even consider it a priority, too busy designing the feature:
https://github.com/NuGet/Home/issues/14657#issuecomment-3573...
There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.
I’m having a real problem at work with security theatre and the growing push to obsess over numbers of “vulnerabilities” in our projects. And then auto Dependabot PRs that encourage churn to fix issues that if an informed person actually reviews easily concludes it doesn’t affect us in the slightest.
"maybe high and critical vulnerabilities don’t need to be a minor version upgrade"
huh? what do you suggest instead?
A separate pathway to updates. At the moment there is a pressure to keep all the packages updated at all times. Every time a new version of a random package deep in the dependency tree gets published, you roll a dice: is it a bunch of bug fixes that I don’t care about or a vulnerability patch that need to apply immediately? Since it could be either most devs just auto pilot on updates. This creates an environment where newly introduced vulnerabilities get promoted rather quickly before the version matures. Sure, waiting a few days to update a package sounds great, but there is no guarantee that the vulnerability will be found quickly.
To give you a context, I get 20-30 PRs a week across all my repos with potentially hundreds of packages (non distinct) from dependabot. I give it a cursory look and try to get a summary of changes. Do I evaluate every single package update? Nope.
Huh? Sorry but both of your comments are frankly incoherent. I have deep experience maintaining large dependency graphs and empatjize with the frustration about CVEs in deep transitive deps, but I can't make head or tail of your "separate pathway".
`pnpm` also has that and it's on by default since `v11`:
https://pnpm.io/settings#minimumreleaseage
It’s on by default in yarn 4 too now, but pnpm was the first to market that default minimum gate.
https://github.com/yarnpkg/berry/pull/7135
If this were a universal default, would the strategy defeat itself?
No.
Many places run analyzers on published code; many security users have reason to shorten the period. The default period becomes the period where white hats have a chance to detect it and stop it passing the threshold.
Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)
Then shouldn’t the analyzers just be part of NPMs acceptance requirements?
That’s my point. For whatever reason, npm isn’t doing it. All npm users adding a minimum package age is kind of like doing it as a collective, without npm’s help.
I think if they did it, then attackers would be able to iterate their attack against their own project, and once it passes the filters they could deploy for real.
I guess it could work better if it was enabled for only actual attack vectors projects.
pnpm also support this
The gist link above covers how to use it in yarn, npm, and pnpm
npm supports this now as well, with e.g. `min-release-age=7` in `.npmrc`
not if you have internal repos?
I think you can set it on internal repos, but then you need to allow-list internal code. People act like this is simple + solved, but it's not. It turns into 100K-1M's of LLM tokens on a semi-regular basis, or "just hire a build infra team for your side project" pretty quickly.
Why not the other way around, I man by default and can be changed.
The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev...
The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac...
The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope...
A student researcher took over Python ctx and PHPass package maintainership, pushing out malicious changes, and that took over 7 days to be detected and fixed: https://infosecwriteups.com/how-i-hacked-ctx-and-phpass-modu...
Kaspersky found multiple PyPI packages that had been exploited for more than a year: https://www.kaspersky.com/about/press-releases/kaspersky-unc...
"LoftyLife" packages were exploited for several months: https://securelist.com/lofylife-malicious-npm-packages/10701...
Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.
> Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.
Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.
Instant attacks are much easier and more common than delayed attacks. Security is an onion.
Ok so no external dependencies, or pull versions from 2021 and apply security patches?
- Best practice for both reliability and security is to not immediately upgrade to latest versions. Only immediately upgrade to security-patched versions. If your software doesn't need a new version, you can remain on the old version.
- When a feature you're developing, or a transitive dependency, requires an upgraded version, you can upgrade to the latest stable version that satisfies the dependency. But as each of those then requires an additional transitive dependency to be upgraded, you have more and more components upgraded to "latest", and the attack surface widens. So there are two alternatives:
1) (preferred) Upgrade to the latest version of the next-to-latest minor version, within the oldest major version that is supported, if that is available. This is the least number of changes that provides the needed functionality.
2) Upgrade only to the oldest version that gives you the functionality you need. If this ends up being the first version of a new major or minor version, this can cause bugs (initial releases of new major/minor always has bugs), so in that case you might as well use the latest version of that major/minor version.
This all affects security by avoiding upgrading to the latest version. It affects reliability by minimizing the amount of changes between your current version and upgraded version (changes lead to bugs).
The argument against all that, and for always upgrading to the latest versions, is intended to make software development easier. You avoid all the complexity of picking versions or reading changelogs by using software that is probably (but not always) all compatible. But it makes reliability and security worse. So you need to choose: do you want security and reliability, or an easier time writing code?
it would be way easier if dependencies were a flat list and not a graph, aka peer in npm parlance. I believe that’s what go does. A library only need to say that it depends 1.x.x or 1.2.x and it’s up to the application to provide it. Conflict is handled manually.
The onus is on libraries developers to cleanup their act. Start vendoring code instead of depending on hundreds tiny libraries.
If everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?
Vulnerability scanners and security researchers would be looking those first 3 days
Most attacks are discovered 'pretty quickly' via scanning services and groups that monitor repositories. The problem is even an hour gap could mean tens of thousands of downloads and executions.
Just some suggestions:
1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs.
2. Anywhere you have `npm install` or `npm test` or anything where code executes, that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern.
3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture.
(2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks.
There are some vendors in this space that you can and should evaluate as well.
> anything where code executes
ALL the agentic orchestrators like codex, claude-code, etc. seem to do this by default.
Exactly, popular AI coding harness (OpenCode/KiloCode) downloads random npm packages in the background without you knowing. What's worse is the devs don't care.
With coding agents, npm install can become a side effect of "make the tests pass." That feels like a very different risk model.
>install the latest version of zizmor.
What if it gets compromised?
More of a joke. But was funny after saying that new packages should be delayed.
lol yeah I thought of that as typing but figured I'd avoid the complexity. "latest version" means, give or take, whichever the latest one was that contained a bunch of new rules around supply chain stuff.
Should we instead of these cooldowns just run builds in isolated contexts?
I’m running a maven proxy locally. All builds happen inside containers. I only use public repos for python, npm, and go. So these builds happen also in containers but don’t need a repository proxy.
> Should we instead of these cooldowns just run builds in isolated contexts?
I'd suggest both. Cooldown for 1-2 days is very cheap and you likely won't even notice it, so it's quite harmless and from what I've seen even just 24 hours is enough to let security companies pick up malware.
But yeah, isolation is a must-have.
At this point, is there an obligation of package managers, or at least npm to arrange the sandboxing themselves?
Or as us or companies to wrap the build tools to provide the wrapping for them.
Oh, absolutely they should do that.
Hmm, same day as RH and IBM announce Project Lightwell to help detect and fix supply chain vulns.
https://www.redhat.com/en/lightwell
That was a few days ago: https://news.ycombinator.com/item?id=48313577
I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.
I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.
DUB , for D Lang does that.
Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.
I mean there’s nothing stopping you from committing node_modules to git (after running something like https://github.com/timoxley/cruft on it) and reviewing code changes on dependency updates.
I even managed to make that part of the workflow on one team I worked with but several other teams since thought it was a crazy idea. :)
It's a generic and very old term for committing dependencies to your repo, it's not go-specific.
The problem would be the dependencies of your dependencies, and keep going many levels.
But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation.
That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.
> Trust is built on vetting, signatures and reputation.
https://news.ycombinator.com/item?id=47017833
Well, now with an irony, but sadly, of course.
Would Red Hat be considered a trusted/reputable vendor? :-D
The problem is that node.js doesn't have a good standard library so one must rely on external packages to build even basic apps.
Can you tell us what exactly is missing? A network api? Process execution? IO? Math?
From this we can see a few patterns: https://www.npmleaderboard.org/
Node.js doesn't have good support for regex, handling files, streams, serving static html, routing, operations on lists/dicts.
That might change the odds, but unless you fork diligently (and monkeypatch each and every future vulnerability) you might ship a compromised fork forever.
Except most of the attacks so far has not landed actually source code changes to git IIRC. They have targeting the release files directly.
Software vulnerabilities are often not placed maliciously, and are present in the original source. If you don't patch them if discovered later, you'll be vulnerable to them.
Yes. Isn't that "giant PITA" is referring to here?
> your own repo reviewing and merging from upstream as needed. Would be a giant PITA though
The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.
Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go or Python projects generally only include a handful of external packages. Node projects on the other hand…
My requirements.txt does tend to be shorter than package.json, but not by a massive amount.
Hum... You should check your JavaScript numbers again.
I have never seen a project that uses npm and has only dozens of dependencies. Normal numbers are in the 10s of thousands (including different versions of some deps).
So be more selective with your dependencies then. Next.js is usually a mistake.
Shouldn't you also restrict version number for a package not just the latest?
Built Packj [1] to audit dependencies easily from CLI.
1. Packj (https://github.com/ossillate-inc/packj) detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).
Some of us have been doing this for years or decades, including for our desktop OS.
Gentoo graybeards know.
About a week ago, I uninstalled Node from my laptop, which felt great. :)
I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir.
Cooldowns and allow-listing of installer scripts are good additions to layered security, especially for CI. However, I think the fundamental thing that needs to change is the OS permissions model. The default of trusting third-party software with everything your user has access is no longer workable.
Are you using something like Bubblewrap/Firejail/Flatpak, or what does such a setup look like? I've been entertaining a similar idea for a while but haven't gotten to it
I'm using VSCode dev containers, powered by Podman on a Mac. Most people would probably choose Docker over Podman but I'm weary of Docker and wanted to try something else. I would not consider myself an expert on containers but with the help of Claude I've been able to fight my way through various challenges:
* Persist a volume for Claude so that conversations don't get blown away with every container rebuild. An attacker may still be able to get a Claude token from me, which is something I'd like to tighten up in the future.
* Fix file permissions issues by running rootful inside the container. (The container process still runs on the host as an ordinary user. Since my threat model is "compromised dependency scanning for credentials in project dir and home dir" rather than "attacker escaping the container", I figured that was good enough to get started.)
* Work around architectural availability issues with precompiled PyPI libraries. This I punted on by choosing a different approach and eliminating the problematic dependency (by writing my hobbyist CAD 3d printing stuff using Blender extensions instead of CadQuery). I've gotten the impression that dependency compatibility with a container workflow is an ongoing challenge.
* Run a database in a docker-compose sidecar for integration testing.
For all the projects I'm containerizing I'm the solo dev with full control over the Git repo so I can make the call to add a `.devcontainer/devcontainer.json` config file. I haven't yet explored how to isolate projects I don't control.
Should link to the original announcement I think:
https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...
Yes. Also Red Hat is misspelt in the title.
I'll be honest, I have always found the "trusted" publishing concept quite suspect -- the boiled-down argument is that developers are too incompetent to manage their own keys. Yes, there are obviously problems with storing plaintext publishing keys and tokens in $HOME, but that isn't the only solution. You can use hardware keys for signing (I would wager a lot of open source maintainers have at least one Yubikey or NitroKey kicking around -- they used to give them away at conferences) and for upload tokens you can even just password-protect them or require them to log in each time.
The alternative proposal with "trusted" publishing is to grant all of GitHub's automated infrastructure the ultimate authority to publish things on your behalf automatically in a way that it is shown as being more "trusted" than the developer uploading it themselves! I'm honestly surprised that it took this long for supply-chain attackers to start targeting this obvious security hole -- I doubt any user of GitHub would argue that GitHub Actions are a parogon of security, and yet the strongly recommended deployment workflow for several language communities involved bolting it into the core of your release mechanisms! I think the OCID stuff is interesting and provides some nice properties but it doesn't prove that the GHA workload is actually trusted in the sense that "trusted publishing" means.
The arguments for adding speed bumps to auto-applying updates apply just as much to adding speed bumps to doing releases (arguably even more so -- even rapidly evolving libraries don't have hundreds of releases a week). Automating everything to the nth degree just expands the blast radius when stuff like this happens.
I do all runc releases manually and sign them with a PGP key stored in a hardware token that requires a pin for every signature attempt. Yes, it's a bit more cumbersome but it certainly would be harder to supply-chain hundreds of projects of every maintainer would need to manually publish them. For some other projects that need to publish to crates.io or PyPI I was honestly a little dismayed at how prominently they push for "trusted" publishing and how little support there is for making the "dumb" publishing flow more secure (they even visually display such releases as less trusted, and the only way to get more green checkmarks is to let GitHub take the wheel).
I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago
Yarn 4 can automate this
In case others are unaware, you just have to set https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate to the value you want. It defaults to 1 day.
If supply-chain security is a concern yarn is the worst js package manager you can pick. It comes far down their priority list, below "just make things work without need for user input". Whatever you thought you configured will simply be ignored many times and that's considered a feature.
Go look in that projects issue tracker and commit log for changes to relevant configuration and you will know what I mean.
Even yarn 1.22 is a safer choice.
I just use `pnpm` and set up a liberal `minimumReleaseAge`: https://pnpm.io/settings#minimumreleaseage
Thankfully, it's on by default since v11.
If using straight npm (v11.10.0 or higher), you can just add to .npmrc in the project root:
min-release-age=5
If you use npm 11, you can simplify your workflow by setting min-release-age to 5. https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.
I don't follow your second sentence. Doesn't npm have the opposite problem of 'not invented here'? By adopting many external packages rather than developing in-house, npm projects tend to have large, complex dependency trees. It has long been the complaint that packages such as https://www.npmjs.com/package/is-windows create potential vulnerabilities and maintenance headaches, when writing the same piece of code directly is so simple.
One common fallacy of the NIH folk is that reinventing X package would take a lot of time.
But first, you will of course not remake every single feature, just the one you need.
And furthermore, when you code just one feature, you don't need to make any abstraction or additional function interfaces. So it's cheaper, and probably better integrated.
Another fallacy is that you'll make bugs and introduce vulnerabilities. Maybe, if you are a bad programmer, but you will also avoid a category of bugs where the vuln is introduced at the boundary of the integration between two different libraries that weren't designed to fit exactly together. (Many such cases)
One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime
Some packages need to build native dependencies. sharp for example needs to build libvips on the system [0] to work
0: https://github.com/lovell/sharp/blob/main/install/build.js
I’ve always felt this automation shouldn’t exist at all, but should rather be selectively controlled via a hook. The hooks yarn offers out of the box for example can be used to run any code you need to after install. Putting the project owner in control instead of the dependency.
Nuget/.NET ecosystem just handles it so much better. Netvips assumes libvips is available and they provide packages for common platforms. No need to waste electricity rebuilding stuff, or install native build chains, build and test deps. Similar for Skia or Sqlite or whatever.
but how can you verify that the prebuilt binaries aren’t compromised?
Out of interest, do you verify that every single binary file on your machine isn't compromised? All the packages coming from your package manager?
I absolutely don't. I even sometimes use "curl | bash" to install new things on my machine because most of the time it's easy and I tend to trust the authors.
My point was just that I don't think moving to pre-built binaries solves this issue.
sharp downloads over https and checks the sha256 (I think?) of the archive.
sharp does this too:
https://sharp.pixelplumbing.com/install/#prebuilt-binaries
it can sometimes need to compile the C++ shim that sits between node and libvips, but that's rare.
sharp does not rebuild libvips, it downloads a pre-compiled libvips for your platform.
https://sharp.pixelplumbing.com/install/#prebuilt-binaries
It can usually also download a precompiled binary for the C++ shim that sits between node and libvips, but if your node / arch / etc. is not supported, it'll compile that (that's what the build.js file you linked does).
I turn off running scripts on installation. So far, no inconveniences.
Some packages with native code components (like sharp) will use these hooks to download the correct precompiled native binary for you.
Qubes offers the strongest protection against these threats. It's surprising it isn't more commonly adopted.
https://qubes-os.org
If this is what will take for folks to move away from JS ecosystem, I'll take it.
Bah, I think that these kind of vulnerabilities exist in any "packaging ecosystem" where the base language offer "ambient authorities"(any library can access your filesystem) which is .. all of them! AFAIK only research languages do not provide these ambient authorities :-(
This x1000. This is the culmination of 15 years of frontend dev culture. Why does RedHat even have an NPM repo?
Seconded
I am not a JS dev, but had to interact with the ecosystem some. It became so bad I won't install anything without it being in a Docker or Podman container.
I honestly don't understand how you could do JS on the backend in 2026. This language and ecosystem are so bad it's ridiculous. Almost all other options (yes, even PHP) are better.
On the browser at least you have the excuse that there's no other option (hoping Wasm will eventually kill JS for good, but we're not there yet).
We have done the complete analysis and there are 32 packages share the same publishing pipeline. https://safedep.io/redhat-cloud-services-hit-by-mini-shai-hu...
Npm is just borked by design. I hop it will take javascrip with it
I would like to meet the person behind the "postinstall scripts" idea and try to understand how they thought it was a good idea.
Y'know just to talk a little bit
This is a completely unexpected turn of events that no one could have possibly foreseen.
Red Hat security bulletin on this incident: https://access.redhat.com/security/vulnerabilities/RHSB-2026...
Quote:
> The affected packages are frontend libraries that are compiled and bundled into some container images during the Red Hat product build process.
So you might be affected if you deployed any Red Hat container images built after the compromise, I guess. (I doubt anyone besides Red Hat is using the affected packages directly.)
Given they use nx my bet is on developer laptop compromise through the nx vscode extension that also compromised GitHub engineer's laptop
the security of their packages should not depend on one laptop being compromised
That’s why I switched to Java.
…. lol
Yeah but you don’t have to use that I think. I think us Node people can just pretend to write Ecmascript 2 in Java and be fine.
https://dayssincelastjavascriptframework.com
You are absolutely right. The dangerous part of NPM packages is the post-install script. Therefore moving from JavaScript to Java removes the threat.
You joke but, yeah, when you think about it, the problem with Javascript is the 'script' part. That's actually correct.
Meh maven plugins are just as juicy a target as npm is
What do u recommend?
https://github.com/s4u/pgpverify-maven-plugin
If you want paranoid mode, you can verify literally every part of the maven build process.
I also commented on the other issue flagged: https://github.com/RedHatInsights/platform-frontend-ai-toolk...
Also detonated the payload: https://leitwacht.eu/blog/valid-provenance-malicious-package
Lol.. yet again npm and install-scripts abuse at play.
Updated:
1. All exploitation techniques used since May 2025: https://npm-supply-chain-attack-techniques.pagey.site/
2. All attacks that happened since May 2025: https://npm-supply-chain-attacks-25-26.pagey.site/
GitHub repo (800+ stars) on a list of tips for protecting against npm supply chain attacks: https://github.com/bodadotsh/npm-security-best-practices
There's no magical solution, you just have to use (WAY) less dependencies
Chainguard based images, packages and libraries are first line of defense. Expensive? Yes. Foolproof? No. I think these types services will be mandatory in the near future.
How would that help? These are not general purpose, base system libraries, these are libraries specific to a product that uses them. Either you're not using them and hence they would not be installed in the first place, or you're using them because you have the product installed.
Though I would expect that Insights uses RPM packages to ship components and not the public NPM packages.
it wouldn't surprise me if insights was in fact a wrapper around npm install
https://access.redhat.com/articles/7139622
Podman? Podman for OSX comes with a login item from "Red Hat, Inc". Anyone know how to check if this subcomponent utilizes these npms?
Looks like RedHat got compromised by a Black Hat…
There is some effort to make NPM more secure https://github.com/npm/cli/pull/9360.
The entire ecosystem is cursed
Always has been. I remember poking fun at it 15+ years ago (queue the 'MongoDB is web scale' meme video).
It will only get much worse because popular AI coding harness (OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.
Setting min age is useless if everyone is doing it. The whole point of setting min age is make someone else take the bait before you.
It isn't useless. Security researchers are the ones catching a lot of these and they will certainly not wait 3 days to inspect a package.
The joke is on you NPM! I only use CDNs for my JS libraries.
Is this more secure?? I would genuinely love to know
Yes, none of npm's lifecycle hooks. You're just pulling bytes over the wire.
Except now you're making http calls to remote servers that could be compromised.
As long as you embed it with an SRI integrity hash, you're safe, even if the remote server is compromised.
Can be mitigated, as the sibling comment points out, but even in the situation you described, the blast radius is reduced, especially for frontend libs.
This is a solved problem.
Use HTTPS and use the integrity attribute.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Also, what's more likely? Someone hacking jsDelivr/cdnjs OR some random NPM packages getting hacked?
Yes (assuming they're doing frontend dev and including the resources from the page). The code is fetched and executed from the browser, so It'll have to escape the browser sandbox to do something nefarious.
Same. I came back to do a little frontend work a couple of years ago and was horrified by the replacement of script tags with subresource integrity with npm and bundlers.
Cool down sounds good until everyone does it and the issue isn't caught until afterwards
Question - is there no way to catch these criminals?
It’s difficult to determine which individuals are involved and even if you manage to do that they almost certainly live in countries without extradition.
I'm refactoring all my personal and research projects to utilize pure HTML/CSS without any dependency of JavaScript. This was always on the table but the cybersecurity risks from all programming languages and frameworks have increased due to AI.
I know of fundamental issues with JavaScript and see no reason why it's still standard on all web browsers.
As a dev mostly working on Node. Those are scary title to read
The combined features that make npm particularly vulnerable:
1) Update by default. Manually updating your package references is annoying and does lead to other security issues as you don't automatically get latest, but it makes this risk much lower.
2) Code executed on install. Statically-typed languages don't run the code until you use them, and that might not happen on the developer machine at all for first run after upgrade, it might be a lower-priv test-server.
3) Culture of many tiny modules (this is good! It's the natural way to fight NIH! Yay modularity!) means many more points-of-failure for security for this kind of attack.
It's becoming laughable how frequently this is happening. Wow.
Throw the JS ecosystem into the sun at this point.
This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if another malicious security update happens again.
So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that.
[0] https://github.com/RedHatInsights/javascript-clients/commit/...
This seems to be sinister
Oooh now I'm wondering if this may have contributed to their Docker image distribution service getting disrupted earlier today... https://status.redhat.com/incidents/jn6r256zc62c
Same actors again?
man we gotta do smth with preinstall hooks atp
Can someone give a tldr on why this happens so much with npm ? I can't recall seeing this with any other package manager. Is npm just the default used these days and therefore sees this more often?
In addition with my usual rant about the current situation with most devs that now want to use dependencies in prod almost the day that they are released, there is something else that I just realized. A big part of the problem might be attributed to Github and the modern CI/CD frameworks.
Before, the source code was located somewhere, and the CI was usually located somewhere else, and slightly unrelated. At first, the CI job was to build ("privately") the artefacts, and they were manually released and deployed by maintainers and owner of software projects.
Then, it became the norm to have the CI located within the VCS file and the VCS located source code controlling the CI. For example having "script"/"description" of the CI actions located within the VCS itself.
Then, Github killed the CI/CD software market by offering "actions" almost for free and totally integrated within Github that was already widely used.
But still, for a long time people were wary to put tokens and security keys in Github and "public" CI/CD jobs and services.
And then, a few years ago, it became the gold standard also... You would look ridiculous to manually sign and deploy new releases with well guarded keys. What is expected from you is to have all your aws, github, ... secret api keys loaded in Github, and have your deployment and infrastructure provisioning automated with ("public") github accounts. All to be deployable in a second of a change being pushed.
So, obviously, the moment a hacker get control of a Github account or Github API keys, it is game over for the entire infrastructure.
Here I only referenced Github, but the bad things that it taught us became the norm and now these patterns are replicated everywhere (Gitlab, ...)
When will npm issues stop ? This has become a big pain !
Human society, and our technology, is a fragile system built on our hubris, a cheap replacement for the Divine Eye of Providence.
Violence!
At some point, they need a new system for these "packages", you've got to be insane to install any of these right now.
'No Way to Prevent This,' Says Only package manager Where This Regularly Happens
Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.
I think this is a thought-terminating cliche, and false equivalences. Stating "This area where problems occur at a high rate is not a problem, as problems can happen elsewhere too" is a curt dismissal of a valid concern. It implies the course of action, rather than to address a high-problem area, is to ignore any solutions which aren't global, or equate it to lower-incidence areas.
You bring up a good point that this class of problem, or related ones can occur with other package managers. It was frustrating how long it took the Crates.io team (Rust manager) to address name squatting, in what appeared to be a "no perfect solution exists, so we won't act" line of reasoning.
It's the exact same logic people used for Apple computers back in the day. The idea that Macs didn't get viruses because they were inherently more secure. But that wasn't true. It was purely a numbers game. Windows' popularity was so far off the charts that hackers naturally targeted Windows users instead of Mac users; it was just a better use of their time. The same thing is happening here. Other package managers do get compromised, but the sheer frequency of npm incidents just reflects how overwhelmingly popular Node.js and web apps are right now. JavaScript simply has a much higher usage rate than most other languages.
It was a reply to "only package manager where this regularly happens". Anyone who thinks it can't happen to them just because they're writing Python instead of Javascript is in for a world of hurt.
The comment I replied to is a literal meme. That's as charitable as it gets. Nothing "thought-terminating" about it.
While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself.
Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than NPM which puts the malware in the trusted/default/automated path.
I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
Depends on who 'you' are. I have one package I installed from the AUR and it's from a corporation that just repackages their builds. The problem is always who vets the packages. I trust the Arch team and I trust that one corporation. Also to use the AUR it's a different command, so I can't get surprised by an AUR package. It's not a pacman -Syu is going to pull in a new unknown to me AUR package.
It's putting the responsibility on the party most capable and interested in evaluating the packages for security.
I'm not tarring Arch, I was praising it. I made sure to explicitly spell out the "User Repository". Arch is the one that does it right.
Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?
They didn't back up their meme with real commentary because they have no real commentary to stand on:
They're spreading cheap disdain & scorn for npm ("only package manager" framing). But most other package management systems have similar abilities to run pretty un-sandboxed code.
TrapDoor has hit python, rust, and js repos. https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...
One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and pointing to a different package repository URL.
If there's some change that must get out sooner, then there can be some fee to pay to npm to have their security team do their own review.
Critically, there must be time for someone to review before it's the default to be selected.
I'm sure there are issues with this, this was off my head, but it seems like a really easy step to at least stem the problem for now. And there are a bunch of ideas like this that would help, but NPM doesn't seem willing to take it seriously as an existential threat to the ecosystem, rather than taking trivial steps.
> where it can be reviewed
> Critically, there must be time for someone to review
By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here.
Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have nothing of the sort. PyPI, Rubygems, crates, npm, it doesn't matter. I can just make an account and push whatever I want.
These package managers are like this because that's what developers actually want. They don't want to deal with Linux distribution maintainers in order to get their software into the official repositories. They want to just run $packager push and have it out there with zero friction.
Indeed, my sentiment also, which I posted elsewhere:
https://news.ycombinator.com/item?id=48358080
As discussed elsewhere in this forum, these exploits are being found by security companies in the first few days after they're published, that's just already too late. For example, the auditor who made the very post that we're discussing! For another, many security-focused AI companies have automated checks on NPM packages. Many people are implementing it on their end by having their client wait seven days before pulling new packages, but that's O(N) rather than O(1), and it's not evenly spread.
If no one reviews it and it still gets out, then we can address it then, but that seems much less likely.
Ideally, the solution is that all of these language package managers need to get serious and have maintainers, but lacking that, at least having the waiting period be built into the server instead of the client is a clear win.
Nix enters the room.
(Everyone claps.)
It's far far harder to do something exploits like this in elm because effects are tagged. There are solutions out there.
IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable
That changes nothing. If you're downloading packages pushed by randoms, then it's vulnerable. There is no escaping it. Go's module index is filled with people's GitHub repositories. You have no idea what's inside those things unless you review the source yourself.
https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.
And all of them "thought" of security as an after-after-after-after-after-thought.
Most of these are now building upon techniques that have already been exploited since past 1 years. This attack used 4 of those techniques.
1. Lifecycle Hook Execution
2. CI/CD Identity Plane Attacks
3. Maintainer Account Takeover and Malicious Publish
4. Self-Replicating npm Worms
https://npm-supply-chain-attack-techniques.pagey.site/
Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.
You can have a security solution but with large ecosystems like this it can’t be pushed to the ecosystem immediately and everyone will take longer to test and deploy.
Right now you could audit packages and make sure you don’t get the latest version
PyPI and Cargo are, 100%, vulnerable to this same class of compromises. That NPM sucks isn't a statement that everyone else doesn't.
People make this joke often. It's package managers and how loose we are with installing them, not NPM.
Cargo,PyPi,Nuget,PHP has had these recent too.
It's not just only NPM. It's frequently repeated here just cause of the average bias against Node.
But this problem isn't isolated to NPM.
The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem.
We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library.
We should have rules that we install the latest that's older than three days.
We should be running "npm audit" and other stuff like Trivy.
The three day rule alone could save most people.
> The three day rule alone could save most people.
The three day 'rule' is just you hoping that someone else does some free work for you. If it is adopted by everyone, it has zero effect.
We need rules that still work if people follow them.
nuget have targets, and allow to run code on build, it doesn't have this problem because there is less dependencies.
It is the same for Crates.io and PyPI they also supply scripts without asking the user so opening an IDE will run them. For PyPI you need to even execute scripts to discover the dependencies!
> but NPM makes it dangerous to merely open a project up in an IDE.
It does not. Opening a project in an IDE has always been dangerous because there are about a thousand language server and analysis tools that run in the background. This is why IDEs ask you whether you trust the contents of a repository.
An even if some automated background execution initiated by the IDE doesn't get you, running `npm run test` 15 seconds later will.
Pip, Composer, RubyGems, NuGet, and several others have lifecycle scripts.
As of course do the OS managers -- apt, yum, Homebrew.
How many package managers allow executing arbitrary code as part of the installation process by default?
Almost all of them.
I haven’t seen this in Go or Java?
Ok, so you are right, Go and Java (Maven, at least) doesn't have this issue.
> It's frequently repeated here just cause of the average bias against Node.
It’s frequently repeated here because NPM is where it keeps happening over and over and over and over and over and over again.
In short, the problem is `npm` not NPM.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of other security settings, like minimum age, no trust downgrade, etc etc.
All attackers can attack packages by updating how a package functions; but npm is particularly problematic as it runs non-sandbox scripts as the calling user. Putting not just your project at risk, but your entire machine/network.
And this stuff has been known about for YEARS, they've taken no action.
> since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
This is semi-common and in no way unique to NPM.
And even in the ones that don't, having to wait until the project executes to begin its attack is a minor inconvenience for malware.
What other package managers do this? I don’t think Ruby does
https://docs.ruby-lang.org/en//master/Gem.html#method-c-post...
Python does too I believe.
Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly.
The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.
A lot of packages are pulled in to call minimal bits of the actual library. I obviously don't have any statistics on this but my instinct would say that for the average application only 5% of an average package is actually used.
So not running package installation scripts is a huge, massive problem.
So what? Packages can just put their backdoors in some initialisation code that is always used.
It is possible that not running package installation scripts could improve security, but for that you need really good sandboxing/compartmentalisation of library code, e.g. with CHERI, WASI component model, or if all of your code must run in a secure context it probably helps.
But those situations are unfortunately rare in my experience.
It doesn't matter how much of the package you use. Here, you can use literally 0% of Koa and get pwned by one of its transitive dependencies (koa > cookies > keygrip > tsscmp) by simply importing the parent package:
--- pwned by a transitive dependency ---
My point was for proper package management tools that don't allow running scripts.
His example did not involve running any post-install scripts.
Most of them? Ruby gems have hooks, Python has setup.py, deb, rpm have them too (relevant if you're installing from 3rd party sources). Elixir/Mix doesn't technically execute code on install, but your language server builds the dependencies as soon as you open the project, which can execute arbitrary code.
Either way it misses the point, nobody just fetches code and removing post-install scripts wouldn't change much because you're going to run `npm run something` 5 seconds after you run `npm install`.
You're right. I said the same thing and got downvoted too. Don't let it discourage you.
>Putting not just your project at risk, but your entire machine/network.
Between average hackers and extortion groups, foreign governments and state sponsored actors and last but not least my own government, I don't think there's much room left for non-compromised supply chains these days. Treat everything that can run foreign code as potentially compromized and keep everything compartmentalized. If you keep your crypto wallets or private banking info on the same machine where you do development, you're asking to get shafted one day. Or if you keep your big corporate github keys on the same machine where you do private weekend projects. It doesn't matter what you use in particular, even if some vectors are currently more popular than others.
If I can - I avoid NPM completely and just go with no-build projects.
Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.
In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't handle it, I'm hand rolling it.
Dapper remains the only constant 3rd party dependency in my projects. I don't know how much longer this will last with LLM assistance. The frontier models are very good at writing repositories over arbitrary sql schemas with low level primitives now.
> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.
This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing small things (left pad) rather than larger utilit libraries maintained by a larger community.
A larger community contributing to a larger library would mean that a larger community feels responsible and checks it.
That small package mentality a trace to web usage: JavaScirpt code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
With server side Node.js this lead to tons of dependencies ... which is worsened by npm allowing to have multiple versions of the same package in parallel. So if something depends on leftpad 1.0 and something else in leftpad 1.1 both are fetched and both are available.
This has been improving recently; one large project built on several heavy libraries that I've been supporting since 2018 currently installs ~180 dependencies without loss of functionality compared to how it worked, and what it depended on, back in 2018.
IIRC 6 years ago the full dependency tree congealed into more than 2000 packages. One small example is React itself:
- 5 deps: https://www.npmjs.com/package/react/v/15.6.2
- 0 deps: https://www.npmjs.com/package/react/v/19.2.6
Another is switching from create-react-app with its hundreds of transitive dependencies to vite, which, according to the test I've ran just now, currently has 15. Etc.
hmm maybe time to get into deno?
I mean, the current "allow ANY filesys operation" can't cope with modern supply-chain attacks...
with deno, you can specify folders/files that the execuble/library CAN touch (or CANNOT)
> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
Which is another part of this entire insanity:
Browsers are already <<huge>>. They're also built by <<huge>> companies companies that collect <<tons>> of analytics.
You'd think at this point they could present a proposal for a rock solid extended JavaScript standard library that would be based on actual website usage and would be comparable to what Java, .NET offer, obviously only keeping the parts that would be applicable to the web.
It sounds crazy but I think the Chrome installer is 150MB and an entire decent stdlib these days would probably be 1-5MB...
The web api is actually extensive. I can understand complaints about it being not exactly approachable, and some wanting a cleaner abstraction, but there’s no way that it is small. Most issues is about people wanting to download a small library than just vendoring the small snippet of code.
The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.
That was circumvented once by CDNs hosting common libraries so that those would stay in browser cache, browser vendors then "broke" that by caching per origin. (So that an evil site can't detect whether a user had been on some target site before by testing whether assets are fetched from cache)
Issue probably is that the standards process is slow (unless it is a feature Google "needs") and full of bike shedding (which features and how exactly they'd look) and adaption of features by developers is slow.
JavaScript meanwhile should be stable enough as an environment to allow a broader standard library.
Luckily it is slowly getting better (see Temporal as new date library, replacing moment.js usage in many places)
How large a project do you typically use dotnet for?
IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.
I don't think going commercial has been that impactful. It sucks, it betrays the spirit of open source but whatever. A few examples:
- FluentAssertions had no moat, and it has been forked as AwesomeAssertions. Not sure what the author's play was here.
- Moq lost trust - we have NSubstitute
- AutoMapper and MediatR have been widely misused anyway
- Maybe MassTransit is a real bummer?
Switching to the forks/alternatives is still time and effort, often a lot of it.
> How large a project do you typically use dotnet for?
The largest dotnet project I am responsible for has around 50 megabytes of source files sitting on its main branch right now. If you include the generated WCF references it's probably closer to 100 megabytes.
Mosts packages manager, allow that.
pnpm can still be exposed, afterall the worm simply have to wait you run tests locally.
I suppose.
But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.
Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'd see them in npm either. Since, they just don't care.
The biggest problem is not software but culture, not at npm, but in the js ecosystem. The js ecosystem is simply a juicy targets, the attack surface is enormous. The attacker can make their attack more sophisticated, there will always be a maintainer that can seed the worm spread.
Meanwhile in the nuget ecosystem is way smaller and have way less mainteners involved for a single given dependency.
I'd go further and say that how JS and the web itself has been run over the years has predisposed it to this sort of thing.
JS didn't have a passable stdlib until ES6. It had bugs built into it because Eich was given a stupidly short time window to deliver the first version. Everyone (particularly MS) had (and still sort of do) their own way of interpreting the language. In spite of all of this it became the primary way of developing applications for public consumption.
This led to a bunch of people who wanted to be the 10x JS engineer to solve problems with their own libraries and technologies. None of them really talked, they just threw their packages on NPM's registry without second thought and some gained widespread use just by accident.
Google tried fixing some of this with Dart but chickened out at the last second. TypeScript was designed by someone competent but can't fix the larger cultural issues.
This is what happens when you put SV hubris and "moving fast and breaking things" over doing things the right way.
> Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.
I'm still trying to calibrate my take on this view.
If attacks are randomly chosen from the set of all potential vulnerabilities, without the attacker knowing which ones had been patched, then that logic clearly makes sense.
But in an adversarial situation where the attacker can guess which vulnerabilities you still have unpatched, or can try many different attack vectors, then having already patched some other vulnerabilities doesn't matter so much.
I guess reality is more complicated though.
You can isolate it through bubblewrap; I moaned about it here and there's no point in repeating it:
https://news.ycombinator.com/item?id=45041798
If you only ever use js/ts for frontend projects (like we do), it closes one major hole that I'm aware of, which still leaves at least two:
- the editor possibly starting random binaries from inside the mode_modules (such as biome, vitest, tsgo)
- escape from sandbox by using some kernel vulnerability, of which there have been many recently
Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as.
It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed it somewhere where it would be dynamically loaded all the time.
Nearly every package manager I've ever used had post-install scripts.
You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs. This worm spreads because npm install runs arbitrary scripts as you, automatically, just from resolving the tree. You don't have to build it, run it, or even import it. Opening the project in an IDE is enough. apt/dnf scripts run on packages a maintainer signed and a distro gatekept. Not on whatever some rando pushed to a public scope 20 minutes ago that landed in your lockfile six levels deep. "They both technically execute code" is true and beside the point. One runs signed code from a trusted path, the other runs unsigned code from the default automated path. That's the whole ballgame.
> You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs.
> You don't have to build it, run it, or even import it
If you just installed something with npm, chances are you'll be running it shortly, either as a tool or a library, probably minutes or seconds later. I imagine the use case of installing an npm package you don't plan on using or transitively importing, constitute a small portion of npm installs.
> apt/dnf scripts run on packages a maintainer signed and a distro gatekept
Unfortunately apt/dnf isn't much better here because random tutorials online suggest people add random repositories where the creator of any repository effectively has root access to anyone machine that adds it as a remote.
Don't add random repositories from random tutorials? Come on, it's basic Internet hygiene. Entirely different thing.
It's the exact same problem when random tutorials (and official pages) recommend to do a curl "URL" | bash to install something. Every time that I see it, I look it suspicious.
Most package managers with postinstall scripts are also heavily curated and have reputation systems. As you say, they run as root, so the high trust requirement is definitely warranted. Anyone can upload an npm package.
I think it’s just a bundle of issues. Deep graph of dependencies, distribution of minimized code (java has jars, but I don’t remember scripts), and nearly impossible to audit. With most projects in other ecosytems, you only have to interact with a few developer/orgs. But with npm, you add one library and you need to essentially trust 10s of entities on the internet.
That's why we don't let the developers run system package manager install scripts as root. We do let them run npm inside containers, which is still more access than I'd like them to have.
Is this one of those places where it takes 6 to 12 weeks to get something new installed on your machine?
You mean directly on the machine? Not in a container? That would be a recklessly fast timeline. The configuration control board meets quarterly and it usually takes 4 or 5 meetings to clear a piece of software.
Interesting. How about in a container? What industry is this, just curious?
Defense. Containers on our normal network are the wild west, but anything that touches the secure network has to be signed off on by the clients.
> they've taken no action.
Not running lifecycle scripts by default is eventually going to be the default behavior. Late is worse (edit: I meant better) than not at all. https://github.com/npm/rfcs/pull/868
Wait how is being late worse than not doing it at all? Is it true for mortgage payments and apologies?
> That's an INSANE default.
It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?
There are so, so many things that NPM could do.
It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them.
It could add an optional key to package.json that allows someone to whitelist which packages can run install scripts.
It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI; (2) this hardened package status would be public, and (3) a developer could set a flag in their package.json that causes any npm action to act as if all non-hardened packages had frozen versions.
And so much more.
You realize that "dependency cooldowns" as a popular concept are extremely new, right? npm manages the installation of dependencies for millions upon millions of users across the globe.
> It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI;
Great, they did this.
> And so much more.
This shit takes time. Yes, they should have done this on day 1. Acting like any of this is easy to retrofit is just nuts though.
What is being said is that a new flag like '--minimum-release-age' would take, realistically speaking, tops 4 hours to implement (without AI assistance), plus a good 1 week of thorough testing, and maybe a 1 month period of progressive deployment. Come on, let's give it a total of 1.5 months, for good measure.
Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.
Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.
Have you ever managed software as critical and ubiquitous as npm?
Not infra, but final product. I know, corporations move slow. But when there is a critical issue, and an actual desire to solve it from someone in a suit, suddenly turns out that the cogs were always able to speed up and move fast...
Yes, this.
Regarding npm CLIENTS, PNPM is fundamentally different from (and superior to) npm or yarn.
Strongest possible recommendation to use pnpm.
It's also a good idea to use a private registry (eg via jfrog), acting as a proxy / pull-through cache, and point trad SAST and maybe AI scanners at it.
But dropping the npm client in favor of pnpm is a no-brainer. Speed, disk space, security, determinism, flexibility, fine-grained control over your dependency graph...
> allows all packages to run package supplied arbitrary code as the logged-in user after an update completes
As opposed to the completely untrusted package supplied arbitrary code that the logged in user executes when they actually use the package immediately after installing it?
The package might not ever be executed on the user's machine. Depending on your setup, it might only be ran on a server, where the data that can be exfiltrated is completely different.
Sure but like.. come on. Is that really a defense? Most packages are run on devs machines. And it's not like "Oh it's just running on my production server, what could go wrong there" is any better.
We should not dismiss that it is slightly better. Production servers vary rarely have creds to the source repository nor to other production servers running possibly more sensitive code where investing in a smaller supply chain was justified.
Why you are downloading code if you're not even using it to run tests ?
And if you run tests in CI/CD, or in a container, why you are downloading code locally ? Only thing that comes to mind is code completion but surely most people at least run unit tests locally before pushing the code out ?
One malicious script that is run right after install vs one per each API entry point that might be called or not (transitive dependency).
You can't even install the package without running arbitrary code, that's quite different from most other package managers for languages.
I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version.
This makes it so an update to a popular library can compromise a huge number of packages that depend on it.
In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.
MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.
NuGet is lock-by-default for the parent package, but with the move from packages.config to <PackageReference> it's no longer lock-by-default for dependencies.
It never made sense the other way. If I reference a package, logically I'm also referencing its dependencies at the version that the package uses. Forcing the user to also reference dependencies of dependencies of dependencies means the package reference lists aren't DRY.
But just the dependency list isn't sufficient to pick a specific version, thanks to dependency ranges. If Package A depends on Package B >= 1.0, and Package B has v1.0 and v1.1 available, it will use v1.0. But if Package B suddenly unlists v1.0, then future restores will change to v1.1.
Ah, I see the worry. A supply-chain attacker can use de-listing to force an upgrade to the malicious version if clients have dependency ranges that reach into the future.
I didn't know about that one.
In general, any dependency system that allows "you can silently upgrade to versions of the package that did not exist at the time the packagereference list was created" seems to be a vulnerability.
It's frustrating since this vuln seems trivially simple to fix, at a glance... although it would require an API change in PackageReference. Mandatory lockfiles by default, or getting rid of the floating versions misfeature. BindingRedirects let you override declared dependency versions anyways, they're not a blood pact.
It seems trivially simple until you have two dependencies with conflicting exact version requirements... So I don't think you can get rid of floating versions entirely. They did add NPM-style lockfiles for PackageReference, but currently not mandatory.
The version numbers for BindingRedirects are orthogonal to the package versions. You can have multiple package versions use the same AssemblyVersion so that applications don't need to create BindingRedirects. (e.g. Newtonsoft.Json - 13.0.0, and 13.0.1 in NuGet are both 13.0.0.0 for binding redirect purposes) And .NET Core/5+ don't need BindingRedirects at all!
Won't pinning a version lead to dependency hell, not to mention potentially using vulnerable versions if you don't a new version after it has some CVE fixes ?
i've been thinking about this as well. but having built a startup, i've learned that users don't care as long as they are given the value and most convenience. they don't really care much at security as much as we do. just look at openclaw? but maybe it's our job to make sure it is taken care of vs assuming the user cares and just make it look seamless.
users don’t care about security until it goes wrong. then they will be angry.
security is a hidden requirement.
One hour ago, while looking casually at a package.json, I saw this and was horrified:
Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory that works both on linux and windows!".
Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.
The industry is the process by which convenient crap like this gets standardized.
Yikes. I would never approve a PR with that in it.
Your agent might!
> Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.
Claude probably birthed this abomination in the first place
I hope the "standard" part is as much of a hallucination as "clever" is
To meekly defend the indefensible here: it's not like rmdir on Linux (I won't speak for all Unixen) can cause loss of data, since it only removes empty directories.
In this case, the rm -rf before that does. The rmdir is the Windows command in this example and with /s /q, it will quietly delete everything.
Yep, but that could still cause issues (those entries could be used as signals, or be mount points for currently unmounted partitions, etc). rmdir anything that start with "/" should be an absolute no-go.
To say nothing about running a sequence of shell commands without the -e option.
> Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.
Many package formats before NPM allowed for it, and frankly, it matters little, because if it can add code to your app it can run malicious code. The fact it executes on package install rather than when dev runs tests or the app matters little, and in general if environment is sandboxes, the package install is also ran in the same sandbox so disallowing it changes little.
so yes, every package manager can be hit, the reason is twofold
* JS is such a lowest common denominator it has that much more clueless users so just by scale every issue will be more common than in other languages
* extreme fragmentation leading to hundreds of packages needed for even small projects, which is again more chances for compromise
So does dpkg & rpm
That usually has a separate maintainer checking things, not updating automatically and often being the author of those packaging scripts, as they are often distro specific.
Maybe NPM is scared to break a ton of packages? I also think action from NPM on the repo level is vital
I went through the package.json on my machine - seems like ~400 / 60000 or 0.7% have (pre|post)install. (That's not all of the scripts that run at install)
Seems to me like a backwards compatibility is a non argument since pnpm is popular enough to stand as existence proof that scripts can be, at least, opt-in
IMO - pre- and post- install scripts should just be abolished/deprecated. It should require a special dispensation from npm to even publish one. A better system for binaries (needed by esbuild) is probably needed.
Even saying "just use pnpm" isn't enough, we need to get the developer community to herd immunity and that isn't going to happen on an opt-in basis.
I would love for npm to sandbox as well. But I think the better way forward is just turn off scripts.
So do the pre- and post-install scripts of Debian packages. The problem is not this but the lack of verified and controlled release channel.
> That's an INSANE default.
I agree that not running arbitrary installation scripts is the right default, but it's just an incremental improvement.
The practical difference between code that runs at installation and code that runs when the package is executed is, very typically, a small amount of time.
IMO, the hyperbole here hurts because it distracts from more effective efforts.
> IMO, the hyperbole here hurts because it distracts from more effective efforts.
For example?
Can I just run npm update diff and see all changes across all updates compared to the last reviewed code in node_modules? Why not?
npm is so bad at everything it's insane.
SIXTEEN YEARS of development and they can't even resolve a tree of dependencies in the correct manner unless you nuke the lockfile and node_modules.
Dependency resolution is literally the number one task and they fail at it. How can you expect them to be good at anything else? Absolute joke.
They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2].
[1] https://github.com/npm/cli/releases/tag/v11.16.0
[2] https://github.com/npm/rfcs/pull/868
This is way too little, way too late.
To see what I mean, try actually packaging a cross-platform binary dependency in their ecosystem.
I have; you specify one optional dependency per platform and set the requirements in each package. It works fine. A bunch of packages do this (e.g. esbuild). I don't know what your complaint is or what you're asking for.
Every package manager, by design, allows arbitrary code execution after the update completes. It is the entire purpose of a package manager. There is no point installing code that does not run.
tbf this is happening with a lot of package managers now, including pypi and composer
Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.
On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny.
How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?
It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
Opponents of gun control surely feel the same way about the Onion’s story.
I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong.
So, explicitly:
- pip
- Cargo
- apt/dpkg
- dnf/yum
- Homebrew
- RubyGems
- Composer (limited)
- Maven
...all allow scripts.
We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager.
npm shouldn't allow scripts, but exploits happen everywhere.
If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution.
Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack.
Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.
Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that.
The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them.
That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.
> Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it.
Not all packages come from the distro. People can and do enable external sources for software that isn't part of their OS.
Read the third sentence in the comment you're ostensibly replying to, friend.
Yes and typically updates take a while to be deployed...
Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.
That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.
> HN downmodded the first comment to hell but I know I'm right and the crowd is wrong.
Got downvoted for saying it too. Don't let it discourage you.
Maven does not run arbitrary scripts just by including a dependency.
Are scripts even necessary? I don't think e.g. mvn has any form of scripts¹, but if the dependency is compromised, you're likely to execute whatever compromised code is in there the next time you do mvn verify (or whatever). Slightly less wormable maybe, running tests or at least checking whether your thing still runs after upgrading package versions is really common, no?
¹ Annotation processors are a thing and somewhat similar to rust macros in function, but you need to set those up manually for each dependency, iirc.
ant-plugin and maven-assembly.
But pulling a maven dependency DON'T run anything. You must download the repository that contains the POM.XML and run mvn with any goal that triggers the lifecycle.
Maven 4 aims to separate distribution and build poms. Currently, we generate distribution pom.xml for distribution using flatten plugin.
It's not the package manager, it's the repo and the cryptographic signatures that are trusted by the package manager and the users who choose to point their pacakge managers at those repos. The fundamental problem here is that people's risk assessment is treating a user named devioustiger12345 as having the same situation and story as Microsoft/Apple/Red Hat.
You didn't include Perl's CPAN, which I think is older (1995) than all of these. And it allows scripts as well.
There’s actually a blog post with that exact title.
https://kevinpatel.xyz/posts/no-way-to-prevent-this/
https://news.ycombinator.com/item?id=48155690
Last 30 days:
PyPI, May 11. [1]
Crates.io, May 22 [2]
Composer, May 22 [3]
[1] https://www.tenable.com/blog/mini-shai-hulud-frequently-aske...
[2] https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...
[3] https://phoenix.security/laravel-lang-composer-supply-chain-...
Npm developers can relate to Windows being a target because it’s the most popular package manager.
Why would you target xyz pkg niche manager knowing that only 200 people will install them?
NPM does perform active offline & online vuln scanning on the packages. Everyone can do more, but they are going to be the #1 target.
Ask and you shall receive: https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-c...
https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says...
The XML extension I use in VSCode is by Red Hat.
Oh dear. Here we go again.
perfect time to drop a reminder: vendoring might seem annoying, but it's way safer than trusting a remote registry.
if RedHat is unable to secure their packages, what can we expect from mere mortals...
this looks like another GitHub Actions workflow compromise...
Is it really so hard for people to make releases manually?
Redhat's entire reason for existence is to prevent this.
not really, no.
So why else do we pay someone to package and certify/verify open source projects? This is absolutely 90++% of what should be RedHats core day job.
Non-profit Open Source distributions also and already package and verify open source packages (arguably often with a higher quality of analysis than Red Hat).
You pay red hat for compliance reasons (availability of a support you'll never call, mostly).
> You pay red hat for compliance reasons
You may, have you heard of docker?
did RPM packages get compromised?
Fucking Microsoft
Salam
Has anyone thought of having an agent review all dependency upgrades before upgrading?
I feel like that would at least catch some of these
Yes, I do this. It absolutely would catch some of these.
Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes?
All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with.
In fact, the entire situation has been exacerbated by coding agents because now practically everything happens on a single device that touches hundreds of different production systems with full production credentials.
Days since last malicious packages in NPM: 0 (evergreen)
Days since last malicious packages in PyPI: 30
Days since last malicious packages in Maven: 120
I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
Except that the JavaScript / NPM ecosystem is 6-7 times larger than Python and Java / Maven.
https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e0...
Check the linked resource which has the actual data.
Thanks for the link. However, a 7x size differential does not fully explain a 100x security incident differential -- although I'm sure it's part of it. Some of the root causes are very hard to address (e.g. a very limited standard library which encourages dependency explosions), some are just hard (e.g. established cultural norms around version pinning and upgrades, well-established reliance on install scripts) and some are easier (e.g. small tool improvements like min-release-age). I'm personally not going to touch npm with a ten foot pole in the next year or two, but I'd love to see significant improvement, so that I have that option again in 2 or 3 years. Stay safe!
The npm cli has bad defaults which you can turn off but they are there I presume for legacy reasons. The secure option is pnpm. The registry is fine.
Also on our comment about size differential ... it absolutely can.
If I jump from 2 meters hight it will be mildly uncomfortable. Jumping from 12 meters will result in severe injurious and possibly death. None of these things go linearly in real world conditions.
no because I dont ship production software from gitlab, I use upstream maintained packages?
Devs and other people who have seen behind the scenes at large companies know that most security is at best shaky and mostly hand-waved
It’s not even really the fault of the people who pushed for these setups, it’s a seemingly simple business decision: build it in a way that looks secure, add some black-box process, and tell the overseers that the reason there are no attacks is because it’s bulletproof, and definitely not because no one has really tried
Then, when someone finally turns their attention to you and walks in: fire whoever needs to be fired, patch that specific hole, maybe spend a bunch of money on a different system, assure the overseers that it’s handled, and move on with business as usual
It’s cheaper in the long-run, it makes stockholders happy, it relieves the bosses and their bosses, and for the most part there are “no security holes”.
Until now, of course
Downvoters: I’m curious why