Skip to content(if available)orjump to list(if available)

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

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

15 comments

·November 23, 2025

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.

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.

mrconter11

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

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

pr0xyb0i

silverwind

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

robkop

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

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.

ssl-3

> Why does elapsed time mean a library is safe?

It doesn't mean that at all.

> This is so ridiculous.

OK.

> It doesn't protect you against anything.

Incorrect.

It can protect against bad code that is less than 90 days old that has been caught and corrected. It also turns undetected 0-day exploits into 90-day exploits.

That's not perfection, but it's more than nothing.

> I'm sure there are 1000s of old libraries out there with hidden vulnerabilities or malicious code.

I'm sure that there are, too.

---

We're all free to develop the perfect system when we have the time. Until this happens, we get to live within the constraints imposed by rest of the world -- including bad actors.

asdkkthrowaway

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

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.

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.

ntonozzi

It's not debouncing, it's delaying. Ideally you can still update a specific dependency to a more up to date version if it turns out an old version has a vulnerability.