Nuove difese temporali di GitHub e PyPI: cooldown di 72 ore e blocco a 14 giorni contro gli attacchi alla supply chain

Introduzione

La protezione della supply chain del software è al centro dell’attenzione di sviluppatori e piattaforme di distribuzione. Il 26 luglio 2026, GitHub e PyPI hanno introdotto due meccanismi imperniati sul tempo per contrastare le recenti campagne malevole che hanno colpito gli ecosistemi npm e Python. GitHub ha integrato in Dependabot un cooldown predefinito di 72 ore per le pull request di aggiornamento automatico, mentre PyPI ora vieta l’upload di file aggiuntivi su una release dopo 14 giorni dalla pubblicazione iniziale. Entrambe le misure nascono dalla necessità di rallentare gli attaccanti e ridurre la finestra di esposizione, reagendo a minacce come “chalk”/“debug”, “s1ngularity”, Shai-Hulud e GhostAction.

Analisi tecnica

Il cooldown di Dependabot su GitHub

Dependabot, lo strumento automatico di GitHub per tenere aggiornate le dipendenze, attende ora 72 ore prima di aprire una pull request quando rileva una nuova versione di un pacchetto. Questo ritardo, personalizzabile nel file .github/dependabot.yml, vuole concedere tempo agli strumenti di sicurezza e alla comunità per individuare pacchetti sospetti o malevoli. L’iniziativa rafforza precedenti interventi per npm e risponde direttamente a tecniche di attacco che sfruttavano l’immediatezza degli aggiornamenti automatici per propagare codice dannoso. Poiché Dependabot analizza i manifesti (es. package.json) e i feed dei registri, il cooldown agisce posticipando la creazione della PR: se un pacchetto viene segnalato e rimosso nelle prime ore, gli aggiornamenti automatici non lo adottano.

Il blocco post-pubblicazione su PyPI

Il Python Package Index ha introdotto un limite temporale rigido: dalla pubblicazione iniziale di una release, i manutentori hanno 14 giorni di tempo per aggiungere file; superata questa finestra, l’API di upload restituisce un errore. La scelta è preventiva: sebbene non siano stati osservati attacchi reali basati sull’avvelenamento di vecchie release, l’analisi dei metadati mostra che solo una frazione trascurabile di progetti carica file legittimamente dopo due settimane, rendendo il vincolo accettabile. Tecnicamente, PyPI verifica la data di creazione della release e blocca qualunque tentativo di modifica oltre il limite, riducendo il rischio che un attaccante con credenziali compromesse inietti malware in versioni “storiche” e fidate.

Impatto

I meccanismi temporali alzano significativamente l’asticella per gli attaccanti e mitiga due scenari ad alta gravità:

• Cooldown Dependabot: senza questo ritardo, un pacchetto malevolo potrebbe essere automaticamente propagato a migliaia di repository attraverso pull request aperte in pochi minuti, prima che i manutentori e i sistemi di threat intelligence lo blocchino. Le 72 ore forniscono un cuscinetto vitale per le difese.
• Blocco PyPI: l’avvelenamento di una release consolidata consentirebbe a un utente malintenzionato di colpire chi installa quella versione, confidando nella sua reputazione. Il limite di 14 giorni rende impossibile manomettere release datate, proteggendo l’integrità a lungo termine dei pacchetti e semplificando la risposta a eventuali compromissioni di account.

La gravità è alta perché le campagne recenti hanno dimostrato come pochi minuti possano trasformarsi in compromessi su larga scala, con furto di credenziali e distribuzione di malware in ambienti CI/CD e di sviluppo.

Mitigazione

Queste le contromisure attualmente in vigore e le raccomandazioni complementari:

• Cooldown Dependabot (attivo di default): 72 ore di attesa prima dell’apertura automatica delle PR. È modificabile, ma se ne sconsiglia la rimozione totale; in caso di necessità di aggiornamenti rapidi, si può ridurre, accompagnandolo a verifiche manuali aggiuntive.
• Blocco PyPI (automatico e universale): nessun intervento richiesto ai manutentori. Il sistema impedisce automaticamente upload tardivi su tutte le release.
• Pratiche complementari (raccomandate da GitHub e dalla comunità):
  • Utilizzare lockfile (es. package-lock.json, Pipfile.lock) per bloccare le dipendenze a versioni esatte note e sicure.
  • Assegnare token con ambiti limitati (scoped token) in CI/CD, riducendo i privilegi di installazione.
  • Disabilitare script superflui in fase di installazione (es. --ignore-scripts per npm, ambienti virtuali Python senza esecuzione automatica di setup.py).
  • Testare le difese attive: condurre simulazioni di attacco per verificare che SIEM ed EDR rilevino manomissioni di pacchetti, riducendo i falsi negativi.

FAQ

1. Posso disabilitare il cooldown di Dependabot se nel mio progetto servono aggiornamenti immediati?

Sì, è possibile modificare il parametro open-pull-requests-limit e il valore dell’attesa nel file di configurazione di Dependabot, o disattivarlo del tutto. Tuttavia, farlo espone a rischi elevati: se si sceglie questa strada, occorre compensare con una scansione manuale delle nuove versioni e con policy di sicurezza stringenti in CI.

2. Il blocco dei 14 giorni su PyPI si applica anche ai pacchetti che ho pubblicato mesi fa?

Sì, la regola è retroattiva per quanto riguarda l’aggiunta di nuovi file. Se provi a caricare un file su una release creata più di 14 giorni fa, l’API di PyPI restituirà un errore, a prescindere dalla data di introduzione della misura. Le release esistenti non vengono alterate, ma non sono più modificabili.

3. Questi meccanismi temporali sono sufficienti a proteggere la supply chain?

No. Le difese basate sul tempo riducono la superficie esposta e rallentano gli attaccanti, ma devono integrarsi in una strategia più ampia: lockfile, controllo continuo delle dipendenze, permessi minimi in CI/CD e formazione dei team rimangono indispensabili. Le minacce evolvono rapidamente e richiedono un approccio multilivello.