We should all be using dependency cooldowns

Security vs. stability tradeoff

• A core debate is whether default delays on dependency updates are good engineering:
  • Pro-cooldown: most changes don’t matter immediately; new releases regularly introduce bugs and vulnerabilities; waiting days–weeks lets scanners, maintainers, and early adopters surface problems before you ingest them.
  • Anti-cooldown: you’re deliberately delaying real bugfixes and zero‑day patches; if your tests are good, staying very up‑to‑date is often the most stable option.
• Several note that zero‑days are usually patched quickly and tools can/should bypass cooldowns for known CVEs, so cooldowns mainly target unknown malicious or buggy updates.

What “cooldown” actually governs

• Many argue cooldowns should apply only to automated, semver-based bumps (Dependabot/Renovate/etc.), not to human decisions.
• Engineers are expected to override the delay for critical fixes, after reviewing changes and accepting responsibility.
• There’s some confusion/annoyance over whether a “cooldown” is a hard rule or just a default; the article’s author clarifies it’s intended as the latter.

Effectiveness if everyone uses cooldowns

• Critics: if all consumers wait, fewer “eyeballs” see the new release; discovery of supply‑chain attacks may be delayed, so the attack window stretches.
• Supporters: recent big supply‑chain incidents were caught by maintainers and automated analysis, not random end‑users; vendors are incentivized to scan new releases regardless of adoption; randomized or staggered cooldowns could mimic gradual rollout.

Dependency management philosophies

• One camp favors aggressive, continuous updates with strong test suites; another favors minimal churn: update only for needed features/bugfixes or security, otherwise stay put.
• Several warn that “update only when you must” leads to huge, painful jumps when you finally have to catch up—“falling off the release train.”
• Others prefer vendoring dependencies and only updating for major vulnerabilities, trading ongoing churn for explicit, infrequent upgrades.
• There’s wide support for:
  • Keeping dependency trees small and focused.
  • Using LTS-style releases.
  • Avoiding “everything” libraries with giant transitive graphs.

Tooling, AI, and governance

• Proposed helpers: CI jobs that batch periodic updates, lockfiles plus minimum package age, proxy registries that expose older snapshots, and LLMs to:
  • Triage CVE firehoses.
  • Summarize diffs and call out breaking or suspicious changes.
• Some want ecosystem-level review/signoff systems where upgrades wait for enough independent audits rather than just time.