Show HN: Safe-NPM – only install packages that are +90 days old

[kevinslin]

This past quarter has been awash with sophisticated npm supply chain attacks like [Shai-Hulud](https://www.cisa.gov/news-events/alerts/2025/09/23/widesprea...() and the [Chalk/debug Compromise](https://www.wiz.io/blog/widespread-npm-supply-chain-attack-b...). This CLI helps protect users from recently compromised packages by only downloading packages that have been public for a while (default is 90 days or older).

Install: npm install -g @dendronhq/safe-npm Usage: safe-npm install react@^18 lodash

How it works: - Queries npm registry for all versions matching your semver range - Filters out anything published in the last 90 days - Installs the newest "aged" version

Limitations: - Won't protect against packages malicious from day one - Doesn't control transitive dependencies (yet - looking into overrides) - Delays access to legitimate new features

This is meant as a 80/20 measure against recently compromised NPM packages and is not a silver bullet. Please give it a try and let me know if you have feedback.

[sebmellen]

"Here, install my new 1-day old NPM package that doesn't let you install packages younger than 90 days."

Pardon me, I couldn’t help myself :D

[mort96]

I get that it's a joke, but I feel the need to defend this project anyway.

The problem with NPM isn't any one young package. The problem with the NPM is that any time you run 'npm install', you download potentially thousands of packages, and you get the most recent patch release from all of them. Installing one 1-day-old NPM package to forever avoid day 1 releases of thousands of packages seems like a worthwhile trade.

Still, I would maybe choose the tried and true PNPM instead, which supports this too.

[MuffinFlavored]

remindme! 89 days

[h33t-l4x0r]

You would `npm link` that thing in real life I think.

[moritzwarhier]

As someotherguyy already mentioned, this is a default feature in pnpm.

And as far as cat-and-mouse-games go in other package managers, I'd say that pinning dependencies and disabling postinstall scripts is a much better option. Sure, not a foolproof one either, but as good as it gets.

edit: misspelled someotherguyy's user name

[buu700]

I recently learned that this is (for all intents and purposes) a feature in npm as well, specifically the `--before` flag to `npm install`: https://docs.npmjs.com/cli/v11/commands/npm-install#before. That was harder than it should've been to figure out; it really needs better marketing.

Related to that is the proposal for `stabilityDays`, which seems way more practical: https://github.com/npm/cli/issues/8570#issuecomment-33004136.... So rather than merely saying "I only want package versions more than N days old", you'd be adding the requirement that "...and also they should have gone at least N days without a subsequent patch release". e.g. if mylib@6.0.0 is released, only to be quickly followed by 6.0.1 and 6.0.2, you ideally wouldn't want to risk ever installing the probably-broken 6.0.0 or 6.0.1 based on luck of the draw; the better behavior would be to stick with the last 5.x release until 6.0.2 has aged past the threshold.

[2muchcoffeeman]

Why is the community persisting with such poor solutions?

[tkzed49]

Not controlling transitive deps makes this vastly less useful because direct deps can specify version ranges (e.g. latest minor version). Personally I'd stick with pnpm's feature.

[zelphirkalt]

This is why one should pin all direct and transitive dependencies with their checksums and not upgrade everyday willy-nilly. There is no need to specify the specific version numbers of transitive dependencies, if one keeps a lock file that pins those exact versions and checksums of transitive dependencies, and one doesn't upgrade willy-nilly all the time. Make upgrading dependencies a conscious choice, and perhaps have a policy of at most upgrading every X days.

[someothherguyy]

https://pnpm.io/supply-chain-security

[zelphirkalt]

This works only if there are some other people, who will use a dependency "too early" to fall victim to some exploit and then notice it, within those 90 days. Imagine, if everyone only used packages older than 90 days. Then we would have no frontrunner to run into the issues before us.

A cooldown time alone is not actually a sufficient solution. What people really need to stop doing, is not properly pinning their versions and checksums, and installing whatever newer version is available. That would cause a problem even, if the date line is moved 90 days into the future for all packages. If however, one only updates versions of dependencies when one consciously makes that choice, there are far fewer points in time, when versions change, and therefore the chance of catching something is also much lower. Combine that with a cooldown time/minimum age for versions, and you got an approach.

[LelouBil]

Yes and no, usually when malicious packages go public it's some third party cybersecurity firm that scans packages that found it.

[mrconter11]

But safe-npm is not 90 days old yet.. :/

[jagged-chisel]

Consider this a 3-month lead on the ability to utilize it

[pr0xyb0i]

How does it differ from: https://docs.npmjs.com/cli/v11/commands/npm-install#before

[silverwind]

Seems like a worse version of `before` because `before` also handles indirect dependencies, whil this module does not seem to.

[asdkkthrowaway]

Doesn't this just mean you're 90 days late on any patches?

[beepbooptheory]

This article was on the front page recently that discusses the idea behind this:

https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Most of the time, you need quick patches because of fairly recent dependency changes, so if you just wait and kind of "debounce" you dependency updates, you can cover a lot of supply chain vulnerabilities etc.

[moritzwarhier]

auto-updating is bad.

Scheduled, audited updates are good.

Installing random npm packages as suggested here is also bad. Especially with "--global", although I'm not sure if that makes any difference because Node by default of course can access all of your file system.

[yokto]

Yarn has a configurable npmMinimalAgeGate setting as well since version 4.10: https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate

[ttoinou]

If everybody does that, won't we take 90 days more to detect problems / hacks of npm packages ?

[lelandbatey]

No, cause the folks detecting the problems typically do so by actively scanning new releases (usually security companies do this). Few such problems are detected by people who do a "normal" update and receive compromised code, investigate, and then report the problem. It does happen, but it's not the "usual" way these supply chain attacks are discovered, especially not the really big ones.

[aussieguy1234]

This does mean that security patches released yesterday won't get installed.

Its the opposite of "keep your software up to date"

[waterTanuki]

Just use pnpm. I've never once had compatibility issues with it on linux/mac/windows over the past 6 years.

[PunchyHamster]

Now with 9000% more zero-days!

> Installs the newest "aged" version

Probably want to install version that has CVE-fixed instead, i.e find the cve for packages and install latest version that has all of them fixed but not later.

Technically someone could fake a cve to get people to upgrade but that's a far more involved process

[codezero]

Does anyone have any statistics on how long a compromised package has been in the wild on average?

[spullara]

this is a good idea but i just did this:

  alias npm='npm --before="$(date -v-1w +%Y-%m-%d)"'
  alias pnpm='pnpm --before="$(date -v-1w +%Y-%m-%d)"'

[vrighter]

the more people use this, the less useful it becomes for everyone. If everyone uses this, then everyone would still be using a particular package for the first time at the same time. What then? Release another package that extends the delay to 6 months?

[mdx97]

Malicious packages aren’t just found because someone gets pwned, there are organizations out there proactively scanning for this stuff.

[robkop]

You could dual brand as vibe-npm, only install packages that are in your models training dataset

[m4rtink]

So how is not using those Debian packages because they are too old working out ? ;-)

