GitHub e PyPI introducono difese temporali contro la supply chain

🛡️ Executive Summary

• Dependabot applica un periodo di attesa predefinito di 72 ore prima di proporre gli aggiornamenti delle dipendenze appena pubblicate.
• PyPI impedisce di aggiungere nuovi file alle release che hanno superato i 14 giorni dalla pubblicazione originale.
• Le misure riducono l’esposizione iniziale, ma non sostituiscono lockfile, token limitati, build riproducibili e controlli sui workflow CI/CD.

GitHub e Python Package Index introducono due difese basate sul tempo per limitare gli attacchi alla supply chain del software. Dependabot attenderà per impostazione predefinita 72 ore prima di proporre l’adozione delle versioni appena pubblicate, offrendo ai sistemi di sicurezza più tempo per rilevare pacchetti compromessi. PyPI impedirà invece di aggiungere nuovi file alle release pubblicate da oltre 14 giorni, bloccando una possibile tecnica di avvelenamento delle versioni considerate affidabili. Le misure arrivano dopo campagne che hanno sfruttato account di maintainer, token di pubblicazione, workflow CI/CD e pacchetti legittimi per distribuire malware a sviluppatori e aziende.

Dependabot attende 72 ore prima degli aggiornamenti

Dependabot analizza i file che descrivono le dipendenze di un progetto e apre automaticamente pull request quando individua una versione più recente. Questa velocità riduce il tempo necessario per applicare correzioni e aggiornamenti, ma può trasformarsi in un rischio quando una release appena pubblicata contiene codice malevolo. Il nuovo periodo di cooldown introduce un’attesa predefinita di tre giorni prima che la versione venga proposta ai maintainer. GitHub ha scelto questa finestra come compromesso tra rapidità degli aggiornamenti e necessità di lasciare ai ricercatori, ai registry e ai sistemi automatici il tempo di identificare comportamenti sospetti. In molti attacchi recenti, infatti, i pacchetti malevoli sono stati rilevati in pochi minuti, ma sono rimasti scaricabili durante il tempo necessario per verificare la segnalazione, rimuovere gli artefatti e revocare gli accessi compromessi. Il cooldown prova a evitare che l’automazione porti immediatamente il codice ostile nei repository e nelle pipeline delle aziende. La durata può essere modificata, permettendo ai team di adottare finestre differenti in base alla criticità delle dipendenze e alla velocità richiesta dai propri processi.

Il ritardo riduce la finestra degli attacchi lampo

La difesa risponde soprattutto agli attacchi che puntano sulla velocità. Un aggressore compromette l’account di un maintainer, pubblica una versione malevola di un pacchetto conosciuto e tenta di raggiungere il maggior numero possibile di sistemi prima della rimozione. I bot di aggiornamento, le configurazioni permissive dei gestori di dipendenze e le pipeline automatiche possono adottare la release senza una revisione umana. Un’attesa di 72 ore rende meno efficace questa strategia, perché numerose campagne vengono individuate e neutralizzate nelle prime ore. Il contesto è quello già descritto nell’analisi sulle nuove difese di GitHub e npm contro gli attacchi alla supply chain, dove la sicurezza si sta spostando dalla sola autenticazione degli autori al controllo del comportamento dei pacchetti durante installazione e aggiornamento. Il ritardo non protegge però dalle compromissioni che rimangono invisibili per settimane o dalle release malevole costruite per attivarsi soltanto in particolari ambienti. GitHub raccomanda quindi di affiancare il cooldown a lockfile, versioni bloccate, token con privilegi limitati e disattivazione degli script di installazione non necessari nelle pipeline CI/CD.

PyPI chiude le release dopo quattordici giorni

