npm firewall porta i controlli delle policy nell’installazione dei package
L’npm firewall, ora disponibile in public preview, può ispezionare i software package prima che vengano installati e bloccare i download che violano le regole di sicurezza di un’organizzazione. npm è un ecosistema utilizzato per distribuire componenti software riutilizzabili, chiamati anche package o dependency. GitHub afferma che la funzionalità attualmente opera soltanto con npm ed è disponibile per tutti i clienti GitHub Enterprise Cloud, compresi quelli che utilizzano la versione del servizio con residenza dei dati.
GitHub, una controllata di Microsoft, colloca il controllo tra gli endpoint o i registry interni di un’organizzazione e gli upstream package repository. Un endpoint può essere una workstation di uno sviluppatore, un coding agent oppure un host di Continuous integration and continuous delivery, comunemente abbreviato in CI/CD, che crea e distribuisce automaticamente il software. Invece di contattare direttamente un package registry pubblico, questi sistemi inviano le richieste di metadata dei package e i download attraverso il nuovo layer di ispezione. L’npm firewall applica quindi le policy selezionate dagli amministratori aziendali e rifiuta i download che non superano tali controlli.
Questo approccio al momento dell’installazione mira a intervenire nel punto in cui una dependency dannosa può iniziare a essere eseguita su un sistema. Il rischio è particolarmente significativo quando gli agent di artificial intelligence e i CI runner recuperano automaticamente le dependency mentre completano un’attività o preparano una build, potenzialmente senza che una persona approvi ogni installazione. Poiché l’installazione di un package può eseguire software all’interno di un ambiente di sviluppo o di build, una release dannosa può esporre sistemi e informazioni sensibili prima che una verifica successiva identifichi il problema.
Una delle policy disponibili verifica le versioni richieste confrontandole con gli avvisi malware attivi nel GitHub Advisory Database. Un’altra può bloccare le versioni interessate da vulnerabilità segnalate. La soglia predefinita impedisce l’installazione soltanto per le vulnerabilità classificate Critical, ma gli amministratori possono scegliere in alternativa High o superiore, Medium o superiore oppure qualsiasi livello di gravità. Queste impostazioni consentono alle organizzazioni di decidere quanto debba essere restrittivo il processo di installazione, anche se GitHub richiede agli amministratori di configurare i controlli che desiderano applicare.
L’npm firewall può inoltre individuare cambiamenti nella software provenance. Confronta le attestation associate alla versione richiesta di un package con quelle associate alle release precedenti e può bloccare una versione priva di una SLSA attestation, un record che descrive come è stato prodotto il software. Questa funzione è progettata per impedire un attestation downgrade, nel quale una release più recente non include più le informazioni di software provenance disponibili per le versioni precedenti.
Un controllo separato rileva gli install scripts aggiunti di recente. Si tratta di comandi che un package può eseguire automaticamente tramite hook preinstall o postinstall, prima o dopo l’installazione. GitHub afferma che tali hook possono essere utilizzati impropriamente per sottrarre dati sensibili; la policy può quindi bloccare un package che li abbia introdotti di recente. In questo modo l’attenzione si concentra su un cambiamento comportamentale significativo, anziché trattare allo stesso modo ogni package script.
Gli amministratori possono inoltre imporre un cooldown period basato sull’età del package. Viene impedita l’installazione delle versioni più recenti rispetto all’età minima selezionata. L’impostazione accetta valori da 1 a 365 giorni, utilizza 1 giorno come valore predefinito e può essere disabilitata impostandola su 0. Se un package legittimo viene bloccato per errore o serve con urgenza, un utente può presentare una richiesta di eccezione affinché venga approvata da un amministratore aziendale o da un security manager.
L’idea basata sull’età della release sta arrivando anche in Rust, un linguaggio di programmazione i cui package sono noti come crate. Rust 1.100, la cui pubblicazione è prevista per il 12 novembre 2026, dovrebbe supportare un’età minima di pubblicazione configurabile. Gli utenti potranno definire un periodo di attesa espresso in giorni o settimane tramite l’opzione global-min-publish-age in cargo/config.toml, un file di configurazione utilizzato da Cargo. Se non viene specificato alcun valore, il valore predefinito previsto è un periodo di attesa di sette giorni che esclude le release pubblicate durante tale intervallo.
Nel corso dell’ultimo anno, periodi di attesa simili sono stati introdotti in npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm e Yarn. Il loro scopo è ridurre la possibilità che una versione appena pubblicata e non ancora verificata venga inserita immediatamente in una build automatizzata. Possono anche rallentare un attacco nel quale qualcuno assume il controllo dell’account di un maintainer e pubblica una versione compromessa di una dependency popolare, concedendo a ricercatori, maintainer e registry più tempo per identificarla e bloccarla.
Un periodo di attesa non dimostra che un package meno recente sia sicuro. Socket osserva che anche le correzioni legittime possono subire ritardi, a meno che gli sviluppatori non approvino un’eccezione, mentre il codice dannoso che rimane inosservato può semplicemente sopravvivere al cooldown period. Per i proprietari di siti web e le aziende, l’insegnamento pratico è considerare l’età minima dei package come un livello di protezione da affiancare agli avvisi malware, alle policy sulle vulnerabilità, ai controlli della software provenance e all’esame dei nuovi install scripts, anziché come una garanzia autonoma.
Le organizzazioni che cercano assistenza per la sicurezza complessiva del proprio ambiente di build e hosting possono prendere in considerazione AEU-I per servizi IT, infrastruttura e consulenza orientati innanzitutto alla sicurezza. Qualunque sia il modello di assistenza utilizzato, le richieste di eccezione devono essere sottoposte a una valutazione accurata, perché approvarne una rimuove la specifica barriera prevista dalla policy che aveva bloccato il package.