Fra le cause principali dei data breach negli Stati Uniti figurano le compromissioni delle supply chain software. Secondo i dati elaborati da Barracuda, questi attacchi generano in media 4,91 milioni di dollari di danni per incidente, piazzandosi al secondo posto per costo fra tutte le tipologie di attacco, appena sotto agli insider threat malevoli. Più che di un trend emergente, si tratta di un cambo strutturale nel modo in cui gli attaccanti concepiscono le intrusioni.

Per molto tempo la difesa informatica ha ruotato attorno al perimetro: aggiornare i sistemi, formare gli utenti, blindare gli endpoint. Oggi la maggior parte delle organizzazioni dipende da decine, a volte centinaia, di fornitori di software, librerie open source, strumenti di sviluppo e aggiornamenti automatici. Ciascuna di queste dipendenze è un potenziale vettore. Gli attaccanti lo sanno, e lo sfruttano.

La logica è elementare: invece di compromettere un'azienda per volta, è sufficiente colpire un singolo vendor, un account sviluppatore o un sistema di build che sia centrale nella catena di fiducia, di modo da moltiplicare in modo esponenziale le vittime potenziali. Questo a prescindere dalla sofisticazione tecnica dell’attacco.

La supply chain come vettore sistemico

Il caso che ha ridefinito la percezione del rischio è ancora SolarWinds. A dicembre 2020, l'azienda produttrice della piattaforma di network management Orion scoprì che un aggiornamento distribuito tra marzo e giugno di quello stesso anno conteneva la backdoor Sunburst. Il malware era stato inserito nel codice sorgente durante il processo di build: chiunque avesse installato l'aggiornamento legittimo aveva scaricato anche il payload malevolo. Le stime iniziali parlavano di 18.000 organizzazioni coinvolte e decine di enti distribuiti su almeno otto paesi. L'attacco svelò una vulnerabilità pressoché globale della supply chain. I cyber criminali ebbero l'opportunità di scegliere le organizzazioni da spiare o compromettere ulteriormente.

Sunburst ha fatto emergere un problema strutturale: i processi di sviluppo software raramente incorporano la sicurezza come priorità; si privilegiano velocità e automazione. Ogni repository violato, ogni pipeline di CI/CD non protetta, ogni aggiornamento automatico non verificato è una porta aperta.

Negli anni ci sono stati diversi casi celebri, fra cui quello ai danni di 3CX, produttore della popolare piattaforma VoIP per aziende, che a marzo 2023 ha distribuito agli utenti un aggiornamento dell'applicazione desktop che conteneva malware. E nel 2024 fu emblematico il caso XZ Utils, un pacchetto di utility per la compressione dati che fa parte di tutte le principali distribuzioni Linux. Un account denominato Jia Tan aveva iniziato a contribuire al progetto quasi tre anni prima, costruendo gradualmente credibilità fino a ottenere i diritti di co-maintainer; nel frattempo account apparentemente indipendenti esercitavano pressione sul maintainer originale per accelerare le approvazioni. A marzo 2024 il developer Microsoft Andres Freund ha scoperto quasi per caso la backdoor (CVE-2024-3094, CVSS 10.0) introdotta nelle versioni 5.6.0 e 5.6.1: se non fosse stata intercettata prima della distribuzione massiva, avrebbe fornito accesso remoto non autenticato a centinaia di milioni di sistemi nel mondo.

Arriviamo al 2025, quando il gruppo UNC5221 con legami al Governo cinese ha violato l'ambiente di sviluppo di F5 Networks e sottratto codice sorgente relativo alla piattaforma BIG-IP, ampiamente utilizzata in ambito enterprise per la gestione del traffico e la sicurezza applicativa. A differenza di attacchi ransomware orientati al profitto immediato, questa operazione aveva un valore strategico di lungo periodo.

Che cosa abbiamo imparato

Sottrarre codice sorgente non genera un incidente immediato visibile: non ci sono file cifrati, non ci sono richieste di riscatto, non ci sono notifiche di data breach obbligatorie in tempo reale. Gli attaccanti acquisiscono una comprensione profonda del funzionamento interno di un prodotto critico: le sue logiche, le sue configurazioni, le sue potenziali debolezze non ancora documentate. Quella conoscenza può essere convertita in exploit mirati, zero-day o campagne di spionaggio protratte nel tempo, rivolte a tutte le organizzazioni che utilizzano lo stesso software.

Come evidenziato da Barracuda nella sua analisi, il furto di codice sorgente crea uno squilibrio duraturo: gli attaccanti acquisiscono conoscenza che i difensori non sanno di aver perso. La difficoltà degli attacchi alla supply chain risiede proprio nella loro logica: sfruttano sistemi e relazioni che si trovano al di fuori del controllo diretto dell'organizzazione. Non si difendono con il perimetro, perché arrivano attraverso il perimetro. Non si bloccano con il filtro antispam, perché viaggiano in aggiornamenti firmati. Non si intercettano facilmente con le regole di detection tradizionali, perché il codice malevolo si comporta come codice legittimo fino al momento dell'esecuzione.

Le linee di difesa identificate da Barracuda partono dall'origine del problema: l'accesso. Autenticazione multifattore, principio del minimo privilegio e revisione periodica delle credenziali attive su sistemi di build, repository e pipeline CI/CD riducono la superficie esposta prima ancora che un attaccante possa inserirsi nel flusso di distribuzione. Altrettanto critica è la visibilità sulle dipendenze di terze parti, in particolare quelle open source: un Software Bill Of Materials aggiornato, l'analisi della composizione del software e il monitoraggio sistematico delle versioni permettono di sapere esattamente da cosa dipende il proprio ambiente e di reagire quando una di quelle dipendenze viene compromessa.

La seconda metà della difesa riguarda ciò che succede quando la prevenzione non basta. Rilevare comportamenti anomali anche in strumenti e aggiornamenti considerati fidati richiede una capacità di detection che non si ferma al perimetro. E quando l'incidente avviene, la cyber resilience, intesa come capacità di contenimento rapido assumendo che anche il software di fiducia possa essere compromesso, diventa il fattore che determina la differenza tra un episodio gestibile e un disastro operativo.