GitHub Package Firewall: controlli npm prima dell’installazione

GitHub ha presentato un package firewall per npm: un controllo che confronta ogni pacchetto con la policy dell’azienda prima che venga installato e blocca malware noti, vulnerabilità critiche e versioni pubblicate da troppo poco tempo. Ne hanno scritto heise Security il 23 ottobre, Help Net Security il 28 e The Hacker News il 29 ottobre 2026. I dettagli tecnici che seguono sono riportati da Help Net Security, che ha raccolto anche le risposte di due responsabili di prodotto di GitHub.

Il firewall è una di quattro novità di sicurezza che GitHub collega alla crescita del software scritto con l’aiuto di agenti IA. L’obiettivo dichiarato è intercettare i problemi prima che un pacchetto arrivi sul portatile di uno sviluppatore, in una build o nell’ambiente di un agente di programmazione.

Come funziona il firewall

Secondo Help Net Security:

• il controllo avviene al momento dell’installazione, confrontando il pacchetto richiesto con una policy definita a livello di enterprise;
• i criteri di blocco sono tre: malware noto, vulnerabilità critiche e versioni appena pubblicate;
• ogni sviluppatore può attivarlo indirizzando npm verso il firewall: in pratica i pacchetti non arrivano più direttamente dal registro, ma passano dal filtro.

Per stabilire se una versione è «troppo nuova», ha spiegato Adam Leftik di GitHub, il firewall usa la data di rilascio presente nei metadati del pacchetto, che è responsabilità del gestore dei pacchetti. Le aziende possono modificare le regole e creare policy personalizzate con un periodo di attesa (soak time o cool-down) prima che una nuova versione sia installabile.

Le fonti disponibili non descrivono la configurazione esatta, la disponibilità per i diversi piani di GitHub né eventuali licenze necessarie, e parlano soltanto di npm.

Perché il periodo di attesa conta

Nella nostra lettura, il criterio sulle versioni nuove è il più interessante. Una versione malevola di un pacchetto legittimo, pubblicata con credenziali rubate o sfruttando una debolezza del processo di pubblicazione (come nel caso SlugFest di npm Trusted Publishing, di questo mese), è più pericolosa nelle prime ore e nei primi giorni, prima che venga segnalata e ritirata. Un periodo di attesa riduce questa finestra; il blocco del malware noto copre le versioni già identificate. La tecnica MITRE ATT&CK di riferimento è T1195.001 (Compromise Software Dependencies and Development Tools).

Alcuni limiti da tenere presenti, sempre nella nostra lettura:

• il filtro protegge solo le installazioni che passano dal firewall: una postazione, un job di CI o un agente configurati diversamente lo aggirano;
• il periodo di attesa ritarda anche le correzioni di sicurezza urgenti, per le quali serve una procedura di eccezione;
• il criterio sulle versioni nuove dipende dalla correttezza delle date nei metadati, come precisa la stessa GitHub.

Le altre novità annunciate

Help Net Security descrive anche le altre tre novità, che lavorano sul codice e sugli avvisi:

• AI Scan analizza ogni pull request alla ricerca di vulnerabilità nei linguaggi non coperti dalla scansione basata su regole, tra cui PHP, Shell e COBOL. Può anche analizzare un intero repository su richiesta, raggiungendo il codice già unito;
• l’estensione GitHub Security per l’app Copilot controlla le modifiche dello sviluppatore prima che esista una pull request; insieme a GitHub Code Security porta nell’app gli avvisi di code scanning, compresi quelli di AI Scan;
• l’analisi di raggiungibilità per gli avvisi di Dependabot verifica se il codice chiama davvero la funzione vulnerabile di una dipendenza: il percorso di chiamata si consulta in GitHub e gli avvisi si possono ordinare in base a questo.

Per le correzioni, Pierre Tempel di GitHub ha indicato sia i suggerimenti di fix nelle pull request, sia Agentic Autofix, che corregge gli avvisi in blocco su tutti gli strumenti di GitHub e su oltre 70 strumenti di partner.

Impatto per le aziende europee e italiane

npm è il registro di riferimento per JavaScript e TypeScript e alimenta applicazioni web, strumenti di sviluppo e pipeline di build in gran parte delle aziende che sviluppano software. Un pacchetto compromesso esegue codice sulle postazioni degli sviluppatori e sui runner di CI, dove si trovano token, chiavi e accessi ai sistemi di produzione. Gli agenti IA di programmazione aumentano il numero di installazioni fatte senza una revisione umana.

Per i soggetti NIS2, la sicurezza della catena di fornitura e dello sviluppo è tra le misure richieste: un filtro con regole scritte, applicato al momento dell’installazione, è una misura concreta e documentabile, a patto che copra davvero tutti i punti da cui si installano pacchetti.

Cosa fare subito

1. Se usi GitHub Enterprise, verifica nella documentazione di GitHub disponibilità e requisiti del package firewall per il tuo piano: le fonti non li riportano.
2. Definisci la policy: blocco di malware noti e vulnerabilità critiche, un periodo di attesa per le nuove versioni e una procedura di eccezione, con un responsabile, per le patch di sicurezza urgenti.
3. Rendi il passaggio obbligatorio: imposta la configurazione di npm in modo centralizzato nei repository, nei runner di CI, nelle immagini dei container e negli ambienti degli agenti IA. Dove possibile, impedisci alle reti di build l’accesso diretto al registro pubblico, così il filtro non si aggira.
4. Mantieni le difese di base: versioni fissate con il file di lock, installazioni con npm ci nelle pipeline e, dove possibile, script di installazione disattivati (--ignore-scripts).
5. Usa la raggiungibilità per dare le priorità, non per chiudere gli avvisi: una dipendenza vulnerabile non chiamata oggi può esserlo domani.

Come aiuta ARXDOME

ARX Sentry raccoglie l’inventario di software e processi di computer e server: aiuta a sapere dove girano Node.js, npm e gli agenti di programmazione, e quindi quali macchine devono rispettare la policy. ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto e, se una macchina ha installato una versione sospetta, consente di isolarla dalla rete in attesa delle verifiche.

Ultimo aggiornamento: 29 ottobre 2026