Per le traduzioni dei siti utilizziamo l'intelligenza artificiale e, sebbene ci sforziamo di essere accurati, non sempre le traduzioni sono precise al 100%. La vostra comprensione è apprezzata.
Casa/
Il blog
/
Da Dune a npm: il verme Shai-Hulud ridefinisce...
Da Dune a npm: il worm Shai-Hulud ridefinisce il rischio Supply Chain
da
OPSWAT
Condividi questo post
I fan di Dune riconosceranno "Shai-Hulud" come il nome dato ai colossali sandworm che rimodellano il deserto con la loro forza inarrestabile. Ora la comunità open-source si trova ad affrontare una minaccia informatica altrettanto temibile. Il 15 settembre, la comunità del software open-source ha affrontato una delle crisi più dirompenti: un worm autoreplicante, noto come Shai-Hulud, ha attraversato l'ecosistema npm, compromettendo più di 180 pacchetti in poche ore.
Librerie affidabili come @ctrl/tinycolor, crowdstrike-nodejs, string-kit, json-sugar, photon-colors e le forchette di digitato.js e data e ora sono già stati colpiti. Con milioni di download ogni settimana, le organizzazioni stanno inconsapevolmente inserendo infezioni attive direttamente nelle loro pipeline di compilazione.
Il worm sfrutta gli hook del ciclo di vita di npm per rubare le credenziali di GitHub e del cloud pubblico, quindi utilizza questi segreti per pubblicare aggiornamenti avvelenati ad altri progetti.
Flusso di attacco
Una versione compromessa di @ctrl/tinycolor inietta uno script locale dannoso (bundle.js).
Lo script bundle.js scarica ed esegue TruffleHog per scansionare i segreti di GitHub sul computer della vittima.
Utilizzando i segreti GitHub scoperti, lo script enumera i repository accessibili (proprietario, collaboratore o membro dell'organizzazione).
Per ogni repository, viene recuperato il ramo predefinito, creato un ramo shai-hulud e carica un file del flusso di lavoro su .github/workflows/shai-hulud-workflow.yml .
Il flusso di lavoro è configurato per attivarsi sugli eventi push. Il runner GitHub Actions esegue il lavoro nel contesto del repository, che ha accesso ai segreti.
Il flusso di lavoro legge i segreti di GitHub e li esfiltra verso un endpoint controllato dall'aggressore.
Perché questo è importante ora e a lungo termine
L'open source è aperto per design. Il registro npm serve centinaia di miliardi di download ogni mese e chiunque può pubblicare un pacchetto. Questa apertura spinge all'innovazione, ma crea anche opportunità per gli aggressori di armare la fiducia su scala.
L'epidemia rende inevitabile un fatto: la fiducia non è permanente. Un pacchetto che oggi è sicuro può essere compromesso domani.
Raccomandazione: Specificare le versioni esatte delle dipendenze
Si consiglia vivamente agli sviluppatori di evitare di installare automaticamente l'ultima versione. Al contrario, è consigliabile definire una versione specifica da installare, e rivedere e aggiornare manualmente le versioni più recenti solo dopo averle verificate.
Le dipendenze dichiarate con >= o * possono portare aggiornamenti non voluti, compresi i rilasci compromessi. Specificare una versione precisa e revisionata:
"dependencies": {
"lodash": "4.17.0"
}
Eseguire l'aggiornamento solo dopo aver convalidato l'autenticità e la sicurezza delle nuove versioni.
Ora e dopo: Bilanciare automazione e intervento umano
Ora: Risposta immediata
Avanti: Resilienza a lungo termine
Automatizzato: Controllare le dipendenze di npm e analizzare gli artefatti con più motori. Umano: Gli sviluppatori mettono in pausa le installazioni cieche e confermano manualmente le fonti di dipendenza.
Automatizzato: Incorporare la convalida continua della SBOM e la scansione delle minacce informatiche in ogni pipeline. Umano: I team di sicurezza esaminano regolarmente i pacchetti ad alto rischio e si attivano in caso di anomalie.
Automatizzato: Revocare e ruotare i segreti esposti. Umano: I team di sicurezza valutano l'utilizzo di credenziali sospette e decidono le misure di contenimento.
Automatizzato: Applicare i criteri di rotazione automatica e le impostazioni predefinite di minimo privilegio. Umano: I dirigenti stabiliscono gli standard di governance e assicurano la responsabilità per la fiducia nella catena di fornitura.
Automatizzato: Applicare i controlli MFA e di firma in CI/CD. Umano: I leader decidono quando rallentare le consegne per proteggere l'integrità.
Automatizzato: Richiedere commit firmati e una prova di compilazione verificabile per tutti i rilasci. Umano: I consigli di amministrazione trattano la fiducia nel software come una questione strategica di resilienza, non come una casella di controllo della conformità.
Il quadro generale
Per i dirigenti, questo attacco ricorda che il rischio della catena di fornitura del software è un rischio aziendale. Le autorità di regolamentazione si aspettano controlli verificabili e i clienti una prova di integrità. I consigli di amministrazione non possono più rimandare la responsabilità per il codice che alimenta le operazioni critiche.
Per i professionisti, l'epidemia dimostra che le pipeline devono evolversi. Ogni dipendenza open-source deve essere trattata come non attendibile fino a quando non si dimostra che è sicura. Le SBOM, le scansioni del malware e la sanitizzazione forniscono la linea di base, ma la consapevolezza umana - sospendere, interrogare, intensificare - è ciò che impedisce all'automazione cieca di importare il prossimo worm.
Il punto di vista di OPSWAT
Creare fiducia nella Supply Chain
Incidenti come gli attacchi alla catena di fornitura di ambienti open-source come npm sono la prova che le catene di fornitura del software sono ora carichi di lavoro critici. Il settore deve passare da una fiducia cieca a una fiducia verificabile.
George Prichici
Vicepresidente dei prodotti, OPSWAT
In OPSWAT crediamo che la fiducia nella catena di fornitura debba essere costruita, non data per scontata. Il nostro approccio si concentra sulla difesa in profondità:
Visibilità completa della catena di fornitura del software con integrazione SBOM per tracciare ogni componente software, identificare le vulnerabilità, gestire i rischi durante l'intero SDLC e verificare la provenienza in ogni fase.
Multiscanning con più di 30 motori per catturare malware polimorfi e altri malware nei pacchetti, soprattutto in quelli open-source di terze parti.
CDR (Content Disarm and Reconstruction) per neutralizzare i payload dannosi prima che vengano eseguiti.
Controlli di archiviazione e trasferimentoSecure che impongono confini di fiducia tra le pipeline CI/CD.
Questi controlli non si limitano a rilevare il rischio, ma sanificano attivamente i file e rafforzano la fiducia, riducendo la possibilità che incidenti come questo si propaghino a valle.
Lo sviluppo rapido e la sicurezza non si escludono a vicenda. I team di sviluppatori hanno bisogno di flussi di lavoro automatizzati di scansione e approvazione integrati nella catena di fornitura del software, in modo da poter proteggere il codice senza rallentare il ritmo.
George Prichici
Vicepresidente dei prodotti, OPSWAT
Sicurezza al passo con lo sviluppo
Con OPSWAT, la sicurezza si integra direttamente nei flussi di lavoro esistenti:
Integrazione della pipeline CI/CD - Scansioni automatiche e applicazione dei criteri all'interno di Jenkins, GitHub Actions, GitLab e altri ambienti di compilazione.
Scansione degli artefatti senza soluzione di continuità: convalida di pacchetti npm, container e binari come parte delle fasi di compilazione di routine.
Generazione e convalida di SBOM on demand - Produzione e verifica automatica di SBOM per ogni release, garantendo la provenienza senza costi aggiuntivi.
Esperienza trasparente per gli sviluppatori - La sicurezza viene eseguita in background, facendo emergere i problemi solo quando è veramente necessario intervenire.
Ganci di riparazione automatizzati - Quarantena o sanitizzazione dei file compromessi senza interrompere le build.
La cultura dello sviluppo guidato dalla velocità non deve entrare in conflitto con la necessaria convalida della sicurezza; i flussi di lavoro automatizzati di scansione e approvazione devono essere un must, con un impatto minimo sulla velocità di sviluppo.
Inserendo queste funzionalità nel ciclo di vita del software, OPSWAT aiuta le organizzazioni a raggiungere sia la velocità di sviluppo che la fiducia verificabile, un equilibrio che l'incidente di npm dimostra essere ormai essenziale.
Il worm npm Shai-Hulud è un chiaro segnale delle minacce che gravano oggi sul software. Gli aggressori non hanno bisogno di entrare nella vostra base di codice. Possono convincervi a installarli. Verificate ogni artefatto, integrate la resilienza in ogni fase e date alle persone la possibilità di agire quando la sola automazione non è sufficiente. Le organizzazioni che prendono sul serio questo aspetto definiranno il futuro delle catene di fornitura del software sicuro.
Siete pronti a proteggere la vostra catena di fornitura del software dalle più recenti minacce informatiche con soluzioni personalizzate e perfettamente integrate?
Ricevete gli ultimi aggiornamenti sull'azienda OPSWAT , le informazioni sugli eventi e le notizie che fanno progredire il settore.
le notizie che fanno progredire il settore.
