Nuove minacce nell'open source: worm, malware basati sull'intelligenza artificiale e abuso di fiducia

Nuove minacce agli ecosistemi open source: worm, malware elaborati dall'intelligenza artificiale e abuso di fiducia su larga scala

L'ecosistema open source sta affrontando un cambiamento di paradigma nelle minacce alla supply chain. I pacchetti dannosi tradizionali non si propagavano spontaneamente, l'intelligenza artificiale non era una prerogativa degli autori delle minacce e la diffusione degli attacchi era limitata.

Negli ultimi mesi abbiamo assistito alla convergenza di tre categorie di minacce che, pur riguardando singolarmente, rappresentano un spostamento fondamentale nel panorama dei rischi per lo sviluppo del software se considerati insieme:

• Vermi autopropaganti negli ecosistemi dei pacchetti: Pacchetti dannosi che si diffondono autonomamente tramite furto di credenziali e ripubblicazione automatica. Questo trasforma ogni computer di uno sviluppatore compromesso in un nuovo vettore di infezione.
• Generazione e sfruttamento di malware basati sull'intelligenza artificiale: Gli autori delle minacce utilizzano modelli linguistici di grandi dimensioni per scrivere payload, scoprire vulnerabilità e orchestrare attacchi alla velocità della macchina.
• Sfruttamento della fiducia su larga scala:Alcuni attori abusano sistematicamente delle ricompense per contributi open source, infrastrutture di repository e strumenti per sviluppatori, creando picchi di migliaia di pubblicazioni di pacchetti spam, che influiscono sui registri.

Le tecniche chiave che consentono attacchi sofisticati alla supply chain del software non sono più teoriche. Sono attive, documentate e sempre più accessibili anche ad autori di minacce meno sofisticati. La barriera per condurre attacchi alla supply chain è crollata: ciò che un tempo richiedeva team di aggressori esperti può ora essere eseguito da agenti di intelligenza artificiale con una supervisione umana minima.

Questo articolo esamina recenti incidenti che hanno coinvolto direttamente pacchetti open source dannosi o che hanno abusato delle infrastrutture di intelligenza artificiale e OSS, analizza le nuove tecniche che li hanno resi possibili ed esplora le capacità emergenti che potrebbero definire la prossima generazione di minacce. Nell'ultima sezione esamineremo cosa si può fare per limitare il rischio.

Sha1-Hulud: il primo attacco worm autoreplicante di Npm

Scoperto il 14 settembre 2025, Shai Hulud Rappresenta il primo attacco worm autopropagante documentato nell'ecosistema NPM. Il nome è stato scelto da autori di minacce che sembrano essere appassionati di fantascienza! L'attacco è iniziato con credenziali di sviluppatori compromesse, probabilmente ottenute tramite campagne di phishing che falsificavano NPM. login prompt o bypass MFA. Una volta all'interno, l'attacco worm ha eseguito un attacco in più fasi che ha trasformato il furto di credenziali in propagazione autonoma. L'attacco era abbastanza grave da meritare un CISUn avviso.

Architettura tecnica:

Il malware opera attraverso un payload JavaScript fortemente minimizzato e in bundle con Webpack (bundle.js) che viene eseguito tramite un hook postinstall…

Raccolta delle credenziali:

Una volta eseguito, il payload implementa una scoperta completa dei segreti:

• Dump process.env e analizza il file system alla ricerca di segreti ad alta entropia
• Esegue TruffleHog per la scansione sistematica delle credenziali
• Query endpoint metadati cloud (169.254.169.254, metadata.google.internal)
• Target token npm in .npmrc, GitHub PAT e CI/CD segreti

Infrastruttura di esfiltrazione:

L'attacco del worm impiega molteplici strategie di esfiltrazione:

• Abuso di GitHub Actions: Flussi di lavoro contenenti ${{ toJSON(secrets) }} che serializzano tutti i segreti del repository.

Propagazione autonoma:

Il meccanismo di autoreplicazione del worm funziona tramite il seguente algoritmo (in pseudo-codice):

