GitHub chiude i rubinetti di npm: pubblicare pacchetti diventa più difficile

🛡️ Executive Summary

• Le configurazioni npm Trusted Publishing mai utilizzate scadono dopo 48 ore e devono essere validate attraverso una prima pubblicazione riuscita.
• npm rifiuta ora i token OIDC generati da workflow GitHub Actions attivati tramite issue_comment, oltre al blocco già applicato a pull_request_target.
• GitHub prepara gennaio 2027 come punto di rottura: i token granulari bypass-2FA perderanno la capacità di pubblicare direttamente e potranno soltanto inviare release in staging per approvazione umana.

GitHub sta progressivamente togliendo alle credenziali automatiche il potere di pubblicare direttamente codice su npm. Dopo oltre un anno di campagne supply-chain capaci di trasformare account di maintainer, token CI/CD e workflow GitHub Actions in macchine per distribuire pacchetti compromessi, il registry JavaScript entra in una fase diversa: non basta più autenticare chi invia una release, serve dimostrare che repository, workflow e identità siano ancora quelli ai quali il maintainer aveva deciso di concedere fiducia. Le ultime modifiche impongono una scadenza di 48 ore alle configurazioni Trusted Publishing non ancora validate, bloccano altri eventi GitHub Actions considerati troppo pericolosi e spingono le pipeline verso staged publishing e approvazione 2FA. Il cambiamento arriva mentre Matrice Digitale ha documentato nuove compromissioni npm capaci di colpire ambienti AI e rubare segreti cloud: la sicurezza della supply chain si sposta dal controllo del pacchetto al controllo dell’identità che ha il diritto di pubblicarlo.

Il trusted publishing ha ora 48 ore per dimostrare che il repository esiste davvero

La modifica più recente riguarda le configurazioni Trusted Publishing, il sistema con cui npm può autorizzare un workflow CI/CD attraverso token OIDC temporanei invece di affidarsi a segreti permanenti conservati nella pipeline. Dal 2 ottobre una configurazione appena creata e mai utilizzata può autorizzare una pubblicazione soltanto per 48 ore. Dopo il primo publish riuscito viene considerata validata e non è più soggetta a quella scadenza. Se invece repository o progetto cambiano identità deve essere creata una nuova relazione di fiducia, nuovamente sottoposta alla finestra di validazione. GitHub spiega che il vincolo serve a ridurre il rischio di configurare fiducia verso un nome che successivamente può cambiare proprietario: il registry non deve considerare equivalente un semplice identificatore testuale e l’identità immutabile del repository che ha effettivamente completato la pubblicazione. Parallelamente npm ha iniziato a rifiutare token Trusted Publishing generati da workflow avviati attraverso issue_comment, aggiungendo questo trigger al già vietato pull_request_target; per la pubblicazione vengono indicati eventi più controllabili come push, release e workflow_dispatch.

Leggi anche: GitHub Actions riattiva Mini Shai-Hulud: i tag malevoli erano ancora lì

Staged publishing separa chi costruisce il pacchetto da chi può renderlo pubblico

Il secondo pilastro è staged publishing, ormai disponibile anche per la creazione di pacchetti completamente nuovi. Una pipeline può costruire il tarball e inviarlo al registry attraverso npm stage publish, ma quella versione non diventa automaticamente installabile. Rimane in una coda dove deve superare i controlli e ricevere l’approvazione di un maintainer autenticato con 2FA. GitHub ha inoltre introdotto token granulari “read and write – stage only”, che possono caricare una release nello staging ma vengono esplicitamente rifiutati se tentano un normale npm publish. La separazione cambia il modello di rischio: rubare il token della pipeline può ancora consentire a un attaccante di preparare una versione ostile, ma non dovrebbe più essere sufficiente per distribuirla immediatamente a milioni di dipendenze. Da settembre l’approvazione è inoltre bloccata finché il pacchetto non completa la scansione malware automatica. È una risposta diretta al problema mostrato da Shai-Hulud quando pipeline autentiche hanno distribuito artifact malevoli apparentemente legittimi: una firma o un workflow corretto non certificano che chi lo controlla sia ancora il maintainer legittimo.

