Settembre si è rivelato un mese particolarmente critico per npm, il registro di pacchetti JavaScript di proprietà di GitHub. Una serie di attacchi informatici mirati ha infatti preso di mira i maintainer dei pacchetti, sfruttando sofisticate campagne di phishing e introducendo malware in centinaia di librerie. Il risultato è stato devastante, con oltre 500 pacchetti infettati da codice malevolo progettato per sottrarre segreti e credenziali sensibili.

A fronte di questa escalation, GitHub ha deciso di accelerare sul fronte della sicurezza, annunciando un pacchetto di novità che ridisegna il processo di autenticazione e pubblicazione dei pacchetti npm. L’obiettivo è sia ridurre i rischi legati a credenziali rubate o token a lunga durata, sia garantire che ogni pacchetto caricato provenga da una fonte verificata e attendibile.

Xavier René-Corail, a capo del GitHub Security Lab, ha spiegato che nei prossimi mesi verranno progressivamente abbandonati diversi sistemi di autenticazione ritenuti obsoleti e vulnerabili. Tra questi ci sono i “classic tokens” e i codici OTP utilizzati per la 2FA, che in passato hanno rappresentato un livello di protezione accettabile ma che oggi non sono più considerati sufficienti. Un altro cambiamento significativo riguarda la durata dei token di accesso, che sarà drasticamente ridotta. Al posto dei token permanenti, verranno introdotti strumenti di pubblicazione basati su credenziali a tempo limitato e sull’uso obbligatorio della 2FA per le pubblicazioni locali.

In pratica, chiunque voglia pubblicare su npm avrà tre sole possibilità:

  • Pubblicazione locale con 2FA attivata
  • Utilizzo di token granulari validi per un massimo di sette giorni
  • Trusted publishing tramite pipeline CI/CD

La novità più importante è rappresentata proprio dal trusted publishing, un sistema di rilascio dei pacchetti che evita i rischi legati ai token statici e a lunga durata. Già sperimentato con successo dal Python Package Index (PyPI), il meccanismo si basa su OpenID Connect (OIDC) per verificare che il pacchetto provenga da un workflow automatizzato e autorizzato, generando un token temporaneo valido solo per il tempo necessario alla pubblicazione.

Al momento, npm supporta il trusted publishing solo attraverso GitHub Actions e GitLab CI/CD, ma GitHub ha già confermato che in futuro verranno inclusi ulteriori provider e anche i runner self-hosted. Attualmente, infatti, solo i runner cloud-hosted sono compatibili, una limitazione che potrebbe ostacolare gli sviluppatori che preferiscono infrastrutture personalizzate. Altri ecosistemi hanno già adottato approcci simili come nel caso di RubyGems, crates.io per Rust e NuGet per .NET (quest’ultimo è stato introdotto da Microsoft proprio pochi giorni fa).

Cloudflare zero trust

Crediti: Shutterstock

I dubbi della community

Nonostante l’evidente rafforzamento delle misure, alcuni sviluppatori hanno espresso perplessità. Andrey Sitnik, maintainer del popolare progetto PostCSS, ha dichiarato di avere riserve sull’uso di OIDC. A suo avviso, infatti, l’aggiunta del trusted publishing tramite pipeline CI può introdurre nuovi rischi, con un eventuale malware presente nelle dipendenze del progetto che potrebbe manipolare commit e tag, propagando codice non sicuro attraverso un flusso automatizzato.

Altri sviluppatori hanno sottolineato come OIDC non rappresenti una soluzione definitiva, ma piuttosto uno spostamento del problema, visto che l’autenticazione viene delegata a un’altra piattaforma, che a sua volta deve essere considerata affidabile. Da qui la richiesta di ulteriori garanzie, come la possibilità di richiedere più revisioni obbligatorie prima di modificare le impostazioni critiche di un pacchetto, rendendo più difficile per un attaccante sfruttare un singolo account compromesso.

GitHub ha ammesso che la volontà iniziale era quella di consentire una transizione graduale al trusted publishing, lasciando agli sviluppatori il tempo di adattarsi. Tuttavia, la pressione esercitata dagli attacchi sempre più frequenti ha reso evidente che i malintenzionati non hanno intenzione di aspettare. Nonostante ciò, per evitare interruzioni massicce nei workflow esistenti, i cambiamenti non entreranno in vigore in maniera immediata e rigida. L’introduzione sarà invece graduale e al momento non è ancora stata comunicata una data ufficiale per l’obbligatorietà delle nuove regole.

Un passaggio cruciale per l’ecosistema JavaScript

La sicurezza della supply chain del software è oggi una delle priorità assolute per l’intera industria tecnologica. Gli attacchi agli ecosistemi di pacchetti open source non sono un fenomeno isolato e il caso npm conferma come ogni anello debole possa trasformarsi in un varco pericoloso. Le misure annunciate da GitHub puntano a limitare il potere degli aggressori, rendendo più difficile l’abuso di credenziali e semplificando la verifica delle fonti. La sfida sarà quella di conciliare sicurezza e usabilità evitando di complicare eccessivamente la vita agli sviluppatori, pur mantenendo un livello di protezione all’altezza delle minacce attuali.

Il futuro di npm e dell’intero ecosistema JavaScript passa dunque dal rafforzare i processi di pubblicazione e garantire la massima trasparenza e tracciabilità. Un passo necessario per difendere non solo i maintainer, ma anche milioni di sviluppatori e aziende che ogni giorno fanno affidamento su queste librerie per costruire applicazioni critiche e servizi digitali di nuova generazione.