[ghtbircshotbe]

Recently decided to learn typescript. You would hardly know there's a Debian package from reading typescript's website.

[arrty88]

With the help of AI, i see no reason to install most deps nowadays besides types and react and mui framework. Everything can be built from scratch quickly.

[actionfromafar]

I think this is a pretty common approach nowadays, and one of the reasons why I believe my job is safe for now. I expect to be called up to fix some of the resulting mess. It's a two-edged sword, for sure.

[zelphirkalt]

You still will have to maintain it then though.

[catlifeonmars]

Now you have shifted your supply chain issues to your coding agent.

[cheesekunator]

Why does elapsed time mean a library is safe? This is so ridiculous. It doesn't protect you against anything. I'm sure there are 1000s of old libraries out there with hidden vulnerabilities or malicious code.

[Waterluvian]

Literally nothing can mean a “library is safe.”

The idea of “safe” in terms of risk and security has misled a lot of people into this wrong idea that there’s a binary state of safe and unsafe.

It’s all about risk management. You want to reduce risk as inexpensively as possible. One of many inexpensive approaches is “don’t install dependencies that are new.” Along with “don’t install dependencies that nobody else uses.” You might also apply the rule, “don’t install dependencies that aren't shipped with the OS.” Or “don’t use dependencies that haven’t been formally proven.” Etc.

Indeed, calling it “Safe-NPM” can be misleading. As if using it achieves some binary state of safety.

[femiagbabiaka]

Most supply chain attacks have a very limited window in which they’re exploitable. This is not a panacea, but it is a good idea.

[PunchyHamster]

hedging bets of zero day vs compromise (that have big chance to be found in thos e 90 days). But yeah, not a good idea