funzione propagate(token, proprietario) { userPackages = npmApi.listPackages(proprietario, token); for (pacchetto in userPackages) { tgz = npmApi.fetchTarball(pacchetto, token); modificato = injectBundleAndPostinstall(tgz); npmApi.publish(modificato, token); } }

function propagate(token, owner) {
    userPackages = npmApi.listPackages(owner, token);
    for (pkg in userPackages) {
        tgz = npmApi.fetchTarball(pkg, token);
        modified = injectBundleAndPostinstall(tgz);
        npmApi.publish(modified, token);
    }
}

Con qualsiasi token npm rubato, il worm enumera tutti i pacchetti di proprietà del manutentore compromesso, inietta bundle.js con un hook postinstall e ripubblica. Questo comportamento autonomo ha fatto sì che il numero di pacchetti infettati aumentasse da decine a centinaia nel giro di poche ore.

Metriche di impatto:

• Rilevamento iniziale: 14 settembre 2025, di Daniel Pereira Il “paziente zero” sembra essere rxnt-authentication:0.0.3.
• Raggio dell'esplosione dell'attacco: Pubblicate circa 700 versioni di pacchetti dannosi, con obiettivi di alto profilo e milioni di download settimanali. Limitato ai pacchetti npm e ai repository GitHub.
• Infrastrutture: C2 a 217.69.3.218, esfiltrazione a 140.82.52.31:80/wall
• Persistenza: Flussi di lavoro GitHub sui rami denominati shai-hulud
• Indicatori osservabili: I repository sono diventati pubblici con -migration suffisso

Shai-Hulud è un worm che raccoglie informazioni riservate. Non ha tentato di rubare denaro o di cancellare l'infrastruttura. Le informazioni riservate esfiltrate e i repository esposti possono essere utilizzati per attacchi mirati, quindi i danni a valle causati dalle credenziali rubate potrebbero manifestarsi in seguito. Il vero costo sta nella correzione, nella rotazione delle credenziali e nel rischio di attacchi secondari.

Un effetto positivo è stato costringendo GitHub/NPM a prendere provvedimenti immediati : deprezzando i token classici legacy e altre credenziali di pubblicazione deboli e spingendo verso il "Giardino dell'Eden OIDC" di OpenSSF'S Pubblicazione affidabile .

Ma continuate a leggere! Il verme è emerso ancora una volta dalle sabbie di Arrakis.

Sha1-Hulud 2.0: Il verme Arrakis colpisce ancora

Due mesi dopo la campagna iniziale di Shai-Hulud, gli autori della minaccia sono tornati con "The Second Coming", un'ondata significativamente più aggressiva che ha imparato dai punti deboli del primo attacco. La campagna si è autoidentificata attraverso repository etichettati “Sha1-Hulud: La Seconda Venuta.”

Esaminiamo le differenze principali rispetto alla prima ondata. preinstall hook ha sostituito il vettore di esecuzione postinstall originale. Secondo Pantera, @asyncapi/avro-schema-parser@3.0.25 è stato il “paziente zero” di questa seconda ondata, sfruttando una vulnerabilità pull_request_target trigger del flusso di lavoro. (Se "conosci un amico che lo usa", per favore leggi Perché pull_request_target è così pericoloso? ).

Propagazione tra registri:

Il worm si è diffuso da npm a Maven Central tramite mirroring automatico. mvnpm strumento, che converte i pacchetti npm in artefatti Maven senza alcuna revisione di sicurezza, ripubblica automaticamente i pacchetti npm compromessi come posthog-node@4.18.1 as org.mvnpm:posthog-node:4.18.1.

Questo è stato il primo worm cross-registry noto: una compromissione di npm che ha avuto un impatto sull'ecosistema Java senza alcuna interazione diretta. Maven Central ha rimosso gli artefatti il ​​25 novembre 2025, ma la finestra di esposizione ha comunque interessato i carichi di lavoro Java/JVM e enterprise costruire sistemi.

Durata di Bun per Evasion:

Gli aggressori hanno schierato un preinstall: node setup_bun.js gancio che ha installato il buono runtime per eludere il monitoraggio specifico del nodo. Bun ha fornito un'esecuzione più rapida per il payload offuscato da oltre 480,000 linee (bun_environment.js) e ha bypassato la tradizionale strumentazione di Node.js.