PyPI applica una regola differente: dopo 14 giorni dalla pubblicazione di una release, i maintainer non potranno più aggiungere nuovi file alla stessa versione. Un progetto potrà continuare a pubblicare una release successiva, ma non modificare indirettamente una versione più vecchia e già considerata affidabile dagli utenti. Il provvedimento impedisce il cosiddetto release poisoning, scenario nel quale un aggressore ottiene un token o compromette un workflow e aggiunge un nuovo artefatto malevolo a una release esistente. Il file potrebbe essere preparato per una piattaforma, una versione di Python o un’architettura non coperte dagli artefatti originali, inducendo alcuni sistemi a scaricarlo senza che il numero della versione cambi. PyPI ha rilevato che soltanto una percentuale molto ridotta dei progetti aggiunge legittimamente file dopo due settimane, rendendo il limite sostenibile per la maggior parte dell’ecosistema. La piattaforma precisa inoltre che non risultano campagne passate confermate basate esattamente su questa tecnica: la misura è preventiva e punta a eliminare un percorso di attacco prima che venga utilizzato su vasta scala.

Shai-Hulud dimostra il valore delle release fidate

L’intervento arriva dopo una serie di operazioni nelle quali pacchetti legittimi sono stati trasformati in vettori per sottrarre segreti, token e credenziali degli sviluppatori. Shai-Hulud ha compromesso centinaia di pacchetti tra npm e PyPI, utilizzando accessi autentici e meccanismi di pubblicazione regolari per distribuire codice malevolo dotato, in alcuni casi, anche di attestazioni di provenienza valide. La campagna ha mostrato che firma, reputazione del maintainer e nome conosciuto del progetto non garantiscono l’integrità della singola release. La crisi ha coinvolto GitHub, Grafana e centinaia di pacchetti npm, mentre una variante successiva ha infettato PyPI con wheel malevoli e uno stealer basato su Bun. Anche AsyncAPI è stata colpita attraverso versioni compromesse capaci di raggiungere milioni di download, confermando che l’attaccante non deve creare un pacchetto sconosciuto quando può appropriarsi della fiducia accumulata da un progetto già adottato. Le nuove finestre temporali cercano di impedire che questa fiducia venga trasferita automaticamente a ogni nuovo artefatto.

Le difese temporali non verificano il codice

Il limite principale delle due misure è strutturale: il passare del tempo non rende sicuro un pacchetto. Una release malevola può rimanere inosservata oltre le 72 ore, mentre un file caricato entro i primi 14 giorni su PyPI può contenere lo stesso codice pericoloso che la nuova regola vuole ostacolare. Il cooldown di Dependabot riduce soprattutto l’adozione immediata, mentre il blocco di PyPI preserva l’immutabilità pratica delle release più vecchie. Nessuno dei due controlli analizza automaticamente la logica del software, le chiamate di rete, gli script eseguiti durante l’installazione o l’eventuale sottrazione di segreti. I team devono quindi verificare le differenze tra le versioni, eseguire le build in ambienti isolati, limitare i token disponibili durante l’installazione e mantenere un inventario delle dipendenze transitive. Le applicazioni critiche dovrebbero utilizzare repository interni nei quali le nuove release vengono approvate soltanto dopo scansioni statiche, analisi dinamiche e un periodo di osservazione.

GitHub e PyPI rallentano l’automazione per guadagnare sicurezza

La ricostruzione delle nuove protezioni temporali di GitHub e PyPI mostra una modifica significativa nella filosofia dei registry: l’aggiornamento più recente non viene più considerato automaticamente la scelta migliore e la velocità di pubblicazione non deve trasformarsi nella velocità di compromissione. Dependabot introduce una zona di osservazione prima dell’adozione, mentre PyPI stabilizza le release impedendo modifiche tardive ai loro artefatti. Le due piattaforme non eliminano gli attacchi alla supply chain, ma aggiungono attrito nei momenti in cui gli aggressori dipendono maggiormente dall’automazione. Per gli sviluppatori, il cambiamento rafforza un principio operativo: gli aggiornamenti devono essere tempestivi quando correggono vulnerabilità, ma non così automatici da importare codice appena pubblicato senza concedere all’ecosistema il tempo necessario per valutarlo.