Nel dicembre 2020 si scoprì che circa 18.000 organizzazioni in tutto il mondo avevano installato, senza saperlo, un aggiornamento compromesso: non perché qualcuno avesse violato i loro sistemi direttamente, ma perché quell’aggiornamento, di un software di monitoraggio di rete perfettamente legittimo, firmato digitalmente dal vendor e distribuito attraverso i canali ufficiali, conteneva codice malevolo inserito dagli attaccanti mesi prima. Per tutte la backdoor era ormai dentro; solo un centinaio, però, vennero poi selezionate dagli attaccanti per un’intrusione attiva con movimento laterale.
SolarWinds. Da allora il caso viene citato in ogni conversazione sulla sicurezza della supply chain software, e con ragione. Non perché sia stato il primo, ma perché ha reso impossibile ignorare una logica d’attacco che funziona: invece di colpire cento organizzazioni ben difese una per una, si compromette il fornitore di cui tutte e cento si fidano. Un punto di ingresso, impatto illimitato.
Cos’è un supply chain attack e perché è così difficile da rilevare
La fiducia è il problema. Un aggiornamento firmato digitalmente viene installato senza essere analizzato. Una libreria open source viene aggiornata senza che nessuno legga le modifiche al codice. Un componente SaaS accede ai sistemi aziendali con permessi ampi perché tecnicamente ne ha bisogno.
Non è una critica: non è possibile verificare manualmente ogni componente software che entra nell’infrastruttura di un’organizzazione. Ma questa fiducia implicita, senza controlli sistematici, è esattamente quello che gli attaccanti sfruttano.
Il caso XZ Utils del 2024 lo ha reso evidente in modo quasi fastidioso. Un attaccante ha trascorso due anni a costruire reputazione come contributore di un progetto open source, guadagnandosi la fiducia dei maintainer, prima di inserire una backdoor. È stato scoperto per caso, da un ingegnere che aveva notato anomalie nei tempi di esecuzione di alcune operazioni SSH. Un dettaglio. Se non lo avesse notato, la backdoor (CVE-2024-3094, presente nelle versioni 5.6.0 e 5.6.1 di xz) — già pacchettizzata nei rami di sviluppo di Fedora, Debian, Kali e Arch — sarebbe potuta arrivare nelle release stabili usate in produzione su milioni di server, agendo direttamente sul demone SSH (sshd).
I vettori più usati
La compromissione del processo di build è il meccanismo di SolarWinds: l’attaccante entra nell’ambiente di sviluppo del vendor e inserisce codice malevolo nella fase di compilazione. Il software che arriva ai clienti è firmato e distribuito normalmente. Il codice malevolo non esiste nel repository sorgente: compare solo nella versione compilata.
La dependency confusion sfrutta la risoluzione delle dipendenze nei sistemi di build. Se un’organizzazione usa librerie interne con lo stesso nome di pacchetti pubblici, pubblicare un pacchetto pubblico con quel nome e una versione superiore può bastare per far scaricare al sistema di build quello malevolo invece di quello interno.
Il typosquatting registra nomi di pacchetti quasi identici a quelli legittimi, puntando sugli errori di digitazione. In ecosistemi con decine di migliaia di pacchetti disponibili, è un vettore più efficace di quanto sembri.
Le integrazioni SaaS sono il vettore più pervasivo e meno visibile. Ogni tool connesso all’infrastruttura aziendale, da un sistema di analytics a una piattaforma di ticketing, è un potenziale punto di ingresso. Una compromissione del provider si trasferisce automaticamente a tutti i clienti, spesso senza che nessuno se ne accorga in tempo reale.
Cosa richiede NIS 2 sulla sicurezza della supply chain
Il D.Lgs. 138/2024 introduce obblighi espliciti: le organizzazioni in perimetro devono valutare il rischio dei propri fornitori critici e adottare misure proporzionate. Non basta avere i propri sistemi sotto controllo.
Nella pratica questo significa inventario dei fornitori software critici, valutazione del loro livello di maturità di sicurezza, contratti con requisiti minimi verificabili e obblighi di notifica degli incidenti, monitoraggio nel tempo. Per la maggior parte delle organizzazioni italiane questo lavoro non è ancora iniziato. Il punto di partenza manca quasi sempre: non esiste un inventario reale dei fornitori che hanno accesso effettivo ai sistemi.
Come costruire un programma di supply chain security
Prima di qualsiasi strumento, serve sapere cosa si ha. Quanti fornitori software critici ci sono? Quali hanno accesso a dati sensibili? Quali sono integrati nei sistemi core? Senza rispondere a queste domande qualsiasi programma di sicurezza parte cieco.
L’SBOM, Software Bill of Materials, è lo strumento che permette di sapere in tempo reale quali componenti software sono presenti nei propri sistemi, incluse le dipendenze di terze parti. Quando viene pubblicata una CVE rilevante, l’SBOM permette di capire in minuti se si è esposti, invece di impiegare giorni a fare inventory manuale. È diventato uno standard de facto nella supply chain security, ancora poco adottato in Italia.
La valutazione dei fornitori critici non può essere un questionario annuale spedito per obbligo contrattuale. Deve essere un processo che include verifica delle certificazioni, analisi delle pratiche di sviluppo sicuro, revisione delle policy di gestione degli incidenti. Per i fornitori più critici, un assessment tecnico che vada oltre la documentazione.
Gli strumenti di software composition analysis automatizzano il monitoraggio delle dipendenze, confrontando i componenti in uso con i database di vulnerabilità noti. Sono una misura essenziale in qualsiasi contesto in cui si sviluppa o si integra software di terze parti, e il loro costo di implementazione è quasi sempre inferiore al costo di scoprire tardi una vulnerabilità critica.
Come può aiutarti Key Partner
Il team Cyber di Key Partner affianca le organizzazioni nella costruzione di programmi di supply chain security: dall’inventario dei fornitori alla definizione dei requisiti minimi di sicurezza, dalla gestione degli SBOM all’integrazione dei controlli nei processi di procurement.
Il punto di partenza, quasi sempre, è la stessa domanda: sapete esattamente quali fornitori hanno accesso ai vostri sistemi critici, e con quali permessi? Se la risposta è incerta, è da lì che si comincia.