GitHub Actions come infrastruttura di comando:

Il worm ha distribuito runner GitHub Actions nascosti e auto-ospitati in $HOME/.dev-env/ su Windows, macOS e Linux. Ancora più avanzato, ha creato discussion.yaml flussi di lavoro che ascoltavano gli eventi di GitHub Discussions ed eseguivano i corpi dei messaggi di discussione come comandi shell, trasformando di fatto GitHub Discussions in un canale C2 invisibile.

Capacità distruttiva del tergicristallo:

A differenza della prima ondata, che si concentrava sulla raccolta delle credenziali, Shai-Hulud 2.0 ha introdotto un tergicristallo distruttivo si attivava quando non erano disponibili credenziali valide per la propagazione. Questo "interruttore a uomo morto" garantiva danni anche in caso di fallimento della replicazione, segnalando un passaggio da operazioni puramente incentrate sullo spionaggio a campagne potenzialmente distruttive.

Nonostante l'utilizzo di tecniche stealth (runtime Bun, offuscamento), la campagna è stata estremamente rumorosa: ha comportato la ripubblicazione di centinaia di pacchetti, la creazione di più repository pubblici, il caricamento in massa di dump di credenziali e l'installazione di runner self-hosted di lunga durata. Questo ritmo aggressivo contrasta nettamente con i tradizionali attacchi alla supply chain che si basano sulla furtività. Suggerisce fiducia in un impatto rapido o una deliberata "tattica di sopraffazione" per massimizzare i danni in un breve lasso di tempo.

GlassWorm: il codice invisibile incontra la blockchain C2

Il 17 ottobre 2025, un'estensione di VS Code denominata GlassWorm ha introdotto due tecniche senza precedenti nel panorama delle minacce alla supply chain: codice dannoso invisibile che utilizza la furtività Unicode e un'infrastruttura di comando e controllo basata su blockchain.

Tecnica di occultamento Unicode:

La principale innovazione di GlassWorm risiede nell'abuso dei selettori di variazione Unicode, caratteri speciali che non producono alcun output visivo ma rimangono eseguibili in JavaScript. Questo crea codice dannoso che appare come righe vuote negli editor di codice, nei diff di GitHub e nell'evidenziazione della sintassi dell'IDE. Questa tecnica compromette radicalmente la revisione del codice da parte degli utenti, nascondendo la logica eseguibile all'interno di aree visivamente vuote.

L'attacco ha preso di mira le estensioni di VS Code nel marketplace OpenVSX. L'analisi dell'estensione CodeJoy (v1.8.3) ha rivelato ampie sezioni invisibili contenenti codice JavaScript eseguibile codificato con caratteri Unicode non stampabili. A uno sviluppatore che esamina il file, il contenuto appare normale, con righe vuote. Per il runtime JavaScript, si tratta di un payload malware completo.

Architettura C2 basata su blockchain:

GlassWorm implementa un meccanismo di comando e controllo inattaccabile utilizzando la blockchain Solana. Il malware esegue la scansione delle transazioni provenienti da un indirizzo di portafoglio hardcoded; i campi memo delle transazioni contengono oggetti JSON con URL codificati in base64.

Questa architettura crea notevoli vantaggi:

• Immutabilità: Le transazioni blockchain non possono essere modificate o eliminate.
• anonimia: I portafogli crittografici sono pseudonimi e difficili da tracciare.
• Resistenza alla censura: Nessun provider di hosting da mettere sotto pressione, nessuna infrastruttura da sequestrare.
• Traffico legittimo: Le connessioni ai nodi Solana RPC sembrano indistinguibili dalle normali attività blockchain.
• Aggiornamenti dinamici: È possibile caricare nuovi URL di payload per meno di $ 0.01 a transazione.

Anche se i difensori bloccano il server del payload decodificato (217.69.3.218), gli aggressori possono semplicemente pubblicare una nuova transazione che punta a un URL alternativo. Ogni sistema infetto recupererà automaticamente la posizione aggiornata.

Backup C2: Google Calendar

