I kept seeing every npm/pnpm/yarn/bun/uv supply chain post end with the same advice (set a minimum release age, turn off install scripts), and while I know cooldowns are "controversial", they do work. But even if you convince people that they should set cooldowns, it seems many don't end up following through, not sure why, maybe because it means hand-editing five config files in five formats with five different time units, or perhaps the "it won't happen to me" syndrome (or "I'll do it later, it seems complicated" where it's actually very simple). So I created a tool that checks what you have set and fixes it for you. I looked for an existing one first and couldn't find it. It started as a small weekend project and turned into a small research project on the nuances of cooldowns across package managers. Not a proof of P vs NP, but a small convenience that can save you and your loved ones from the next supply chain attack. I've raised this in a couple of HN threads since (https://news.ycombinator.com/item?id=47878158 and https://news.ycombinator.com/item?id=48156360) but never actually did a Show HN for the tool itself.

If you know how to edit your ~/.npmrc, which settings apply to npm vs pnpm, and which one wants minutes vs days vs seconds, you probably don't need this. But if you vibe code and just want a one click fix (or you have a PhD in CS from Stanford, ex-FAANG, started 3 YC companies, now work at Anthropic, and still just want a one click fix), read on.

DepsGuard is a single Rust binary, no runtime deps, MIT. Run depsguard and it scans your user-level and repo-level configs, shows a table of what is and isn't set, you pick what to change, hit d for the diff, and apply. It writes a timestamped backup first and depsguard restore rolls it back. depsguard scan is read-only if you just want the report.

The settings are the simple ones that work: min-release-age / minimumReleaseAge (npm, pnpm, yarn, bun, and uv all name it differently and use days vs minutes vs seconds, which is half of why doing this by hand is annoying), ignore-scripts, and on newer pnpm block-exotic-subdeps, trust-policy: no-downgrade, and strict-dep-builds. It also handles Renovate and Dependabot cooldowns.

The whole thing is a bet on timing. The malicious @bitwarden/cli 2026.4.0 was up ~19 hours and got 334 installs. axios was pulled in ~3h, ua-parser-js in hours, node-ipc in days. A 7-day gate means your installer never resolves any of those, they're gone before the window even opens. It does nothing for the slow ones (event-stream sat 2+ months), and it's not SCA, it won't scan your existing lockfile for known CVEs, that's a different layer.

Disclosure: I'm a co-founder and CTO at Arnica (a commercial appsec startup) and built this because putting the same recommendations on each blog post felt like yelling at the clouds. It's free and MIT, no account, no telemetry. I'm also not the only one who had the idea (didn't know at the time), cooldowns.dev does the cooldown part across more ecosystems with a shell helper and is worth a look. DepsGuard covers fewer ecosystems but adds the other settings and the diff/backup/restore flow.

If you want to try it: cargo install depsguard, or brew/apt/winget/scoop, all in the README.

https://github.com/arnica/depsguard (full settings table and FAQ at depsguard.com)

Is this an overkill that could have been a shell script? Probably yes (but I wanted windows support, why not).

Did it save someone from a supply chain attack? Also probably yes.

Do I know personally someone that without it wouldn't have bothered changing their settings after repeatedly asking, but eventually did it when I gave them depsguard? Absolutely yes.

Show HN: DepsGuard – One command to harden NPM/pnpm/yarn/bun/uv configs