Dependency cooldowns turn you into a free-rider
Dependency “cooldowns” — delaying adoption of new package versions by days or weeks — are being debated as a way to reduce software supply-chain attacks, but critics argue they simply push risk onto early adopters and don’t meaningfully improve security. Commenters contrast per-project cooldowns with centralized “upload queues” at registries, which would hold new releases for automated and manual review before they become the default for everyone. Opinions diverge on whether waiting is an irresponsible form of free-riding or a rational, long-standing practice for risk-averse organizations, and on how to balance faster fixes for critical vulnerabilities against the need to detect malicious updates.
Framing: Are Dependency Cooldowns “Free-Riding”?
- Many reject the “free‑rider” label, arguing that cautious updating is normal risk management, not moral failing.
- Others accept that waiting benefits from others’ early pain but say free‑riding is inherent to open source and often rational.
- Several note that if everyone delays, benefits vanish and detection is pushed back; this is framed as a collective action / game‑theory problem.
Practical Reasons for Cooldowns and Delayed Updates
- Longstanding ops practice: avoid “.0” releases, prioritize uptime, and stagger deployments.
- Cooldowns help low‑resource orgs that don’t audit dependencies, letting security tools and early adopters surface issues first.
- They also reduce blast radius: not everyone is broken or hacked at once, unlike uniform auto‑updates.
- Some organizations already achieve this via LTS versions, staging, or intentional, batched dependency upgrades.
Critiques of Cooldowns
- Critics say cooldowns don’t fix fundamental supply‑chain issues and can delay delivery of critical security patches.
- If widely adopted, cooldowns may simply shift who gets hit first, not reduce total harm.
- Some call cooldowns “theater” because many attacks are detected months later, beyond typical cooldown windows.
Upload Queues and Centralized Delays
- Many see registry‑side upload queues as a stronger alternative: time for automated scanning, manual review, paper trails, and opt‑in early access.
- Questions arise about handling urgent CVEs, exception paths, cascading dependencies, and added complexity for underfunded registries.
- Some argue central queues and per‑org cooldowns address different layers: ecosystem‑level safety vs. individual risk tolerance.
Alternatives and Complements
- Suggested complements: shared audit systems, commercial repackagers, honeypots, outbound-network whitelisting, and capability‑based security.
- Several emphasize that insecure software is often an organizational/political problem, not just a technical one about update timing.