Per ridondanza, GlassWorm utilizza un evento di Google Calendar come canale C2 secondario. Il titolo dell'evento contiene un URL di payload codificato in base64.

https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D

https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D

In questo modo si fornisce un servizio legittimo che aggira i controlli di sicurezza e può essere aggiornato semplicemente modificando l'evento del calendario.

Consegna del carico utile:

I server C2 forniscono payload crittografati utilizzando AES-256-CBC. Le chiavi di decrittazione vengono generate per richiesta e trasmesse tramite intestazioni HTTP personalizzate, garantendo che i payload intercettati non possano essere decrittografati senza una nuova richiesta.

ZOMBI: capacità RAT a spettro completo

Il payload finale (ZOMBI) trasforma le postazioni di lavoro degli sviluppatori infette in infrastrutture criminali:

• Server proxy SOCKS: Distribuisce server proxy per instradare il traffico degli aggressori attraverso le reti delle vittime, consentendo l'accesso interno e l'anonimizzazione.
• WebRTC P2P: Stabilisce canali di controllo peer-to-peer che aggirano i firewall tramite NAT traversal.
• BitTorrent DHT: Utilizza tabelle hash distribuite per la distribuzione decentralizzata dei comandi che non possono essere arrestate.
• VNC nascosto (HVNC): Fornisce un accesso desktop remoto invisibile in esecuzione su desktop virtuali che non vengono visualizzati sullo schermo o in Task Manager.

Targeting del portafoglio di criptovaluta:

ZOMBI è attivamente alla ricerca di 49 diverse estensioni di wallet per criptovalute, tra cui MetaMask, Phantom e Coinbase Wallet. Combinato con l'accesso remoto invisibile, questo consente il furto diretto di fondi dai computer degli sviluppatori.

Raccolta e propagazione delle credenziali:

Come Shai-Hulud, GlassWorm raccoglie token npm, credenziali GitHub e token di accesso OpenVSX. Queste credenziali consentono la diffusione autonoma ad altri pacchetti ed estensioni, creando un comportamento di propagazione simile a quello dei worm.

Metriche di impatto:

• Rilevamento iniziale: Ottobre 17, 2025
• Installazioni totali: 35,800+ nel marketplace OpenVSX e VS Code (probabilmente gonfiato dai bot)
• Estensioni compromesse: 16 confermati (15 OpenVSX, 1 Microsoft Marketplace)
• Infrastruttura: C2 primario a 217.69.3.218, esfiltrazione a 140.82.52.31:80/wall
• Portafoglio Blockchain: 28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2 (Solana)
• Stato attuale: Attivo, con infrastruttura operativa al momento della stesura di questo documento

Cyber ​​spionaggio orchestrato dall'intelligenza artificiale

Stiamo tutti imparando a usare gli strumenti di intelligenza artificiale. Osservando le tecniche utilizzate nei recenti attacchi, ci si potrebbe chiedere: Gli autori delle minacce utilizzano l'intelligenza artificiale per creare malware? Certamente. Ma possono estendere ulteriormente gli attacchi utilizzando l'intelligenza artificiale come arma per l'orchestrazione. Quella che segue è una campagna di cyberspionaggio, ma immaginate le stesse tecniche applicate ad attacchi automatizzati mirati agli OSS.

Nel settembre 2025, Anthropic rilevato e interrotto il primo attacco informatico documentato eseguito in gran parte senza intervento umano. La campagna ha raggiunto l'80-90% di esecuzione autonoma utilizzando Claude Code come motore di orchestrazione, con agenti di intelligenza artificiale che eseguono ricognizioni, sfruttamento, spostamenti laterali ed esfiltrazione di dati. Questo segna il passaggio dagli attacchi assistiti dall'intelligenza artificiale alle operazioni informatiche orchestrate dall'intelligenza artificiale.

L'autore della minaccia, GTG-1002 (un gruppo sponsorizzato dallo Stato cinese), ha preso di mira circa 30 organizzazioni nei settori tecnologico, finanziario e governativo. Hanno sviluppato un framework autonomo che ha trasformato Claude Code da un assistente di programmazione a un motore per le operazioni informatiche.

