Cos'è il dependency cooldown e perché aspettare prima di aggiornare?

Il dependency cooldown, cioè il periodo di attesa per le dipendenze, è la regola con cui un progetto software rifiuta la versione appena pubblicata di una libreria open source finché non è rimasta online per un tempo stabilito, da qualche ora a qualche settimana. Le dipendenze sono i pacchetti di codice scritti da altri che un'applicazione scarica da registri pubblici come npm per JavaScript o PyPI per Python. Il rischio nasce quando un attaccante ruba l'account di chi mantiene un pacchetto molto usato e ne pubblica una versione che contiene codice malevolo: chi aggiorna subito la installa. Queste versioni però vivono poco, e la documentazione di pnpm osserva che il registro npm di solito le rimuove nel giro di poche ore. Aspettare vuol dire lasciare a ricercatori e gestori del registro il tempo di scoprirle prima che entrino nella propria build, il pacchetto finale che va in produzione. Il bot Renovate chiama la stessa impostazione minimum release age.

Leggi anche: Patch management (gestione degli aggiornamenti) · Il processo con cui un'azienda scopre, prioritizza, testa e installa gli aggiornamenti di sicurezza dei propri sistemi, misurato in giorni di esposizione.

Quanto aspettare, e cosa non deve aspettare

Non esiste una durata standard: pnpm attende per impostazione predefinita un giorno, Dependabot di GitHub applica tre giorni agli aggiornamenti di versione, Renovate porta come esempio 14 giorni. Il nome si è diffuso con un articolo di novembre 2025 di William Woodruff, ingegnere di Astral (la società che sviluppa uv). Woodruff vi confronta dieci attacchi noti, un campione che lui stesso definisce molto piccolo: in otto la versione malevola era rimasta disponibile meno di una settimana.

Così però anche le correzioni legittime arrivano tardi. Per questo Renovate e Dependabot lasciano passare subito gli aggiornamenti di sicurezza, quelli che chiudono una vulnerabilità nota, di solito con un identificativo CVE: l'attesa vale per gli aggiornamenti ordinari. È il punto in cui il cooldown incontra il patch management, che stabilisce con quale urgenza una falla va chiusa. Woodruff segnala anche il rovescio della medaglia: se l'eccezione esiste, annunciare una vulnerabilità diventa un modo allettante per aggirare l'attesa.

Le dipendenze delle dipendenze

Un progetto dichiara qualche decina di librerie, ma ognuna ne porta con sé altre, dette transitive, che nessuno ha scelto. I bot che propongono gli aggiornamenti guardano solo le dipendenze dichiarate, mentre l'albero completo lo calcola il gestore di pacchetti (npm, pnpm, uv). Per questo la documentazione di Renovate raccomanda di impostare l'attesa sia nel bot sia nel gestore di pacchetti: altrimenti una versione appena uscita entra dalla porta di servizio, come dipendenza di una dipendenza. I gestori principali oggi lo prevedono, con nomi diversi: min-release-age in npm, minimumReleaseAge in pnpm, exclude-newer in uv.

Un esempio enterprise

Un'azienda sviluppa un assistente interno e usa litellm, una libreria Python che fa da interfaccia unica verso più fornitori di modelli linguistici. Nel 2026 su PyPI sono comparse versioni compromesse di litellm: secondo il rapporto di PyPI sull'incidente, fra caricamento e quarantena sono passate 2 ore e 32 minuti, quanto è bastato perché venissero scaricate oltre 119.000 volte. Con un'attesa di sette giorni impostata sia nel bot sia in uv, quelle versioni non sarebbero mai arrivate in una build: allo scadere della settimana erano già sparite. Il bot, invece, propone subito una correzione di sicurezza per un'altra libreria, ma uv la ignora finché il team non esenta quel pacchetto a mano.

Perché conta per chi decide

Il cooldown costa poco: una riga di configurazione e qualche giorno di ritardo sulle novità delle librerie. Riduce un rischio preciso, l'installazione di una versione malevola appena pubblicata, e niente di più: non ferma un attacco che resta nascosto per settimane e non sostituisce la SBOM, l'inventario dei componenti che dice dove intervenire quando qualcosa va storto. È un controllo che trova posto naturale in una pipeline DevSecOps. Le domande da fare al team o al fornitore sono due: l'attesa è impostata sia nei bot sia nei gestori di pacchetti? Gli aggiornamenti di sicurezza sono esclusi in entrambi, e qualcuno li guarda subito?