Gennaio 2027 chiude l’epoca dei token automatici che pubblicano senza 2FA

Il vero punto di rottura è però già fissato. Da gennaio 2027 npm prevede di rimuovere la pubblicazione diretta tramite granular access token configurati per bypassare la 2FA. Questi token hanno già perso la possibilità di eseguire operazioni particolarmente sensibili sull’identità dell’account, come creare altri token, cambiare maintainer o modificare configurazioni Trusted Publishing. Per le pipeline che non possono ancora migrare a OIDC, GitHub propone proprio i token stage-only: l’automazione continua a produrre e caricare il pacchetto, mentre il rilascio effettivo richiede l’intervento di una persona. Il risultato è un modello molto meno comodo per alcune catene CI/CD, ma anche molto più difficile da trasformare in un worm. Il problema emerso nelle campagne npm degli ultimi mesi non era infatti soltanto il furto di un segreto: una volta ottenuto un token con privilegi di publishing, malware come Shai-Hulud potevano enumerare i pacchetti controllati dalla vittima, manipolarli e ripubblicarli in sequenza, trasformando una singola identità compromessa in un moltiplicatore della propagazione.

npm v12 e la scansione malware spostano i controlli anche sul contenuto

Il rafforzamento dell’identità procede insieme a modifiche destinate al pacchetto stesso. Dal 2026 npm effettua una scansione malware al momento della pubblicazione prima che una release diventi installabile e può trattenere o bloccare i pacchetti sospetti. Per il codice dual-use esiste inoltre un campo contentPolicy accompagnato da un file DISCLOSURE, con obblighi di pubblicazione che impediscono di usare token capaci di aggirare la 2FA. npm v12 sta contemporaneamente restringendo gli install script automatici, altro vettore storicamente utilizzato per eseguire codice appena una dipendenza entra nel progetto. La difesa resta inevitabilmente incompleta: Matrice Digitale ha già mostrato come indexed-btree abbia spostato il payload dall’installazione al normale runtime della libreria. Nessuna policy sul publishing può quindi dimostrare che un pacchetto sia benigno per sempre, ma può diminuire drasticamente la probabilità che il semplice furto di un token consenta di trasformare una libreria legittima in malware nel giro di pochi minuti.

Continua con:
Shai-Hulud cerca credenziali in 469 percorsi di AI, cloud e CI/CD
Open VSX, npm e QuickFox allargano la crisi della supply chain

GitHub sta eliminando la pubblicazione basata sulla fiducia cieca nelle credenziali

Il disegno complessivo diventa chiaro osservando le modifiche insieme. Trusted Publishing lega la release a un’identità CI verificabile, la finestra di 48 ore impedisce di lasciare relazioni di fiducia indefinite prima della validazione, staged publishing separa il caricamento dalla distribuzione e la 2FA riporta una persona nell’ultimo passaggio critico. La scansione malware prova infine a verificare ciò che quella identità sta distribuendo. Non è un sistema capace di eliminare gli attacchi supply-chain: un maintainer può essere compromesso, un repository può contenere codice ostile e un pacchetto apparentemente innocuo può attivarsi soltanto in determinate condizioni. Ma GitHub sta riducendo il valore della credenziale rubata, ed è probabilmente il cambiamento più importante. Per anni la pipeline è stata progettata affinché un segreto custodito nel posto giusto potesse pubblicare software senza intervento umano; Shai-Hulud ha dimostrato che quella stessa efficienza era disponibile anche all’attaccante. npm sta quindi facendo una scelta scomoda ma razionale: rallentare di pochi passaggi la release legittima per impedire che la compromissione di un token diventi automaticamente una compromissione dell’intero ecosistema.