L'intelligenza artificiale come sistema di orchestrazione

Invece di usare l'IA come consulente, GTG-1002 ha usato Claude come operatore primarioIl framework suddivideva gli attacchi multifase in attività isolate, ciascuna delle quali apparentemente innocua. Attraverso prompt attentamente studiati e personaggi ben definiti, gli aggressori inducevano Claude a eseguire azioni dannose senza comprenderne il contesto malevolo.

L'intelligenza artificiale ha eseguito le fasi tecniche, mentre il motore di orchestrazione ha monitorato lo stato della campagna, gestito le transizioni di fase e aggregato i risultati in sessioni della durata di giorni. Il coinvolgimento umano si è limitato alla supervisione di alto livello: inizializzazione, selezione del target, approvazione delle escalation e convalida dell'esfiltrazione.

Gli strumenti di base (scanner di rete, exploit di database) sono stati orchestrati tramite strumenti personalizzati Server MCP.

Questo approccio automatizza le operazioni a velocità impossibili per gli esseri umani. Claude ha persino analizzato i dati rubati per dare priorità alle informazioni preziose, mantenendo un contesto persistente tra le sessioni, mentre gli operatori umani tornavano in seguito per verificare i progressi.

Ingegneria sociale dell'intelligenza artificiale: aggirare i controlli di sicurezza

Il successo della campagna si basava sulla capacità di convincere Claude a eseguire attività di intrusione informatica nonostante la sua formazione in materia di sicurezza. La tecnica: inganno nel gioco di ruoloGli aggressori si sono spacciati per analisti della sicurezza informatica che svolgevano indagini legittime. Combinato con l'isolamento delle attività, questo è stato sufficiente per eludere i controlli di sicurezza dell'IA.

Le allucinazioni sono fantastiche!

Claude spesso allucinava i risultati: segnalava exploit riusciti che poi fallivano, inventava credenziali, inventava scoperte. Per ora, questo limita le operazioni completamente autonome, ma con il miglioramento dei modelli, queste debolezze diminuiranno. Fino ad allora, un difetto comune dell'IA è ironicamente il nostro migliore amico 🙃.

Rilevamento e risposta:

Anthropic ha rilevato la campagna attraverso modelli di utilizzo anomali che indicavano un comportamento di intrusione sistematico. Ha bloccato gli account associati, ha informato le organizzazioni interessate, si è coordinata con le autorità e ha integrato i modelli di attacco in controlli di sicurezza più ampi.

Implicazioni sulla catena di fornitura:

Ogni tecnica qui dimostrata si trasferisce direttamente agli ecosistemi dei pacchetti. L'intelligenza artificiale potrebbe scoprire autonomamente i manutentori vulnerabili, generare pacchetti dannosi e orchestrare attacchi a livello di registro alla velocità della macchina. La barriera è passata da "team di criminali informatici esperti" a "operatore che comprende i prompt dell'intelligenza artificiale".

Hai bisogno di un esempio concreto di come l'intelligenza artificiale venga utilizzata per attacchi informatici? Leggi ShadowRay 2.0: Gli aggressori rivolgono l'intelligenza artificiale contro se stessa in una campagna globale , in cui gli avversari hanno utilizzato le funzionalità di orchestrazione di Ray ("il Kubernetes dell'intelligenza artificiale") per gestire una botnet di cryptojacking globale che si è diffusa autonomamente nei cluster Ray esposti.

Un altro esempio: S1ngularità attacco , sfruttando lo stesso pull_request_target problema menzionato in precedenza. Rileva gli strumenti AI CLI installati localmente (Claude, Gemini, Q con flag di bypass) e li utilizza per la ricognizione. Da telemetry.js carichi utili, i prompt includevano cose come questo:

Abuso delle infrastrutture: campagne di spam su larga scala

Oltre ai pacchetti che distribuiscono malware, l'ecosistema open source è soggetto ad abusi infrastrutturali attraverso campagne di spam che inondano i registri con migliaia di pacchetti. Il DevOps per la criminalità informatica è comune: gli aggressori lo utilizzano abitualmente. SCMe registri per OSINT, distribuzione di fasi di malware, estrazione di segreti e mantenimento del comando e del controllo. Ma queste piattaforme possono anche essere abusato per scopi non dannosiSebbene tradizionalmente non siano dannose, tali campagne consumano risorse del registro, inquinano i risultati di ricerca e minano la fiducia.

