GitHub crea un firewall per bloccare i pacchetti malware prima dell'installazione

Installare una dipendenza software può bastare per compromettere un computer, sottrarre credenziali di accesso o esporre i segreti utilizzati nei processi di compilazione. Non serve necessariamente avviare l’applicazione che contiene il componente malevolo: alcuni package manager, tra cui npm, consentono l’esecuzione di script durante la stessa procedura di installazione.

Per affrontare una delle minacce più insidiose alla sicurezza della supply chain software, GitHub ha annunciato la disponibilità in anteprima pubblica di GitHub Package Firewall, un servizio che intercetta le richieste dirette ai repository dei pacchetti e impedisce il download delle dipendenze considerate rischiose.

Attacchi alla supply chain: i casi che hanno messo in crisi la fiducia nei pacchetti software

Un semplice comando npm install può trasformarsi in un’operazione ad alto rischio: anziché limitarsi a scaricare una libreria JavaScript, può innescare l’esecuzione di codice malevolo, sottrarre credenziali di accesso e compromettere interi ambienti di sviluppo.

A marzo 2026, la compromissione di Axios, una delle librerie JavaScript più utilizzate al mondo, ha dimostrato come basti alterare una dipendenza per distribuire un trojan ad accesso remoto (RAT) attraverso versioni apparentemente legittime di un pacchetto npm.

Gli episodi si sono moltiplicati nei mesi successivi. A maggio, la campagna Mini Shai-Hulud ha coinvolto 314 pacchetti npm, sfruttando meccanismi di propagazione automatica e furto di credenziali. A giugno, persino alcune librerie associate ai servizi cloud di Red Hat hanno distribuito codice capace di sottrarre token GitHub, credenziali cloud e altri segreti dai sistemi degli sviluppatori.

Non sono mancati attacchi su altri fronti. A marzo 2026, la compromissione di LiteLLM, popolare libreria Python per l’integrazione dei modelli AI, ha mostrato come anche i pacchetti distribuiti tramite PyPI possano trasformarsi in strumenti per il furto di credenziali e segreti. A maggio, la campagna Megalodon ha coinvolto oltre 5.500 repository GitHub, prendendo di mira i workflow GitHub Actions e dimostrando che gli attaccanti possono compromettere non soltanto le dipendenze, ma anche i processi automatizzati utilizzati per sviluppare e distribuire software.

Il denominatore comune è la fiducia accordata a componenti software che, pur provenendo da registry ufficiali, possono contenere istruzioni dannose eseguite già durante l’installazione.

Come nasce GitHub Package Firewall

Anziché limitarsi a individuare le vulnerabilità nelle dipendenze già installate, il servizio GitHub Package Firewall – disponibile in anteprima pubblica per i clienti GitHub Enterprise Cloud – introduce un filtro tra i sistemi di sviluppo e il registry npm: verifica i pacchetti richiesti, blocca quelli associati a malware o falle di sicurezza note e può impedire il download di versioni appena pubblicate o caratterizzate da modifiche sospette.

L’obiettivo è interrompere gli attacchi alla supply chain software prima che il codice potenzialmente pericoloso raggiunga workstation, server di compilazione e agenti AI.

La novità consiste nell’introdurre un intermediario tra i sistemi che richiedono le dipendenze e i registry pubblici da cui provengono i pacchetti. Il firewall non analizza soltanto il codice già presente in un repository: interviene mentre il package manager interroga il catalogo delle versioni disponibili e richiede gli archivi necessari all’installazione.

Le 5 verifiche applicate ai pacchetti npm

La documentazione tecnica di GitHub descrive 5 controlli configurabili, ciascuno destinato a contrastare una specifica categoria di rischio: gli amministratori possono gestirli dalle impostazioni dell’account Enterprise, nella sezione Policies, Package firewall.

Il primo verifica la presenza del pacchetto all’interno del GitHub Advisory Database, controllando le segnalazioni attive relative a malware conosciuti; se la versione richiesta corrisponde a una segnalazione, il firewall ne impedisce il download. La funzione risulta attiva per impostazione predefinita.

Un secondo controllo riguarda le vulnerabilità note: a differenza delle segnalazioni di malware, che identificano componenti considerati dannosi, le vulnerabilità descrivono difetti di sicurezza potenzialmente sfruttabili. Gli amministratori possono scegliere la soglia minima di gravità che determina il blocco: Critical, High, Medium oppure qualsiasi livello.

Il terzo controllo esamina le attestazioni SLSA (Supply-chain Levels for Software Artifacts, livelli di sicurezza della catena di fornitura degli artefatti software) associate alle versioni dei pacchetti. Sono dichiarazioni verificabili che forniscono informazioni sulla provenienza del codice e sul processo utilizzato per produrlo. Package Firewall può rilevare un peggioramento delle garanzie: se le precedenti versioni disponevano di attestazioni SLSA e quella richiesta non le presenta più, la nuova pubblicazione può essere bloccata.

La quarta verifica si concentra sugli script di installazione npm, una delle caratteristiche più delicate del sistema di distribuzione dei pacchetti JavaScript. Il firewall controlla se una versione introduce nuovi script eseguiti durante l’installazione, come preinstall o postinstall. Anche questa protezione è inizialmente attiva.

Una difesa preventiva che sposta la sicurezza prima dell’esecuzione

L’aspetto più interessante dell’iniziativa GitHub non è l’introduzione di un ulteriore archivio di vulnerabilità, ma la possibilità di utilizzare segnali differenti per decidere se un componente debba raggiungere o meno un ambiente di sviluppo.

Bloccare una software che certamente contiene malware è cosa praticamente immediata; più complesso è riconoscere una pubblicazione potenzialmente sospetta prima che emerga una segnalazione ufficiale.

Il vantaggio di uno strumento come GitHub Package Firewall, deriva dal fatto che ciascuna organizzazione può così adottare una politica più prudente senza dover modificare il codice sorgente delle applicazioni.

Restano da valutare l’affidabilità del servizio, il comportamento in presenza di numerose dipendenze appena pubblicate e l’impatto sulle procedure di compilazione che richiedono aggiornamenti immediati. Anche la futura integrazione con registry aggiuntivi sarà determinante per le aziende che utilizzano contemporaneamente pacchetti pubblici e privati.