[HN Gopher] Show HN: Safe-NPM - only install packages that are +...
___________________________________________________________________
Show HN: Safe-NPM - only install packages that are +90 days old
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.
Author : kevinslin
Score : 22 points
Date : 2025-11-23 22:14 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pr0xyb0i wrote:
| How does it differ from:
| https://docs.npmjs.com/cli/v11/commands/npm-install#before
| silverwind wrote:
| Seems like a worse version of `before` because `before` also
| handles indirect dependencies, whil this module does not seem
| to.
| asdkkthrowaway wrote:
| Doesn't this just mean you're 90 days late on any patches?
| beepbooptheory wrote:
| 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 wrote:
| 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.
| moritzwarhier wrote:
| 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.
| someothherguyy wrote:
| https://pnpm.io/supply-chain-security
| tkzed49 wrote:
| 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.
| moritzwarhier wrote:
| 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
| mrconter11 wrote:
| But safe-npm is not 90 days old yet.. :/
| robkop wrote:
| You could dual brand as vibe-npm, only install packages that are
| in your models training dataset
| cheesekunator wrote:
| 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.
| femiagbabiaka wrote:
| 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.
| Waterluvian wrote:
| 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.
| ssl-3 wrote:
| > 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.
| ttoinou wrote:
| If everybody does that, won't we take 90 days more to detect
| problems / hacks of npm packages ?
| lelandbatey wrote:
| 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.
| codezero wrote:
| Does anyone have any statistics on how long a compromised package
| has been in the wild on average?
| sebmellen wrote:
| "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
___________________________________________________________________
(page generated 2025-11-26 23:00 UTC)