Due esempi significativi dimostrano questa tendenza: Cibo indonesiano (sfruttando le ricompense dei collaboratori) e il Campagna degli Elfi (test del team rosso impazziti).

IndonesianFoods: Sfruttamento del protocollo TEA

La motivazione principale era la frode finanziaria attraverso sfruttamento del protocollo TEA , un sistema basato su blockchain progettato per compensare gli sviluppatori open source.

Gli aggressori hanno pubblicato migliaia di pacchetti interconnessi contenenti tea.yaml file collegati ai loro wallet Ethereum, formando reti di dipendenza circolari per gonfiare le metriche di contribuzione. Script automatizzati pubblicavano circa 12 pacchetti al minuto con nomi indonesiani e termini alimentari generati casualmente. Un file README del pacchetto vantava persino i guadagni in token TEA, confermando la motivazione finanziaria.

La campagna ha interessato circa 44,000 pacchetti, ovvero oltre l'1% di npm, ed è durata quasi due anni. Le dipendenze circolari hanno fatto sì che l'installazione di un singolo pacchetto potesse generare centinaia di pacchetti spam. I risultati di ricerca sono peggiorati, l'affidabilità nelle metriche dei pacchetti è diminuita e la larghezza di banda e lo spazio di archiviazione del registro sono stati pesantemente consumati.

Sebbene l'abuso del protocollo TEA sia stato documentato nell'aprile 2024, la rimozione sistematica non è avvenuta fino a novembre 2025, rivelando lacune critiche nel rilevamento degli abusi del registro. L'episodio ha minato la fiducia nei modelli di finanziamento basati su blockchain e ha messo in luce la facilità con cui i sistemi di ricompensa possono essere manipolati.

Campagna degli Elfi: Test automatizzati delle infrastrutture

. campagna degli elfi a dicembre 2025 ha sottolineato l'abuso dell'infrastruttura piuttosto che l'intento malevolo. Le descrizioni dei pacchetti facevano riferimento a "sfida cattura la bandiera" e "test" (incluso il testo francese: "Pacchetto generato automaticamente tutti i 2 minuti"), suggerendo origini nella ricerca sulla sicurezza o nell'esercizio CTF.cises.

I pacchetti sono stati seguiti in modo coerente elf-stats-* nomi con temi stagionali. Alcuni contenevano banali reverse shell (semplici one-liner bash), così poco sofisticati da sembrare progettati solo per test di rilevamento piuttosto che per un vero e proprio exploit.

Il ritmo operativo (un pacchetto ogni 2 minuti su più account) ha messo alla prova le capacità di limitazione della velocità e di rilevamento degli abusi di npm. La campagna ha dimostrato che il flooding automatizzato può persistere per ore o giorni prima dell'intervento, consumando risorse di archiviazione, larghezza di banda e moderazione.

Ma, cosa ancora più importante, ha segnalato ad altri autori di minacce che gli attacchi di flooding automatizzati sono fattibili, il che potrebbe potenzialmente ispirare future campagne di abuso.

Nuove tattiche, tecniche e procedure (TTP)

Postura difensiva

È arrivata l'era dei worm della supply chain che si autopropagano. La difesa richiede automazione, vigilanza e controlli architetturali che presuppongono la compromissione anziché sperare nel rilevamento. Ogni installazione di pacchetto è un potenziale vettore di infezione. Ogni credenziale è un meccanismo di propagazione. La questione non è più se gli attacchi si verificheranno, ma quanto velocemente è possibile rilevarli e contenerli quando si verificano.

Per difendersi dai pacchetti dannosi simili a worm è necessario passare dalla scansione reattiva alla prevenzione proattiva e al monitoraggio continuo:

Pipeline Controlli:

