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.