Google avverte: gli attacchi supply chain open source cresceranno ancora

🛡️ Executive Summary

• Gli attaccanti compromettono repository, account dei maintainer, dipendenze e workflow CI/CD per distribuire malware attraverso pacchetti open source apparentemente legittimi.
• I pacchetti malevoli individuati sono aumentati del 1.444% in un anno, mentre AI e vibe coding ampliano velocità e superficie degli attacchi.
• Google raccomanda SBOM e ABOM, quarantena delle nuove release, token temporanei, runner effimeri, sandbox e segmentazione della rete.

Gli attacchi contro la supply chain del software open source sono entrati in una fase di espansione sistemica. Secondo Google Threat Intelligence Group e Mandiant, le campagne osservate nel 2025 e nella prima metà del 2026 hanno colpito soprattutto repository di codice, dipendenze, registri di pacchetti e strumenti utilizzati dagli sviluppatori. Gli aggressori non devono più compromettere direttamente ogni azienda: è sufficiente prendere il controllo di un account fidato, di una pipeline o di un pacchetto molto diffuso per raggiungere contemporaneamente migliaia di ambienti. Google prevede che queste tecniche continueranno a crescere per tutto il 2026, favorite anche dall’intelligenza artificiale e dalla diffusione del vibe coding.

Repository e dipendenze sono il nuovo punto di ingresso

La maggior parte degli incidenti più rilevanti analizzati da Google riguarda la categoria T1195.001 del framework MITRE ATT&CK, relativa alla compromissione delle dipendenze e degli strumenti utilizzati durante lo sviluppo. Rispetto agli attacchi tradizionali contro i sistemi di aggiornamento di un produttore, colpire l’open source richiede meno preparazione, offre una distribuzione potenzialmente enorme e consente di sfruttare la fiducia attribuita automaticamente a nomi, repository e maintainer conosciuti. Gli aggressori possono pubblicare un pacchetto imitativo, prendere il controllo di un progetto reale, inserire una dipendenza malevola oppure manipolare un workflow di rilascio. Il codice viene poi scaricato da sviluppatori, sistemi di build e pipeline automatizzate che spesso possiedono token GitHub, chiavi cloud, credenziali npm, accessi Kubernetes e certificati di firma. È lo stesso modello emerso nella compromissione di AsyncAPI, dove workflow ufficiali hanno distribuito Miasma con una provenance formalmente valida. La firma del processo di build certificava l’origine tecnica dell’artefatto, ma non poteva stabilire che il codice di partenza fosse stato inserito da un intruso.

TeamPCP e Axios mostrano la nuova scala degli attacchi

Google attribuisce al gruppo UNC6780, conosciuto anche come TeamPCP, una serie di compromissioni condotte tra febbraio e maggio 2026 contro PyPI, npm e Docker Hub. Il gruppo ha sfruttato vettori differenti, compreso l’abuso del trigger privilegiato pull_request_target di GitHub Actions, per ottenere segreti e permessi di scrittura nei repository. I pacchetti compromessi distribuivano infostealer come SANDCLOCK, progettati per raccogliere credenziali da rivendere oppure trasferire a gruppi ransomware e operatori specializzati nell’estorsione.

Un altro caso emblematico è stato l’inserimento di una dipendenza malevola nel pacchetto Axios, scaricato più di 100 milioni di volte ogni settimana e utilizzato a sua volta da decine di migliaia di altri moduli. L’account di un maintainer sarebbe stato sottratto tramite ingegneria sociale e usato per pubblicare versioni contenenti un dropper destinato alla backdoor WAVESHAPER.V2, associata da Google all’attore nordcoreano MIDNIGHT NEPTUNE. Le release sono rimaste online per meno di tre ore, ma hanno comunque coinvolto clienti in almeno 15 settori e 13 Paesi. La portata dell’incidente era stata ricostruita anche nell’analisi sull’attacco supply chain ad Axios e sulle vulnerabilità inserite nel catalogo CISA.

I pacchetti malevoli aumentano del 1.444% in un anno

I dati raccolti dalla Open Source Security Foundation indicano che il numero di pacchetti open source identificati come malevoli è cresciuto del 1.444% tra il 2024 e il 2025. L’incremento non riflette soltanto una migliore capacità di rilevamento, ma l’industrializzazione delle campagne. Gli aggressori pubblicano intere famiglie di pacchetti, automatizzano la creazione di nomi credibili, utilizzano repository falsi e modificano rapidamente i payload quando una versione viene rimossa. I worm della supply chain possono inoltre rubare i token di pubblicazione e usare gli account compromessi per infettare altri moduli, trasformando ogni vittima in un nuovo punto di distribuzione.

Il fenomeno è stato evidente con Shai-Hulud, capace di propagarsi tra npm, GitHub e progetti collegati a Grafana, e con Miasma, che ha compromesso decine di pacchetti npm collegati all’ecosistema Red Hat. La velocità della propagazione rende insufficiente la strategia basata esclusivamente sulla rimozione successiva: quando l’avviso diventa pubblico, il codice può essere già entrato nei lockfile, nelle cache aziendali, nelle immagini container e nei sistemi di produzione.

L’intelligenza artificiale accelera attacco e contaminazione