• Imponi installazioni solo con file di blocco (npm ci, yarn install --frozen-lockfile) per impedire gli aggiornamenti automatici delle dipendenze e garantire un rigoroso pinning della versione.
• Implementa la scansione pre-installazione dei pacchetti e degli alberi delle dipendenze completi, bloccando i pacchetti dannosi prima dell'esecuzione.
• Blocca i pacchetti con caratteristiche sospette: bundle di grandi dimensioni, offuscamento, pre/post-installazione inaspettati hooks.
• Richiedere la revisione del codice per aggiunte e aggiornamenti delle dipendenze.

Gestione delle credenziali:

• Ridurre al minimo l'ambito del token: quando possibile, i token di pubblicazione dovrebbero essere destinati solo a pacchetti specifici.
• Implementare token di breve durata con rotazione automatica.
• Non memorizzare mai i token nel codice sorgente o nelle variabili di ambiente.
• Utilizzare account di servizio CI dedicati con privilegi minimi.

Rilevamento e monitoraggio:

• Tieni traccia dei modelli di pubblicazione e segnala eventuali picchi insoliti da parte dei singoli responsabili.
• Monitorare i flussi di lavoro di GitHub Actions per la serializzazione segreta, come toJSON(secrets).
• Aggiunte al flusso di lavoro di scansione per richieste HTTP esterne.
• Rileva nuovi repository pubblici con nomi insoliti o contenuti codificati.
• Monitorare le postazioni di lavoro degli sviluppatori per server proxy inaspettati, CI/CD runner, processi VNC o query RPC blockchain.

Risposta agli incidenti:

• Trattare qualsiasi esecuzione di installazione sospetta hooks come un compromesso completo.
• Supponendo che tutti i token sugli host compromessi siano stati rubati, ruotare immediatamente.
• Ricostruzione interessata CI/CD corridori da immagini pulite.
• Controlla tutti i pacchetti di proprietà di account compromessi per individuare versioni dannose.
• Verificare la persistenza nei flussi di lavoro di GitHub e nelle impostazioni del repository.

I produttori di intelligenza artificiale affermano spesso che qualsiasi strumento può essere utilizzato per il bene o per il male. I sistemi di intelligenza artificiale non possono impedire completamente il doppio uso, ma possono creare attriti e migliorare la visibilità forense. La vera domanda progettuale non è "si può abusare dell'intelligenza artificiale?", ma "quanto attrito possiamo aggiungere senza compromettere l'utilità legittima?". Un fatto rimane: il jailbreak degli attuali sistemi di intelligenza artificiale è fin troppo facileL'analisi dei prompt dannosi negli attacchi recenti mostra che il non determinismo LLM si estende ai loro guardrails.

Stanno emergendo diverse idee per migliorare la sicurezza dell'IA: autenticazione avanzata dell'origine, isolamento affidabile dei contenuti e controlli basati sulle policy per i sistemi esterni (con MCP e protocolli simili che stanno entrando nel panorama). Solo il tempo ci dirà se l'IA diventerà la prossima arma per attacchi su larga scala alle infrastrutture OSS.

Scopri di più

• Shai-Hulud: Il worm dei pacchetti npm spiegato
• Attacco alla catena di fornitura Shai-Hulud 2.0 NPM
• GlassWorm: il primo worm auto-propagante che utilizza codice invisibile arriva sul marketplace OpenVSX – Koi Security
• Smantellamento della prima campagna di spionaggio informatico orchestrata dall'intelligenza artificiale – Anthropic
• Analisi dei prompt dell'IA utilizzati nell'attacco Nx
• Compromissione diffusa della catena di fornitura che ha un impatto sull'ecosistema npm – CISA
• Il nostro piano per una catena di fornitura npm più sicura – Blog GitHub

L'autore

Scritto da Luis Rodriguez , Co-fondatore e CTO presso Sicurezza Xygeni.

Luis è un fisicocist, matematico e CISSP con oltre 20 anni di esperienza nella sicurezza del software. Ha guidato e contribuito a importanti iniziative di sicurezza in SAST, SCAe tecnologie avanzate di analisi del codice. Oggi si concentra su software supply chain security, combinando una ricerca approfondita con l'ingegneria pratica per aiutare i team a difendere i moderni DevSecOps pipelinedalle minacce emergenti.