Gli ecosistemi digitali sotto attacco: Supply Chain Security, NIS2 e l’importanza degli SBOM
Al Forum ICT Security 2025, Vincenzo Sammartino analizza i rischi emergenti degli attacchi alla catena di fornitura e le strategie di difesa attraverso Digital Twin e Software Bill of Materials
Dal biologico al digitale: comprendere gli ecosistemi informatici
Quando si parla di cybersecurity, pensare in termini di singoli sistemi isolati non è più sufficiente. Questa consapevolezza emerge con chiarezza dall’intervento dal titolo “NIS2, Supply Chain Security e SBOM”, tenuto da Vincenzo Sammartino durante la 23ª edizione del Forum ICT Security, svoltosi a Roma il 19 e 20 novembre 2025. Sammartino, dottorando del National PhD in Artificial Intelligence presso l’Università di Pisa, ha sostituito il professor Fabrizio Baiardi, impossibilitato a partecipare per motivi di salute.
L’esperto ha aperto la sua presentazione con un’analogia tanto efficace quanto illuminante: quella tra ecosistema biologico ed ecosistema digitale. Ha spiegato che così come nell’ecosistema biologico l’energia fluisce dal basso verso l’alto della piramide alimentare, trasportando con sé non solo nutrimento ma anche tossine, funghi e batteri, allo stesso modo nell’ecosistema digitale le vulnerabilità si propagano attraverso la catena di fornitura. Ciò che per gli organismi viventi rappresentano le tossine, nel mondo digitale sono le vulnerabilità informatiche che si diffondono da un componente all’altro, da un fornitore all’utilizzatore finale.
Questa prospettiva sistemica rappresenta un cambio di paradigma fondamentale per comprendere la natura degli attacchi supply chain, dove una singola vulnerabilità inserita a un determinato livello della catena può propagarsi come un’onda a tutti i sistemi che dipendono da quel componente. La sicurezza, quindi, non è più una proprietà dei singoli sistemi, ma dell’intero ecosistema informativo a cui tali sistemi appartengono.
L’industria del ransomware: un ecosistema criminale strutturato e maturo
Uno degli aspetti più inquietanti emersi dall’intervento riguarda l’evoluzione del ransomware, che è diventato ormai una vera e propria industria strutturata con attori specializzati e ben organizzati. Come ha sottolineato Sammartino, non si parla più di singoli criminali informatici, ma di vere e proprie organizzazioni che operano secondo il modello del ransomware as a service, dove diversi attori collaborano ciascuno con competenze specifiche.
Al centro di questo ecosistema criminale si trova una figura chiave: l’Initial Access Broker, ovvero chi vende l’accesso iniziale a una rete o sistema compromesso. Questo punto di accesso iniziale nella catena di fornitura viene poi sfruttato da altri attori per perpetrare l’attacco vero e proprio. L’ecosistema include sviluppatori di malware, fornitori di infrastrutture di hosting protette (bulletproof hosting), affiliati che distribuiscono il ransomware, servizi di negoziazione con le vittime e persino servizi di riciclaggio del denaro (money laundering).
La complessità dell’ecosistema della cybersecurity è stata illustrata attraverso una slide deliberatamente caotica che mostra centinaia di fornitori, servizi e prodotti interconnessi. Lo speaker ha fatto notare come dietro ogni singolo logo rappresentato ci siano in realtà tantissimi attori, e di conseguenza la superficie di attacco aumenta in maniera esponenziale. Un esempio recente citato è stato quello di Cloudflare, che nei giorni precedenti al convegno era stato al centro delle cronache per quello che inizialmente sembrava un attacco informatico ma che si è poi rivelato essere un errore di programmazione. Tuttavia, questo errore ha comunque avuto ripercussioni su numerosi altri servizi che dipendevano da Cloudflare, dimostrando quanto sia estesa e fragile la rete di interdipendenze nell’ecosistema digitale.
Anatomia di un attacco supply chain: come funziona la compromissione
Sammartino ha illustrato con precisione il meccanismo attraverso cui si sviluppa un attacco alla catena di fornitura. Il processo inizia con la scelta strategica di un fornitore: gli attaccanti non colpiscono direttamente l’obiettivo finale, ma identificano prima quali fornitori utilizza il target prescelto. Una volta individuato il fornitore più vulnerabile o strategico, gli attaccanti lo compromettono inserendo del codice malevolo all’interno del suo prodotto o servizio.
Un aspetto particolarmente insidioso di questi attacchi riguarda la scelta dei target preferiti: paradossalmente, i sistemi di sicurezza stessi rappresentano gli obiettivi ideali. Il relatore ha spiegato che questo avviene perché inserire un malware all’interno di un prodotto di sicurezza, come potrebbe essere un sistema IDS (Intrusion Detection System) o un antivirus, crea quella che viene definita una situazione Living off the Land. In pratica, il codice malevolo nascosto all’interno di uno strumento di sicurezza diventa praticamente invisibile, poiché è molto più difficile che venga rilevato proprio dal sistema che dovrebbe proteggerci.
Un punto cruciale evidenziato nell’intervento riguarda l’intero ciclo di vita del prodotto. Sammartino ha sottolineato con forza che la supply chain non coinvolge soltanto la fase di distribuzione, ma abbraccia l’intero processo di vita del prodotto e del servizio: progettazione, sviluppo, manutenzione e persino dismissione. Le vulnerabilità possono essere introdotte in qualsiasi momento e in qualsiasi fase di questo percorso.
Gli attori che possono rappresentare una minaccia sono molteplici: non solo fornitori diretti, ma anche fornitori dei fornitori (le cosiddette terze parti), utenti finali e soprattutto insider, ovvero dipendenti dell’azienda che volontariamente o involontariamente inseriscono codice malevolo all’interno del servizio. La vulnerabilità può annidarsi in qualsiasi fase: durante la progettazione, nello sviluppo, nella distribuzione, nell’installazione, nella manutenzione o persino nella fase di dismissione del prodotto.
Le vulnerabilità nascoste nel codice: dalla sorgente al runtime
Dal punto di vista dello sviluppo software, il relatore ha illustrato tutte le possibili fonti di vulnerabilità che possono annidarsi nelle diverse fasi di creazione di un’applicazione. Utilizzando come riferimento il framework SLSA (Supply chain Levels for Software Artifacts) proposto da Google, ha mostrato come le minacce possano manifestarsi in ogni passaggio del processo.
Nel primo blocco, a livello di codice sorgente, troviamo vulnerabilità come il poisoning del repository, ovvero l’avvelenamento del deposito di codice sorgente attraverso modifiche non autorizzate. Tuttavia, il punto più critico e attuale riguarda le dipendenze: l’uso sempre più massiccio di librerie open source all’interno dei prodotti commerciali comporta che queste librerie possano contenere vulnerabilità sfruttabili da attaccanti per scopi malevoli, come l’esfiltrazione di dati sensibili.
Ma le fonti di vulnerabilità non si fermano qui. Possono annidarsi anche nella fase di build, attraverso il caricamento di pacchetti già compromessi, e persino nelle fasi di sviluppo e runtime. Google ha proposto un’estensione del concetto di sicurezza che copre tutte queste fasi, rendendo evidente che ogni singolo passaggio dello sviluppo e dell’esecuzione di un prodotto software rappresenta una potenziale porta di ingresso per gli attaccanti.
I numeri di una minaccia crescente: dati e casi concreti
I dati presentati durante l’intervento confermano che non si tratta di minacce teoriche, ma di un fenomeno in drammatica crescita. Le statistiche di Cyble citate da Sammartino mostrano picchi sempre più elevati negli attacchi supply chain, con un incremento particolarmente significativo registrato nel 2025. Il grafico presentato evidenzia una curva in costante ascesa, con oscillazioni che però tendono sempre verso l’alto, segno che gli attaccanti hanno compreso l’efficacia di questa strategia e la stanno sfruttando sempre di più.
Tra i casi più eclatanti e recenti citati durante la presentazione, spicca l’attacco alla piattaforma Discord Bot del marzo 2024, che ha colpito una community di oltre 170.000 membri. Gli attaccanti hanno infettato gli sviluppatori con malware in grado di rubare informazioni sensibili, utilizzando diverse tecniche tra cui il dirottamento di account GitHub, la distribuzione di pacchetti Python malevoli e l’uso di una falsa infrastruttura Python appositamente creata per ingannare gli sviluppatori.
L’attacco Okta dell’ottobre 2023 ha invece dimostrato come anche i fornitori di servizi di autenticazione e gestione delle identità possano essere compromessi. Gli attaccanti sono riusciti ad accedere a dati privati dei consumatori ottenendo le credenziali del sistema di gestione del supporto clienti, mettendo potenzialmente a rischio migliaia di organizzazioni che si affidavano ai servizi di Okta.
Nel settembre-ottobre 2023, i server JetBrains TeamCity sono stati presi di mira sfruttando una vulnerabilità critica di bypass dell’autenticazione. Questo attacco ha destato particolare attenzione per il suo potenziale impatto, dato l’utilizzo diffuso di TeamCity negli ambienti di sviluppo software. Gli stessi attori dietro il noto attacco SolarWinds sono stati identificati come responsabili di questa campagna.
L’attacco a Microsoft del febbraio 2023 ha sfruttato una vulnerabilità in JFrog Artifactory, un gestore di repository binari che Microsoft utilizza per distribuire e conservare i componenti software. Gli attaccanti sono riusciti a iniettare codice malevolo in alcuni componenti software di Microsoft, ottenendo accesso alla rete e riuscendo a esfiltrare codice sorgente e altre informazioni confidenziali di estremo valore.
Anche Norton, il noto fornitore di software antivirus, non è stato immune: nel maggio 2023 è stato vittima di un attacco che ha sfruttato una vulnerabilità zero-day in un software MFT (Managed File Transfer) utilizzato dalla società madre per trasferire file tra consumatori e uffici. Gli attaccanti hanno avuto accesso alla rete di Norton e sono riusciti a sottrarre informazioni personali dei dipendenti.
L’attacco ad Airbus del gennaio 2023 ha dimostrato come anche le grandi multinazionali dell’aerospazio possano essere colpite attraverso la compromissione di un account di un dipendente di uno dei loro clienti, in questo caso Turkish Airlines. Questo caso evidenzia come la catena di fiducia possa essere sfruttata in entrambe le direzioni: non solo dai fornitori verso i clienti, ma anche dai clienti verso i fornitori.
Ma il caso che forse più di tutti ha segnato la storia recente della supply chain security rimane SolarWinds, avvenuto alla fine del 2020. In questo attacco sofisticatissimo, la società SolarWinds ha distribuito ai propri clienti un aggiornamento software legittimamente firmato che però conteneva al suo interno del malware accuratamente nascosto. I clienti avevano completa fiducia nel software perché era stato firmato, costruito e distribuito direttamente da SolarWinds attraverso i canali ufficiali. Nessuno poteva immaginare che fosse compromesso. L’attacco è riuscito a infiltrarsi in oltre 18.000 organizzazioni commerciali e governative, incluse agenzie federali statunitensi di primissimo livello, rappresentando uno dei più gravi incidenti di sicurezza informatica della storia recente.
NIS2 e le nuove normative europee: cosa cambia per le organizzazioni
L’intervento ha poi analizzato come la direttiva europea NIS2 affronti specificamente il tema della sicurezza della catena di fornitura. Sammartino ha spiegato che proprio l’esigenza di difendersi dagli attacchi supply chain rappresenta una delle ragioni principali dell’evoluzione dalla precedente direttiva NIS alla nuova NIS2, molto più stringente e articolata.
La NIS2, nello specifico all’interno dell’articolo 21, definisce dieci misure di sicurezza di base che le organizzazioni dovrebbero implementare. Tra queste, due punti affrontano direttamente la questione della catena di fornitura:
- Il punto 4 richiede di garantire la sicurezza della catena di fornitura, comprese le misure che affrontano il rapporto tra le aziende e i loro fornitori diretti o prestatori di servizi
- Il punto 5 impone di garantire la sicurezza nell’acquisizione, sviluppo e manutenzione di reti e sistemi informativi, inclusa la gestione e la divulgazione delle vulnerabilità
L’articolo 21 prevede anche altre misure fondamentali: politiche di analisi dei rischi e di sicurezza dei sistemi informativi, piani di risposta agli incidenti per la gestione delle minacce attive, piani di continuità aziendale (inclusi backup e ripristino di emergenza), politiche per valutare l’efficacia delle misure implementate, formazione sulla consapevolezza e sulle migliori pratiche di sicurezza informatica, politiche sull’uso della crittografia, procedure di controllo degli accessi (in particolare per i dipendenti con accesso a dati sensibili) e sistemi di autenticazione multifattoriale e monitoraggio continuo.
Lo speaker ha però evidenziato come la normativa europea, per quanto più stringente rispetto al passato, risulti ancora meno rigorosa rispetto agli standard richiesti negli Stati Uniti. L’Executive Order 14028 del Presidente degli Stati Uniti, emanato nel maggio 2021 e intitolato “Improving the Nation’s Cybersecurity”, stabilisce infatti requisiti ancora più precisi e vincolanti.
Questo ordine esecutivo richiede che:
- Tutto il software venduto al governo federale degli Stati Uniti deve includere un SBOM (Software Bill of Materials), ovvero un registro formale e dettagliato di tutti i suoi componenti e delle loro relazioni
- I fornitori devono implementare pratiche di sviluppo sicuro, inclusi ambienti di build sicuri, autenticazione multifattoriale obbligatoria e cifratura dei dati
- Il software deve essere sottoposto regolarmente a vulnerability scanning e devono essere fornite evidenze documentali di questi test
- Deve essere garantita e dimostrata l’integrità del codice open source utilizzato, assicurando che sia stato correttamente validato e testato
La differenza principale, ha sottolineato il relatore, sta nel livello di dettaglio e nella natura cogente delle misure richieste: mentre la NIS2 fornisce linee guida generali, l’Executive Order americano impone requisiti tecnici specifici e verificabili.
SBOM: la lista degli ingredienti del software moderno
Una delle soluzioni più innovative e concrete per affrontare i rischi legati alla supply chain è rappresentata dal concetto di Software Bill of Materials, comunemente abbreviato in SBOM. Sammartino ha utilizzato ancora una volta un’analogia con il mondo reale per spiegare questo concetto: “È come una lista di ingredienti di materie prime che si trovano all’interno di un alimento.”
Così come è relativamente semplice identificare la presenza di allergeni in un prodotto alimentare grazie all’elenco degli ingredienti riportato sull’etichetta, allo stesso modo diventa molto più facile individuare una libreria compromessa se è stata creata e mantenuta una Software Bill of Materials completa e accurata.
Ma cosa deve contenere esattamente un SBOM? Secondo le linee guida internazionali, un SBOM rappresenta un registro formale dei dettagli e delle relazioni della catena di fornitura di qualsiasi componente utilizzato per costruire un software. All’interno di questa lista devono essere inserite tutte le dipendenze utilizzate: librerie open source, porzioni di codice prese da terze parti e l’elenco completo dei fornitori che compongono la catena di approvvigionamento.
Un SBOM efficace deve possedere alcune caratteristiche fondamentali. Innanzitutto, deve essere elaborabile automaticamente (machine-processable) in un formato ampiamente utilizzato, per consentire l’automazione dei processi di verifica. Deve contenere informazioni sufficienti sia sui componenti open source che su quelli proprietari presenti nel software, in modo da poterli correlare con altre fonti di dati, come i database delle vulnerabilità note e i bollettini di sicurezza. L’automazione rappresenta infatti un obiettivo chiave sia per la generazione che per l’utilizzo degli SBOM.
Analizzando i dati contenuti in un SBOM, un utilizzatore dovrebbe essere in grado di determinare con certezza se un determinato componente è presente in un software specifico. I dati dell’SBOM possono inoltre fornire informazioni preziose sulla provenienza dei componenti, consentendo una migliore tracciabilità e gestione del rischio. Condividere gli SBOM lungo tutta la catena di fornitura permette alle organizzazioni di formare un quadro più completo del software utilizzato e di rispondere tempestivamente alle informazioni che potrebbero indicare nuovi rischi emersi.
Il caso Log4Shell: quando sapere è più importante che rimediare
Per illustrare l’importanza pratica degli SBOM, il relatore ha analizzato in dettaglio il caso Log4Shell, la celebre vulnerabilità scoperta nel dicembre 2021 nella libreria Apache Log4j. Questa libreria di logging (registrazione degli eventi) è ampiamente utilizzata come modulo standard per l’output dei log nei sistemi Java in tutto il mondo, ed è stata classificata con un livello di criticità molto alto per la facilità con cui poteva essere sfruttata.
Il problema principale non riguardava la complessità della correzione: la vulnerabilità in sé era relativamente facile da rimediare una volta identificata. La vera sfida consisteva nel sapere quali sistemi fossero effettivamente vulnerabili. Come ha spiegato Sammartino con una frase efficace: “Il problema non era rimediare la vulnerabilità, il problema era sapere se in un sistema c’era la vulnerabilità da rimediare.”
La difficoltà derivava dal fatto che Log4j veniva solitamente utilizzata come dipendenza transitiva, ovvero come dipendenza di altre dipendenze, rendendo molto difficile identificarla senza strumenti adeguati. Le organizzazioni prive di capacità SBOM si sono trovate costrette a impegnarsi in ricerche manuali lunghe e dispendiose, rischiando di rimanere vulnerabili per settimane o mesi. Al contrario, le organizzazioni che disponevano già di SBOM aggiornati e completi sono state in grado di identificare immediatamente tutti i sistemi che utilizzavano la libreria compromessa e di rispondere in modo relativamente rapido ed efficiente.
Questo caso ha rappresentato un punto di svolta nella consapevolezza dell’importanza degli SBOM, dimostrando in modo inequivocabile che la trasparenza sui componenti software non è un lusso ma una necessità per la sicurezza moderna.
Strategie di difesa: oltre le pratiche tradizionali
L’intervento si è concluso con una panoramica delle strategie difensive più efficaci per contrastare gli attacchi alla catena di fornitura, che vanno ben oltre le pratiche di sicurezza tradizionali e richiedono un approccio innovativo e multilivello.
La prima linea di difesa consiste nella valutazione accurata della scelta del fornitore. Non è sufficiente verificare che un fornitore dichiari di avere determinate certificazioni: è necessario valutare se queste certificazioni sono supportate da evidenze sperimentali concrete e verificabili. Bisogna inoltre esaminare attentamente le politiche di sicurezza adottate dal fornitore e richiedere prove tangibili della loro effettiva implementazione.
Un secondo pilastro fondamentale è lo sviluppo secondo i principi del Secure by Design, ovvero progettare e sviluppare prodotti la cui sicurezza sia garantita fin dalle prime fasi di creazione. Come ha spiegato il relatore, questo significa intervenire durante la fase di sviluppo e, conseguentemente, durante la fase di debug, per andare a sviluppare un sistema che sia privo di vulnerabilità a partire dalla sua concezione iniziale, non cercando di “rattoppare” la sicurezza a posteriori.
Il terzo principio riguarda l’applicazione rigorosa del principio del privilegio minimo, specialmente quando si ha a che fare con fornitori di terze parti. Questo significa ridurre al minimo assoluto i privilegi di accesso di chi opera sul sistema, limitando così i potenziali impatti di una eventuale esfiltrazione di dati o compromissione del fornitore stesso.
Ma il punto più innovativo e promettente illustrato nell’intervento riguarda il What-if Engineering basato su Digital Twin, l’area di ricerca su cui stanno attualmente lavorando Sammartino e il suo supervisor, il professor Baiardi. Questo approccio consiste nel creare un gemello digitale (digital twin) completo dell’infrastruttura informatica, in modo da poter eseguire su di esso simulazioni utilizzando il metodo Monte Carlo.
La potenzialità di questa tecnologia è straordinaria: permette di fare quello che viene chiamato what-if analysis, ovvero verificare preventivamente cosa succederebbe se un determinato componente venisse aggiunto al sistema. Per esempio, prima di integrare una nuova libreria per il logging nel proprio software, si può chiedersi: quante vulnerabilità note ha questa libreria? Quali rischi comporta al sistema nel suo complesso l’inserimento di questa libreria? Quali sono i percorsi di attacco che un ipotetico attaccante potrebbe sfruttare? Qual è il rischio potenziale complessivo che l’aggiunta di questo componente introduce nel sistema?
Attraverso simulazioni condotte sul gemello digitale, è possibile ottenere risposte concrete a queste domande prima ancora di implementare le modifiche nell’ambiente di produzione reale, identificando preventivamente le vulnerabilità e progettando le appropriate contromisure. Questo approccio proattivo rappresenta un salto qualitativo enorme rispetto alla tradizionale sicurezza reattiva, che interviene solo dopo che un problema si è manifestato.
Per chi fosse interessato ad approfondire questa metodologia, Sammartino ha rimandato ai paper scientifici pubblicati dal gruppo di ricerca e alle precedenti presentazioni del professor Baiardi sull’argomento, disponibili negli atti delle scorse edizioni del Forum ICT Security.
Conclusioni: ripensare la sicurezza come proprietà ecosistemica
L’intervento di Vincenzo Sammartino ha evidenziato con chiarezza come la sicurezza informatica non possa più essere concepita come una proprietà di singoli sistemi isolati, ma debba necessariamente essere considerata a livello di ecosistema nella sua interezza. Gli attacchi supply chain sfruttano proprio le molteplici interconnessioni tra fornitori, componenti software, servizi e sistemi, rendendo indispensabile un approccio olistico e sistemico.
Le vulnerabilità, come le tossine negli ecosistemi biologici, si propagano lungo le catene di dipendenza, e un singolo punto debole può compromettere centinaia o migliaia di organizzazioni a valle. La complessità crescente dell’ecosistema digitale, con i suoi innumerevoli attori e interdipendenze, amplifica esponenzialmente la superficie di attacco e rende ogni componente un potenziale vettore di compromissione.
Per affrontare efficacemente questa sfida, è necessario un approccio multilivello che includa:
- Trasparenza radicale attraverso l’adozione sistematica degli SBOM, che permettono di sapere esattamente cosa c’è dentro il software che utilizziamo
- Conformità normativa rigorosa con la direttiva NIS2 e gli standard internazionali più avanzati, come quelli stabiliti dall’Executive Order americano
- Validazione continua dei fornitori, delle loro pratiche di sicurezza e delle evidenze concrete che le supportano
- Simulazione proattiva dei rischi attraverso tecnologie innovative come i Digital Twin, che permettono di prevedere e prevenire le vulnerabilità prima che possano essere sfruttate
Come ha efficacemente sintetizzato il relatore nella sua conclusione, la vera sfida non sta tanto nel rimediare alle vulnerabilità una volta scoperte – operazione spesso relativamente semplice dal punto di vista tecnico – quanto piuttosto nel saperle identificare tempestivamente all’interno di ecosistemi sempre più complessi, interconnessi e in continua evoluzione.
Il passaggio da una visione atomistica della sicurezza (incentrata sul singolo sistema) a una visione ecosistemica (che abbraccia l’intera catena di fornitori, dipendenze e relazioni) rappresenta non solo un’evoluzione tecnologica, ma un vero e proprio cambio di paradigma culturale. Solo attraverso questo nuovo approccio sarà possibile costruire sistemi realmente resilienti, capaci di resistere alle sofisticate minacce che caratterizzano il panorama della cybersecurity moderna.
Guarda il video completo dell’intervento “NIS2, Supply Chain Security e SBOM”, tenuto da Vincenzo Sammartino durante il Forum ICT Security 2025:
Sono un professionista con un solido background in Intelligenza Artificiale e CyberSecurity, attualmente impegnato nel dottorato nazionale in AI presso l'Università di Pisa. La mia specializzazione si concentra sull'implementazione di soluzioni innovative per la sicurezza informatica e la gestione dei dati.
Grazie al mio percorso accademico e alla mia esperienza pratica, ho sviluppato competenze approfondite nei sistemi distribuiti e nei Digital Twin, con particolare interesse per la loro applicazione nell'intelligenza artificiale e nella cybersecurity. Attualmente, le mie ricerche si focalizzano su sistemi di decomposizione di database e sull'integrazione dei Digital Twin per anticipare e mitigare minacce informatiche, sempre con un occhio di riguardo alla conformità ai regolamenti GDPR.
Con diverse pubblicazioni accademiche e presentazioni a conferenze internazionali, sono attivamente coinvolto nella condivisione di conoscenze innovative nel mio campo. La mia passione per l'AI mi spinge a esplorare costantemente nuove frontiere tecnologiche, contribuendo a progetti all'avanguardia per migliorare la sicurezza e la resilienza dei sistemi IT.
