La catena di fornitura del software open source è sotto attacco incrociato. Trellix, colosso della cybersecurity, ha confermato un accesso non autorizzato al proprio repository di codice sorgente, avviando indagini forensi. In parallelo, i ricercatori di Socket.dev hanno smascherato una vasta campagna di attacchi alle supply chain che ha infettato repository Ruby Gems e Go Modules (tramite l’account BufferZoneCorp), oltre ad aver compromesso la versione ufficiale del pacchetto npm intercom-client. Sfruttando account GitHub hackerati e tecniche di esecuzione automatica come l’hook preinstall in Node.js o la funzione init() in Go, i pacchetti malevoli avvelenano le pipeline CI/CD, alterano i proxy di download (GOPROXY) ed esfiltrano in modo silente chiavi SSH private, token cloud (AWS, GCP) e credenziali Kubernetes. Un’ondata, parzialmente riconducibile alla campagna worm Mini Shai-Hulud, che dimostra la crescente fragilità degli ecosistemi di sviluppo.
Cosa leggere
Trellix indaga accesso non autorizzato al repository sorgente
Trellix conferma di avere identificato un accesso non autorizzato a una porzione del proprio repository di codice sorgente, aprendo immediatamente un’indagine forense con specialisti esterni e notificando le forze dell’ordine. L’azienda afferma che, sulla base delle verifiche iniziali, non emergono prove di compromissione del processo di release o distribuzione del codice, né indicazioni che il codice sorgente sia stato sfruttato in attacchi attivi. L’episodio resta comunque rilevante perché coinvolge un vendor di cybersecurity, quindi un soggetto che gestisce prodotti sensibili e infrastrutture usate da molte organizzazioni. L’incidente dimostra come gli attaccanti puntino sempre più spesso ai repository sorgente per ottenere informazioni su architetture interne, componenti proprietari, procedure di build e possibili debolezze sfruttabili in futuro. Anche senza manipolazione diretta degli artefatti distribuiti, l’accesso al codice può facilitare analisi offensive, sviluppo di exploit mirati e individuazione di percorsi di attacco contro clienti enterprise. Trellix promette trasparenza e aggiornamenti alla comunità di sicurezza, ma il caso rafforza l’urgenza di controlli più severi su repository, credenziali developer e accessi privilegiati.
BufferZoneCorp pubblica Ruby Gems e Go Modules malevoli contro developer
BufferZoneCorpAccount GitHub che ospita un insieme di repository Ruby e Go assemblati rapidamente.La campagna analizzata da Socket.dev ruota attorno all’account GitHub BufferZoneCorp, usato per pubblicare un cluster di repository collegati a Ruby Gems e Go Modules malevoli. I pacchetti imitano tool di sviluppo legittimi con nomi credibili e struttura apparentemente affidabile, sfruttando la fiducia degli sviluppatori negli ecosistemi open source. Tra i Ruby Gems segnalati compaiono pacchetti come knot-activesupport-logger, knot-devise-jwt-helper e knot-rack-session-store, pubblicati sotto l’utente RubyGems knot-theory.
La strategia è tipica delle campagne moderne di dependency poisoning: alcuni pacchetti partono come sleeper, cioè innocui o quasi inattivi, per guadagnare reputazione prima di ricevere aggiornamenti malevoli. Socket segnala sei Ruby Gems con payload attivi e un pacchetto dormiente, mentre nei Go Modules individua progetti come go-metrics-sdk, go-retryablehttp e go-stdlib-ext, con sette moduli weaponized e due sleeper. Questo modello permette agli attaccanti di ridurre i sospetti iniziali e colpire ambienti di sviluppo, runner CI e pipeline automatizzate quando la dipendenza risulta già integrata.
Ruby Gems rubano credenziali locali tramite extconf.rb e logger custom
I Ruby Gems malevoli sfruttano meccanismi tipici dell’ecosistema Ruby per eseguire codice durante l’installazione e l’uso della libreria. Il file extconf.rb, normalmente impiegato per configurare estensioni native, diventa un punto di attivazione del payload. A questo si aggiunge un logger custom che consente l’esecuzione a runtime, aumentando le occasioni in cui il malware può raccogliere informazioni sensibili dal sistema della vittima. Il bersaglio principale sono ambienti developer e macchine usate per build interne. Il codice cerca variabili d’ambiente contenenti stringhe come token, key, secret, pass, aws e github, quindi tenta di leggere file locali come ~/.ssh/id_rsa, ~/.aws/credentials, ~/.npmrc e ~/.gitconfig. I dati vengono impacchettati in formato JSON e inviati tramite HTTPS POST verso endpoint controllati dagli attaccanti. Questo tipo di furto è particolarmente pericoloso perché può consegnare chiavi persistenti, token di pubblicazione e credenziali cloud utilizzabili per muoversi oltre la macchina dello sviluppatore e raggiungere repository, ambienti CI/CD o infrastrutture di produzione.
Go Modules manipolano GOPROXY go.sum e workflow GitHub Actions
I Go Modules della campagna introducono tecniche ancora più invasive contro la supply chain. Il modulo go-metrics-sdk sfrutta la funzione init() per attivarsi automaticamente e modificare variabili usate dalle pipeline, incluso GITHUB_ENV. La manipolazione di GOPROXY, la rimozione di checksum da go.sum e la disabilitazione di GOSUMDB consentono agli attaccanti di indebolire i controlli di integrità e spingere la build verso fonti malevole. In un ambiente automatizzato, queste modifiche possono avvenire senza intervento umano diretto.
Altri moduli ampliano il raggio dell’attacco. go-retryablehttp imposta proxy HTTP e HTTPS e installa un wrapper fittizio del comando go, mentre go-stdlib-ext estrae credenziali da ~/.ssh/id_rsa e ~/.kube/config. Lo stesso modulo aggiunge una chiave SSH pubblica hardcoded a ~/.ssh/authorized_keys, garantendo persistence sulla macchina compromessa. L’uso combinato di manipolazione PATH, proxy malevoli e alterazione dei controlli Go consente agli attaccanti di controllare il processo di build, esfiltrare segreti e mantenere accesso anche dopo la rimozione apparente del pacchetto.
[email protected] viene compromesso tramite account GitHub Intercom
Il 30 aprile 2026 la versione [email protected] del pacchetto npm ufficiale viene compromessa, mentre la precedente 7.0.3 risultava pulita. L’attacco passa dall’account GitHub nhur, membro privato dell’organizzazione Intercom, usato per creare repository con nomi ispirati a Dune come ghola-melange e mentat-melange. In una finestra di circa 47 minuti, l’account modifica workflow CI/CD con commit spoofati a nome di identità come dependabot[bot] o claude, sfruttando la fiducia implicita nelle automazioni di sviluppo.
Un commit denominato “Test Commit” elimina il workflow ci.yml e introduce test.yml, attivando la pipeline di pubblicazione automatica della versione malevola. Il pacchetto include un hook preinstall che scarica ed esegue un binario Bun non verificato da GitHub. Il payload principale, contenuto in router_runtime.js, pesa circa 11,7 MB ed è fortemente offuscato. Il codice raccoglie credenziali da Kubernetes, Vault, AWS IMDS, ECS e GCP, poi cifra ed esfiltra i dati tramite GitHub API. Il rischio è amplificato dai circa 360.000 download settimanali del pacchetto e da oltre 100 progetti dipendenti.
Mini Shai-Hulud collega npm PyPI SAP CAP e pacchetti Intercom
La compromissione di intercom-client rientra nella campagna Mini Shai-Hulud, descritta come una worm attack focalizzata su ecosistemi multipli. Gli analisti osservano somiglianze tecniche con incidenti precedenti che hanno coinvolto PyPI, pacchetti SAP CAP, moduli Cloud MTA npm e librerie correlate a Intercom. La logica ricorrente include script preinstall, file JavaScript offuscati di grandi dimensioni, uso di Bun runtime, furto di credenziali e sfruttamento delle integrazioni GitHub per propagare il malware lungo le pipeline. Il modello Mini Shai-Hulud punta a trasformare la fiducia nella supply chain in un meccanismo di propagazione. Una volta ottenuto accesso a un account maintainer o a una pipeline di pubblicazione, gli attaccanti iniettano workflow malevoli, pubblicano pacchetti tainted e cercano segreti che consentano ulteriori compromissioni. Socket indaga se si tratti di un’estensione diretta delle precedenti campagne Shai-Hulud o di un copycat che replica tecniche già viste. In entrambi i casi, il dato centrale resta la maturità dell’operazione e la sua capacità di attraversare ecosistemi diversi con payload simili.
Segreti CI/CD diventano il bersaglio primario degli attacchi supply chain
Il punto comune tra Ruby, Go, npm e repository aziendali è il furto di segreti CI/CD. Gli attaccanti cercano chiavi SSH, token GitHub, credenziali AWS, file Kubernetes kubeconfig, segreti Vault, configurazioni npm e variabili d’ambiente presenti nei runner. Questi dati hanno valore operativo superiore a una semplice password perché possono consentire accesso diretto a repository privati, deployment automatici, bucket cloud, cluster Kubernetes e ambienti di produzione. Un singolo token con permessi eccessivi può diventare il ponte verso una compromissione molto più ampia. La pericolosità aumenta perché molti payload si attivano durante l’installazione del pacchetto, anche senza importazione esplicita nel codice applicativo. Questo significa che una dipendenza aggiunta per test, sviluppo o build può compromettere l’intera pipeline prima ancora che venga usata. Gli attaccanti sfruttano la natura automatica dei processi CI/CD e la presenza di segreti caricati nei job per esfiltrare credenziali in pochi secondi. La superficie di attacco non è più soltanto il codice applicativo, ma l’intero ciclo di sviluppo, build, test e pubblicazione.
Persistence e lateral movement sfruttano SSH proxy e workflow manomessi
Le tecniche osservate mostrano una forte attenzione alla persistence. Nei Go Modules, l’iniezione di una chiave pubblica in authorized_keys consente accesso continuativo alla macchina compromessa, anche dopo la chiusura della sessione iniziale. L’impostazione di proxy HTTP e HTTPS permette invece di deviare traffico e intercettare comunicazioni. La manipolazione del comando go tramite wrapper fittizio consente di alterare il comportamento degli strumenti developer e rendere la compromissione meno evidente agli occhi dell’utente. Nel caso npm, la manomissione dei workflow GitHub Actions permette agli attaccanti di modificare processi di build e pubblicazione, sfruttando commit spoofati e automazioni legittime. Questo approccio segue tecniche riconducibili a MITRE ATT&CK T1195.001 per la compromissione della supply chain, T1552.001 per il credential dumping e T1098.004 per l’iniezione di chiavi SSH. L’esfiltrazione verso endpoint come webhook.site o tramite GitHub API rende il traffico più difficile da distinguere da attività lecite, soprattutto in organizzazioni che usano GitHub come piattaforma centrale di sviluppo.
Organizzazioni enterprise rischiano compromissioni estese da singole dipendenze
L’impatto per le organizzazioni enterprise può essere significativo. Un pacchetto malevolo installato su una macchina di sviluppo o su un runner CI può raccogliere segreti sufficienti per accedere a repository privati, modificare dipendenze, pubblicare nuove versioni compromesse o raggiungere ambienti cloud. Nei casi peggiori, la compromissione può propagarsi a produzione attraverso pipeline automatizzate che si fidano delle dipendenze senza controlli aggiuntivi. Questo scenario rende gli attacchi supply chain particolarmente difficili da contenere, perché sfruttano processi legittimi e strumenti già autorizzati. La fiducia nell’open source non viene meno, ma richiede controlli più rigorosi. Le aziende devono trattare ogni nuova dipendenza come un potenziale punto di ingresso, soprattutto quando il pacchetto dispone di script lifecycle, accesso a file locali o esecuzione automatica in fase di installazione. La stessa vicenda Trellix dimostra che anche i vendor di sicurezza possono diventare target, perché repository e pipeline rappresentano asset strategici. In questo contesto, le policy di least privilege e la segregazione dei segreti diventano requisiti fondamentali, non opzioni avanzate.
Mitigazioni operative richiedono rotazione credenziali e controllo delle dipendenze
La risposta immediata deve partire dalla rimozione dei pacchetti indicati da Socket.dev, inclusi quelli collegati a BufferZoneCorp, knot-theory e alla versione compromessa [email protected]. Le organizzazioni devono ruotare tutte le credenziali potenzialmente esposte, inclusi token GitHub, chiavi AWS, credenziali Kubernetes, segreti Vault e chiavi SSH. È essenziale controllare ~/.ssh/authorized_keys, log CI/CD, variabili d’ambiente, modifiche ai workflow GitHub Actions e alterazioni di GOPROXY, GOSUMDB, go.sum o PATH. Sul piano preventivo, gli amministratori devono limitare i permessi dei token usati nelle pipeline, applicare scadenze brevi alle credenziali e separare i segreti per ambiente. La firma dei commit, la revisione obbligatoria dei workflow e l’uso di strumenti di scanning comportamentale sui pacchetti open source riducono il rischio di installare payload nascosti. Anche il blocco o la revisione degli script preinstall, postinstall, extconf.rb e funzioni init() nei contesti CI può impedire l’esecuzione automatica di codice sospetto. La mitigazione efficace richiede velocità, visibilità e controllo granulare.
Supply chain software 2026 richiede difesa continua su ecosistemi open source
L’ondata di maggio 2026 conferma che gli attacchi alla supply chain software sono diventati una minaccia strutturale. Ruby Gems, Go Modules, npm, PyPI e Packagist offrono agli attaccanti un’enorme superficie di propagazione perché milioni di progetti importano dipendenze in modo automatico. La combinazione di pacchetti sleeper, account maintainer compromessi, script di installazione e workflow CI/CD manomessi permette di raggiungere sviluppatori e aziende con un rapporto costo-impatto estremamente favorevole per gli aggressori. La risposta non può limitarsi alla rimozione dei pacchetti compromessi dopo la scoperta. Le organizzazioni devono costruire una difesa continua basata su monitoraggio delle dipendenze, controllo degli accessi, isolamento dei runner, revisione delle pipeline e rotazione sistematica dei segreti. La sicurezza del software non riguarda più soltanto il codice scritto internamente, ma l’intero ecosistema che entra nella build. Gli attacchi contro Ruby, Go, npm e Trellix mostrano che ogni passaggio della catena può diventare un vettore di compromissione su scala globale.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
