In questo articolo Indice dei contenuti 2 sezioni
GitHub Package Firewall è il nuovo servizio con cui GitHub prova a fermare i pacchetti malevoli prima ancora che vengano installati, ed è disponibile in anteprima pubblica. Il problema di fondo è più serio di quanto sembri, perché basta aggiungere una dipendenza software per compromettere un computer, sottrarre credenziali di accesso o esporre i segreti usati nei processi di compilazione. Non occorre nemmeno avviare l’applicazione che contiene il componente infetto. Alcuni package manager, a cominciare da npm, permettono infatti di eseguire script durante la procedura di installazione stessa. Il nuovo strumento intercetta le richieste dirette ai repository dei pacchetti e impedisce di scaricare le dipendenze ritenute rischiose.
Gli attacchi alla supply chain che hanno incrinato la fiducia
Un banale comando npm install può diventare un’operazione ad alto rischio. Invece di limitarsi a scaricare una libreria JavaScript, può far partire codice malevolo, rubare credenziali e mettere in crisi interi ambienti di sviluppo. A marzo 2026 la compromissione di Axios, tra le librerie JavaScript più diffuse al mondo, ha mostrato quanto sia facile distribuire un trojan ad accesso remoto attraverso versioni in apparenza legittime di un pacchetto npm.
Nei mesi seguenti gli episodi si sono moltiplicati. A maggio la campagna Mini Shai Hulud ha colpito 314 pacchetti npm sfruttando meccanismi di propagazione automatica e furto di credenziali. A giugno perfino alcune librerie legate ai servizi cloud di Red Hat hanno diffuso codice in grado di sottrarre token GitHub, credenziali cloud e altri segreti dalle macchine degli sviluppatori.
Anche altri ecosistemi sono finiti nel mirino. Sempre a marzo 2026 è toccato a LiteLLM, libreria Python molto usata per integrare i modelli di intelligenza artificiale, a dimostrazione che pure i pacchetti distribuiti tramite PyPI possono diventare strumenti per rubare segreti. A maggio la campagna Megalodon ha coinvolto oltre 5.500 repository GitHub prendendo di mira i workflow di GitHub Actions, cioè i processi automatizzati con cui il software viene sviluppato e distribuito. Il filo che lega tutti questi casi è la fiducia riposta in componenti che, pur arrivando da registry ufficiali, nascondono istruzioni dannose eseguite già al momento dell’installazione.
Come funziona il filtro e quali controlli applica
Invece di cercare le vulnerabilità nelle dipendenze già presenti, GitHub Package Firewall si piazza tra i sistemi di sviluppo e il registry npm. Il servizio, riservato per ora ai clienti GitHub Enterprise Cloud, verifica i pacchetti richiesti, blocca quelli associati a malware o falle note e può negare il download di versioni appena pubblicate o con modifiche sospette. L’idea è interrompere l’attacco prima che il codice pericoloso arrivi su workstation, server di compilazione e agenti AI. Il firewall interviene proprio mentre il package manager consulta il catalogo delle versioni e richiede gli archivi da installare.
La documentazione tecnica descrive 5 controlli configurabili, gestibili dagli amministratori nelle impostazioni dell’account Enterprise alla voce Policies, Package firewall. Il primo confronta il pacchetto con il GitHub Advisory Database e, se la versione richiesta corrisponde a una segnalazione di malware attiva, ne blocca lo scaricamento. Questa funzione è abilitata di default. Il secondo riguarda le vulnerabilità note, ossia difetti di sicurezza potenzialmente sfruttabili, e lascia scegliere la soglia minima di gravità che fa scattare il blocco tra Critical, High, Medium oppure qualsiasi livello.
Il terzo controllo esamina le attestazioni SLSA, dichiarazioni verificabili sulla provenienza del codice e sul processo con cui è stato prodotto. Se le versioni precedenti ne erano provviste e quella richiesta non le ha più, la nuova pubblicazione può essere fermata. La quarta verifica si concentra sugli script di installazione npm, controllando se una versione introduce nuovi script come preinstall o postinstall. Anche questa protezione risulta attiva fin dall’inizio.
Il punto più interessante non è l’ennesimo archivio di vulnerabilità ma l’uso di segnali diversi per decidere se un componente debba raggiungere un ambiente di sviluppo. Bloccare un software che contiene sicuramente malware è quasi immediato, mentre è molto più complicato riconoscere una pubblicazione sospetta prima che arrivi una segnalazione ufficiale. Ogni organizzazione può così adottare una politica più prudente senza toccare il codice sorgente delle proprie applicazioni. Andranno verificati l’affidabilità del servizio, il comportamento con molte dipendenze appena pubblicate e l’impatto sulle compilazioni che richiedono aggiornamenti immediati, mentre l’integrazione con altri registry sarà decisiva per le aziende che usano insieme pacchetti pubblici e privati.
Fonte: TecnoAndroid