Ing. Calogero Bono
GitHub ha presentato il 20 ottobre 2026 il package firewall, un filtro che si mette tra i computer che installano pacchetti e i registri pubblici da cui questi li scaricano. Oggi è in anteprima pubblica per tutti i clienti di GitHub Enterprise Cloud e supporta soltanto npm. L'obiettivo è fermare il malware che colpisce nel momento dell'installazione, un rischio più forte per agenti AI e sistemi di build che installano dipendenze senza nessuno che controlli. Se sviluppi software o gestisci chi lo fa, è un segnale su dove sta andando la sicurezza della catena di fornitura.
Qualche termine, prima di entrare nei fatti. Un registro (o registry) è il deposito online da cui si scaricano i pacchetti, come npm per JavaScript. Una dipendenza è un pezzo di codice altrui che il tuo progetto usa. Le CI/CD sono le procedure automatiche che compilano e pubblicano il software. Una attestation SLSA è una dichiarazione verificabile su come e da chi un pacchetto è stato costruito. I metadati sono le informazioni sul pacchetto, per esempio l'elenco delle versioni disponibili.
Cos'è il package firewall di GitHub?
Secondo il changelog ufficiale di GitHub, negli ultimi tempi c'è stata una vera ondata di attacchi malware che sfruttano il momento in cui i pacchetti vengono installati. Agenti e runner di CI sono bersagli particolari, perché installano dipendenze per portare a termine un compito o una build senza una persona nel mezzo.
Il firewall si colloca tra gli endpoint, o i registri interni, e i repository di pacchetti a monte. Come riporta The Hacker News, GitHub lo descrive così. «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate,» cioè un cancello di regole applicate al momento dell'installazione.
Il tema non è teorico. Il sito The Register ha titolato su una campagna in cui gli attaccanti avrebbero trasformato le issue di GitHub in un attacco alla catena di fornitura contro 61 repository pubblici in meno di un'ora. Dalla pagina che abbiamo a disposizione non emergono altri dettagli, quindi non possiamo dire se e come le due notizie siano collegate.
Come funziona e quali controlli offre?
Il flusso ha due passaggi. Prima gli amministratori impostano le regole per la loro enterprise. Poi agenti di coding e host CI/CD puntano al firewall invece che direttamente ai registri pubblici. Sia le richieste di metadati sia i download passano dal firewall, che li valuta in base alla policy.
I controlli disponibili
Dall'elenco di The Hacker News risultano questi controlli.
- Blocco del malware noto, controllando gli avvisi attivi nel GitHub Advisory Database.
- Blocco per gravità delle vulnerabilità, sempre tramite il database. L'impostazione predefinita blocca solo il livello «Critical only», ma si può scegliere «High or higher», «Medium or higher» o «Any severity».
- Blocco dei downgrade di attestation. Il firewall confronta le attestation della versione richiesta con quelle delle versioni precedenti e ferma il download se manca l'attestation SLSA.
- Blocco dei nuovi script di installazione, cioè quelli che girano con gli hook preinstall o postinstall e possono essere usati per rubare dati sensibili.
- Periodo di attesa (cooldown), che impedisce di installare versioni più recenti dell'età minima configurata.
Il cooldown può andare da 1 a 365 giorni. Il valore predefinito è 1 giorno e si disattiva impostandolo a 0.
E se blocca un pacchetto buono?
Se un pacchetto viene bloccato per errore, l'utente può chiedere un'eccezione. Per GitHub il flusso è simile a quello di altre funzioni di GitHub Advanced Security. Secondo The Hacker News, la richiesta può essere approvata da amministratori e responsabili della sicurezza dell'enterprise.
Quanto costa e chi può usarlo?
Il servizio è disponibile in anteprima pubblica per tutti i clienti GitHub Enterprise Cloud, compresa la versione con residenza dei dati. Durante l'anteprima è gratuito. Quando arriverà la disponibilità generale, GitHub dichiara che sarà a pagamento in base al consumo misurato, in modo simile alla fatturazione di Actions.
GitHub spiega che l'anteprima serve a far crescere l'infrastruttura e ad aggiungere funzioni in base alle richieste dei clienti. Per le istruzioni di configurazione rimanda alla documentazione Protecting endpoints with package firewall.
Perché si parla tanto di periodi di attesa?
Il cooldown è la regola più semplice e, forse, la più diffusa. The Hacker News ricorda che nell'ultimo anno attese simili sono state introdotte in npm, Python, Visual Studio Code, Ruby, Bun, pnpm e Yarn. Il principio è ridurre la probabilità che una versione appena pubblicata e mai rivista finisca subito in una build.
Aiuta soprattutto contro chi prende il controllo dell'account di un maintainer e pubblica una versione avvelenata di un pacchetto popolare. L'attesa frena la diffusione rapida, manuale o automatica.
Lo stesso articolo segnala che Rust 1.100, in uscita il 12 novembre 2026, dovrebbe aggiungere un'età minima di pubblicazione configurabile per i crate. L'opzione si chiama «global-min-publish-age» e vive nel file cargo/config.toml. Se non è specificata, si applica un'attesa predefinita di sette giorni.
Sul rovescio della medaglia parla Socket, citata da The Hacker News. «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception,» dice la società. Aggiunge che un rilascio sfuggito ai controlli può semplicemente sopravvivere al cooldown. Il valore, secondo Socket, sta nel dare tempo a ricercatori, maintainer e registri di intervenire.
Limiti da conoscere
- Oggi il firewall supporta solo npm. Chi lavora con PHP, Python o altri ecosistemi non è coperto, e le fonti non indicano date per altri registri.
- È riservato ai clienti GitHub Enterprise Cloud. Le fonti non parlano di piani più piccoli.
- Siamo in anteprima. Funzioni, infrastruttura e prezzi possono cambiare, e il costo a consumo non è ancora quantificato.
- Non abbiamo dati indipendenti sull'efficacia. Le fonti riportano le dichiarazioni di GitHub, non test su malware reali, e non si parla di falsi positivi in numeri.
- Come ricorda Socket, il cooldown non rende innocuo il codice malevolo. Una versione non rilevata può restare nascosta oltre l'attesa.
Cosa cambia per chi lavora con il digitale
Il punto pratico è che la sicurezza si sposta dal controllo a posteriori al controllo prima dell'installazione. Per chi sviluppa con agenti AI che scrivono e installano da soli, questo significa avere una regola centrale invece di fidarsi del singolo agente. Se usi strumenti di sviluppo guidati dall'AI, è utile rileggere i rischi che abbiamo descritto nel nostro articolo sul vibe coding per la PMI.
Per le aziende italiane il tema tocca anche la conformità. La catena di fornitura del software è parte di quella che trattiamo nella guida al registro fornitori NIS2. Poter dimostrare che i pacchetti passano da un filtro con regole scritte è un argomento concreto, anche se nessuna fonte collega il firewall alla NIS2.
Chi usa molto open source dovrebbe ricordare che ogni dipendenza è un fornitore. Ne parliamo nell'approfondimento su open source in azienda. Anche chi non è cliente Enterprise può copiare l'idea con gli strumenti già disponibili, per esempio i periodi di attesa che alcuni gestori di pacchetti offrono.
Per i server di build e di produzione contano anche aggiornamenti e isolamento. Se vuoi un'infrastruttura curata da altri, c'è il nostro servizio di hosting e server gestiti. Se invece stai valutando un progetto su misura, trovi il percorso nello sviluppo di software su misura.
Il nostro parere
L'idea è giusta. Fermare un pacchetto prima che giri sul computer è più efficace che accorgersene dopo, e farlo in un punto unico evita di affidarsi alla disciplina di ogni sviluppatore o di ogni agente. Il fatto che GitHub parta proprio dagli agenti senza supervisione ci sembra una lettura onesta del problema.
Le riserve sono due. La prima è commerciale. Una protezione così utile, per ora riservata alla fascia Enterprise e a pagamento a consumo dopo l'anteprima, rischia di lasciare scoperti i piccoli team, che sono spesso i più esposti. La seconda è tecnica. Molti controlli si appoggiano al database di GitHub e al tempo, e il tempo non è una garanzia, come ammette la stessa Socket.
Per questo non lo vediamo come uno scudo definitivo. È un livello in più, utile se accompagnato da revisione delle dipendenze, blocco delle versioni e permessi minimi per gli agenti. Se pensi che basti accendere il firewall, ti stai dando una falsa sicurezza.
Domande frequenti
Il package firewall di GitHub è gratuito?
Sì, ma solo durante l'anteprima. GitHub dichiara che alla disponibilità generale sarà addebitato in base al consumo misurato, in modo simile a Actions. I prezzi non sono ancora indicati.
Funziona solo con npm?
Sì, al momento supporta solo pacchetti npm. Le fonti non annunciano date per altri ecosistemi. Se usi altri linguaggi, per ora devi cercare altre difese.
Chi può usarlo?
Tutti i clienti GitHub Enterprise Cloud, compresa la versione con residenza dei dati. Le fonti non menzionano altri piani. Gli amministratori configurano le regole per l'intera enterprise.
Cosa succede se blocca un pacchetto legittimo?
L'utente può chiedere un'eccezione. Secondo The Hacker News la richiesta può essere approvata da amministratori e responsabili della sicurezza. Il flusso, dice GitHub, è simile a quello di altre funzioni di Advanced Security.
Il periodo di attesa basta a fermare il malware?
No. Aiuta a guadagnare tempo contro le versioni appena pubblicate, ma Socket ricorda che il codice malevolo non diventa innocuo con l'età. Una release non rilevata può superare l'attesa.
Cosa guardare fino alla disponibilità generale
Nei prossimi mesi conviene seguire tre cose. Il prezzo a consumo che GitHub fisserà, l'eventuale estensione oltre npm e l'arrivo dell'attesa minima in Rust 1.100, prevista il 12 novembre 2026. Intanto puoi muoverti così.
- Elenca le dipendenze usate da CI e agenti, e decidi chi può installare cosa senza supervisione.
- Valuta un periodo di attesa sulle nuove versioni, sapendo che ritarda anche le correzioni legittime.
- Prepara una procedura per le eccezioni, con un responsabile che approvi in fretta ma con traccia scritta.
