L’8 ottobre la versione 0.5.144 di tensorlake, l’SDK TypeScript di una piattaforma per applicazioni e ambienti isolati destinati agli agenti di intelligenza artificiale, è comparsa su npm con un payload in grado di sottrarre token npm e GitHub, chiavi SSH, credenziali cloud e segreti custoditi in Vault, e di propagarsi ad altri pacchetti.
Nel 2026 non è una notizia rara. Il dettaglio che conta è il percorso: il pacchetto è stato pubblicato dal workflow di rilascio ufficiale del progetto, a partire da commit inseriti il giorno prima sul ramo principale con l’identità di un maintainer, e recava un’attestazione di provenienza valida. Qualsiasi controllo automatico che verifichi da dove proviene un pacchetto avrebbe dato la risposta corretta: repository giusto, pipeline giusta. Il contenuto era malevolo.
Il caso arriva a un mese esatto dalla pubblicazione, l’8 settembre, dell’aggiornamento trimestrale del Google Threat Intelligence Group sull’uso offensivo dell’IA, e a quattro settimane dall’11 settembre, data in cui sono diventati applicabili gli obblighi di segnalazione del Cyber Resilience Act. Il calendario mette uno accanto all’altro due modelli di responsabilità che non si incontrano.
Indice degli argomenti
Cyber Resilience Act e supply chain software: attacchi oltre la provenienza
Il rapporto, intitolato From Prompting to Autonomy, dedica una sezione a UNC6780, gruppo a motivazione finanziaria noto anche come TeamPCP, che da marzo conduce compromissioni su larga scala di PyPI, npm e Docker Hub. Le campagne di primavera, ricostruite tra gli altri da Unit 42, avevano colpito Trivy e le GitHub Action di Checkmarx KICS, due strumenti di scansione di sicurezza integrati in un numero enorme di pipeline, e da lì la libreria LiteLLM, che instrada le richieste verso decine di fornitori di modelli linguistici.
Software adottato per mettere in sicurezza la catena di fornitura è diventato il veicolo per contaminarla. Le credenziali raccolte vengono vendute o cedute a gruppi ransomware ed estorsivi: in un incidente seguito da Mandiant, l’accesso iniziale ottenuto da UNC6780 è passato a un secondo attore, che ha poi avanzato la richiesta di riscatto.
DUSTMAKER prende di mira coding assistant e ambienti di sviluppo
La novità di settembre riguarda il bersaglio. Il credential stealer DUSTMAKER contiene funzioni pensate per interagire con i coding assistant. Deposita file nelle directory nascoste che assistenti e ambienti di sviluppo usano per la configurazione di progetto, come .claude/, .vscode/ o .cursor/, zone che i sistemi EDR sorvegliano meno del registro di sistema o dei crontab, e li usa per istruire l’assistente a eseguire comandi durante le normali interazioni con lo sviluppatore.
Nelle pipeline compromesse crea attività con nomi rassicuranti come “Copilot Setup” per cercare altri token, poi cancella i log di esecuzione. In testa ai loader JavaScript, i ricercatori hanno trovato testo avversariale su armi biologiche e nucleari, verosimilmente inserito perché gli scanner di sicurezza basati su modelli linguistici rifiutino di analizzare il codice sottostante. Il gruppo ha inoltre pubblicato su PyPI fork trojanizzati di server MCP legittimi e iniettato codice nel repository ufficiale di un’estensione MCP per Azure Functions, usando account reali di sviluppatori.
Attestazioni valide da pipeline compromesse
Per chi si occupa di regolazione, il passaggio decisivo è un altro. Quando rileva di trovarsi in un ambiente di integrazione continua, DUSTMAKER estrae i token OIDC dalla memoria dei runner di GitHub Actions, si accredita come trusted publisher e pubblica versioni compromesse dei pacchetti con attestazioni SLSA Build Level 3 valide e firmate. Google nota che pacchetti pubblicati in questo modo superano i controlli di fiducia automatici degli agenti di codifica.
È lo stesso meccanismo che i registri stanno rendendo la norma per sostituire i token permanenti, indicati come il punto debole dopo le ondate Shai-Hulud: la credenziale effimera legata alla pipeline elimina il segreto da rubare, ma trasforma la pipeline stessa nel bersaglio. Il rapporto avverte infine che il rilascio pubblico del codice del gruppo favorirà l’emulazione delle sue tecniche. Tensorlake, che gli analisti riconducono alla famiglia Shai-Hulud e non direttamente a UNC6780, suggerisce che non serviva molto tempo.
La responsabilità nel Cyber Resilience Act ricade sul fabbricante
Il Regolamento (UE) 2024/2847 costruisce la sicurezza della catena di fornitura attorno a una figura: il fabbricante che immette sul mercato un prodotto con elementi digitali. È il fabbricante a dover esercitare la dovuta diligenza quando integra componenti di terzi, compresi quelli open source non messi a disposizione nell’ambito di un’attività commerciale (art. 13, par. 5). È lui a dover segnalare a chi mantiene un componente le vulnerabilità che vi individua (art. 13, par. 6) e a dover redigere una software bill of materials in formato leggibile da macchina, che copra almeno le dipendenze di primo livello (Allegato I, parte II).
Dall’11 settembre deve notificare tramite la Single Reporting Platform dell’ENISA le vulnerabilità attivamente sfruttate e gli incidenti gravi, con un preallarme entro 24 ore. Il resto degli obblighi si applicherà dall’11 dicembre 2027.
La logica regge: chi trae valore dall’integrazione di software altrui ne risponde verso il mercato, ed è l’unico soggetto con la scala e l’incentivo economico per sostenerne il costo. Le campagne del 2026 mettono però in luce una conseguenza di questa scelta. Il regolamento colloca la responsabilità dove il valore viene catturato; la compromissione avviene altrove.
La supply chain software fuori dal perimetro del CRA
Basta ripercorrere i punti in cui gli attacchi descritti sono andati a segno. Un registro di pacchetti, gestito come servizio. L’account di un maintainer, spesso un volontario. La memoria di un runner messo a disposizione da una piattaforma commerciale. Una directory di configurazione letta da un assistente di codifica. Nessuno di questi punti coincide con un operatore economico che immette un prodotto sul mercato. Lo sviluppatore che pubblica software libero senza monetizzarlo è fuori dal perimetro per scelta esplicita del legislatore; registri e piattaforme di integrazione continua sono servizi, mentre il CRA disciplina prodotti.
Il fabbricante a valle può fare tutto ciò che la norma gli chiede: valutare il componente, documentarlo, tenere aggiornata la SBOM, applicare le patch. Non ha però alcuna leva sul punto in cui il codice viene alterato, perché quel punto è fuori dalla sua catena contrattuale e, in larga parte, fuori dal campo di applicazione del regolamento. Ne deriva che un fabbricante può essere, nello stesso momento, conforme e compromesso.
Open source e Cyber Resilience Act: il ruolo limitato degli steward
Tra il fabbricante pienamente responsabile e il volontario escluso, il CRA ha introdotto una figura intermedia: l’open-source software steward, persona giuridica diversa dal fabbricante che sostiene in modo sistematico e continuativo lo sviluppo di specifico software libero destinato ad attività commerciali (art. 3, punto 14). In pratica, le fondazioni.
Il regime dell’art. 24 è volutamente leggero: una politica di cybersicurezza documentata, la cooperazione con le autorità di vigilanza del mercato su loro richiesta e una parte degli obblighi di notifica dell’art. 14, applicabile soltanto nella misura in cui lo steward partecipa allo sviluppo o fornisce i sistemi su cui lo sviluppo avviene. Niente marcatura CE e nessuna sanzione pecuniaria, qualunque sia la violazione (art. 64, par. 10).
Le linee guida adottate dalla Commissione il 27 luglio, C(2026) 5252, chiariscono che lo steward che offre solo supporto non tecnico, come governance, marchio, eventi o raccolta fondi, non ha obblighi di notifica. E la Commissione indica che gli obblighi di segnalazione degli steward decorrono dall’11 dicembre 2027, non dall’11 settembre 2026.
Obblighi che crescono lontano dal punto dell’attacco
Il quadro che ne risulta, oggi, è questo. Il fabbricante che integra una versione compromessa ha 24 ore per notificare una vulnerabilità attivamente sfruttata nel proprio prodotto. Lo steward del componente, se esiste, non ha obblighi di notifica fino a dicembre 2027 e non ne avrà di sanzionabili neppure dopo. Il maintainer volontario il cui account è stato sottratto non ne ha nessuno. Gli obblighi crescono man mano che ci si allontana dal punto in cui l’attacco è avvenuto.
Perché equiparare steward e fabbricanti non risolve il problema
Il compromesso, va detto, aveva buone ragioni. Le prime versioni della proposta avevano allarmato le comunità open source, che temevano un effetto paralizzante su chi pubblica codice gratuitamente, e il regime alleggerito ha evitato di scaricare su volontari e fondazioni senza scopo di lucro oneri pensati per l’industria. Trattare gli steward come fabbricanti non risolverebbe nulla: allontanerebbe chi mantiene i componenti senza renderli più sicuri.
Il limite sta nel criterio. La categoria è costruita su chi è il soggetto, sulla sua natura giuridica e sul suo rapporto con il mercato, e non sulla posizione che occupa nel percorso del codice. Sono proprio quelle posizioni, il nodo di pubblicazione, il runner, l’account con diritti di rilascio, a essere diventate il bersaglio.
SBOM e dovuta diligenza nella supply chain software
La SBOM di un prodotto che avesse incluso tensorlake 0.5.144 sarebbe stata esatta: nome corretto, versione corretta, provenienza verificabile. I pacchetti pubblicati da DUSTMAKER avrebbero esibito un’attestazione SLSA di livello 3. Il CRA non impone attestazioni di provenienza, ma è con questi strumenti, insieme alla SBOM, che i fabbricanti si stanno attrezzando per dimostrare la dovuta diligenza dell’art. 13, ed è su queste evidenze che tenderà ad appoggiarsi la verifica della conformità.
Descrivono che cosa c’è in un prodotto e da quale percorso è arrivato; non dicono se ciò che è arrivato è legittimo. Per di più l’Allegato I chiede di censire almeno le dipendenze di primo livello, mentre i worm di questa stagione si propagano attraverso quelle transitive, che il fabbricante spesso non sceglie e non vede.
La velocità degli attacchi supera i processi documentati
Anche la dovuta diligenza presuppone un tempo che gli attacchi non concedono. Un componente si valuta prima di integrarlo; la compromissione colpisce l’aggiornamento. Secondo Unit 42, nell’ondata di maggio contro TanStack sono state pubblicate 84 versioni malevole in sei minuti; le versioni compromesse di axios, a marzo, sono rimaste disponibili per circa tre ore.
E la decisione di aggiornare viene sempre più spesso presa, o eseguita, da un assistente di codifica dentro un ciclo automatico, che è esattamente l’anello che DUSTMAKER cerca di manipolare. La diligenza intesa come processo documentato produce evidenze per l’autorità di vigilanza, non una barriera per l’attaccante.
Il Cyber Resilience Act e i controlli sul punto di consumo
Se la superficie d’attacco non ha un fabbricante, chiedere di più agli steward non è la strada. È più utile tradurre la dovuta diligenza dell’art. 13 in controlli sul punto di consumo, l’unico che il fabbricante governa davvero: non accettare versioni pubblicate da pochi minuti o poche ore, costruire in ambienti isolati privi di segreti, fissare le dipendenze per hash anziché per numero di versione, trattare le configurazioni di progetto lette dagli assistenti come codice eseguibile e non come semplici impostazioni.
Le norme armonizzate che daranno contenuto tecnico agli obblighi del CRA, ancora in corso di elaborazione, sono la sede naturale per questa traduzione. Sul versante pubblico, i programmi volontari di attestazione per il software libero previsti dall’art. 25 e il finanziamento della manutenzione dei componenti critici restano gli strumenti che agiscono a monte senza presupporre che a monte ci sia un fabbricante.
Il punto cieco che la regolazione non riesce ad assegnare
Il CRA ha stabilito con precisione chi risponde quando un componente compromesso finisce dentro un prodotto. Non ha potuto stabilire chi debba impedire che ci finisca, perché nel punto in cui accade non c’è nessuno a cui chiederlo. Finché la regolazione continuerà a cercare un soggetto responsabile, l’ecosistema continuerà a offrire agli attaccanti posizioni che nessuno occupa.
Partecipa alla community