Google prevede che l’intelligenza artificiale aumenterà ulteriormente il volume delle compromissioni. I modelli possono aiutare gli aggressori a generare pacchetti plausibili, documentazione credibile, varianti offuscate e campagne di social engineering più convincenti. Parallelamente, gli assistenti di programmazione possono suggerire dipendenze inesistenti o incorporare automaticamente moduli malevoli senza che lo sviluppatore ne analizzi provenienza e comportamento. Sono già stati osservati pacchetti dannosi inseriti nelle comunità dedicate ai modelli AI e componenti Model Context Protocol contenenti codice ostile. In un caso, un agente di coding avrebbe contribuito a integrare in un progetto legittimo di trading una dipendenza pubblicata da operatori nordcoreani. Il rischio non consiste quindi soltanto nell’uso offensivo dell’AI: riguarda anche la delega delle decisioni di sviluppo a sistemi che scelgono librerie, eseguono comandi e modificano repository. La minaccia è simile a quella descritta nel caso di AgentBaiting, dove repository GitHub costruiti appositamente ingannano gli agenti AI e consegnano malware.

SBOM e ABOM devono diventare inventari operativi

La prima raccomandazione di Google è costruire un inventario continuo di applicazioni, fornitori, servizi e dipendenze. La tradizionale Software Bill of Materials, o SBOM, deve elencare ogni componente software utilizzato, consentendo ai team di sicurezza di verificare rapidamente quali sistemi contengano una versione compromessa. Google propone inoltre una Action Bill of Materials, denominata ABOM, dedicata agli strumenti e alle azioni di terze parti utilizzate nelle pipeline. L’inventario deve comprendere workflow GitHub, plugin, builder, immagini container, servizi CI/CD e utility che partecipano alla generazione degli artefatti. Questo approccio permette di ricostruire non soltanto quali librerie siano presenti nel prodotto finale, ma anche quali componenti abbiano avuto accesso ai segreti e all’ambiente di build. Ogni rischio dovrebbe essere collegato a un proprietario, a una scadenza e a una fase precisa del ciclo di sviluppo, evitando di trattare vulnerabilità, token sovraprivilegiati e branch non protetti come problemi indipendenti. Gli attaccanti costruiscono infatti catene nelle quali più debolezze apparentemente minori producono una compromissione critica.

Le nuove release devono attraversare una quarantena

Una delle misure più concrete consiste nel ritardare automaticamente l’adozione dei pacchetti appena pubblicati. Per npm e pnpm, Google raccomanda un intervallo minimo di almeno 24 ore, durante il quale le nuove versioni rimangono in quarantena e non possono entrare immediatamente nelle build. Il tempo consente alla comunità, ai ricercatori e ai sistemi automatici di individuare una release compromessa prima che venga scaricata in massa. Per Python, le organizzazioni dovrebbero evitare che pip interroghi direttamente il repository pubblico PyPI, imponendo un indice aziendale privato sottoposto a verifica. Le nuove protezioni native vanno nella stessa direzione: GitHub ha introdotto un periodo predefinito di tre giorni per Dependabot, PyPI impedisce di aggiungere file a release vecchie più di 14 giorni e npm 12 disabilita per impostazione predefinita gli script del ciclo di installazione. Questi cambiamenti erano stati approfonditi nell’articolo sulle difese temporali introdotte da GitHub e PyPI contro gli attacchi supply chain. Nessuna misura è però sufficiente da sola: un pacchetto malevolo può attivarsi durante l’importazione e non attraverso un tradizionale script postinstall.

Token brevi e runner effimeri limitano la propagazione

Le pipeline non dovrebbero utilizzare Personal Access Token amministrativi, statici e senza scadenza. Google raccomanda identità dedicate alle macchine, GitHub Apps e token temporanei ottenuti attraverso OpenID Connect, capaci di scadere dopo pochi minuti. I token personali e le chiavi API dovrebbero avere una durata massima di pochi giorni, mentre l’accesso ai repository dovrebbe utilizzare autenticazione hardware FIDO2. Anche i runner CI/CD devono essere effimeri: ogni ambiente dovrebbe essere creato per un singolo job e distrutto immediatamente dopo, impedendo a un pacchetto compromesso di mantenere persistenza tra build differenti. I trigger ad alto privilegio come pull_request_target devono essere limitati e sottoposti a revisione, perché possono eseguire codice proveniente da contributori esterni con accesso ai segreti del repository. Pipeline, sandbox e ambienti di test devono inoltre rimanere separati dalla produzione, con segmentazione della rete e regole di uscita che consentano soltanto le destinazioni necessarie.

La risposta deve partire prima della conferma dell’incidente

Le aziende devono preparare playbook specifici per il takeover di un maintainer, la dependency confusion, l’avvelenamento delle pipeline e la compromissione delle workstation degli sviluppatori. Quando un pacchetto sospetto viene individuato, non basta rimuoverlo dal file delle dipendenze: occorre determinare se sia stato eseguito, quali credenziali fossero accessibili, quali artefatti siano stati generati e quali sistemi abbiano ricevuto quelle build. Token, chiavi di firma e segreti cloud potenzialmente esposti devono essere ruotati immediatamente. Log di repository, pipeline, endpoint e proxy devono essere correlati per individuare modifiche non autorizzate, trigger anomali, processi inattesi e connessioni verso infrastrutture esterne. Nella guida ufficiale di Google Cloud Threat Intelligence e Mandiant, la difesa viene descritta come un sistema multilivello composto da governance, identità, isolamento, verifica crittografica, monitoraggio comportamentale e risposta coordinata. La supply chain non può più essere considerata un rischio confinato ai fornitori: ogni dipendenza, workflow e strumento di sviluppo è ormai parte effettiva del perimetro aziendale.