Nell’ormai lontano dicembre 2020 il mondo scoprì che Solarwinds, il software di monitoraggio IT usato da migliaia di aziende, era stato compromesso alla fonte: gli attaccanti avevano infatti inserito una backdoor direttamente negli aggiornamenti software, distribuita poi a circa 18 mila clienti.
Un anno dopo fu la volta di Log4Shell. Una vulnerabilità critica in Log4j, una libreria di logging usata praticamente ovunque (da Apple ai software di grandi gruppi bancari), permetteva di eseguire codice da remoto su milioni di server con una stringa di testo. E nello stesso periodo l'attacco a Kaseya, fornitore di software di gestione IT usato dagli MSP, sfruttò il suo stesso meccanismo di aggiornamento per distribuire ransomware a cascata, colpendo fino a 1.500 aziende clienti finali in un colpo solo.
Con gli esempi si potrebbe andare avanti a lungo. Il minimo comun denominatore di tutti questi episodi è che nessuno ha colpito l'obiettivo finale in modo diretto, ma hanno tutti sfruttato la fiducia che le aziende ripongono nei loro fornitori di software, nelle librerie e negli strumenti di terze parti che lo compongono.
Da qui nasce il concetto di software supply chain e, soprattutto, l’esigenza che questa specifica catena di fornitura sia in qualche modo protetta. Vediamo come.
Key Points
- La sicurezza del software non dipende solo dal codice scritto internamente, ma anche da tutto l’ecosistema open source e di terze parti che vi gravita attorno.
- Attacchi recenti e su larga scala hanno infatti colpito componenti fidati del software, non il cuore dell'applicativo. SolarWinds, Log4Shell e Kaseya sono soltanto alcuni esempi.
- La sicurezza della supply chain software è un requisito normativo ed esistono solidi framework su cui costruire la resilienza del proprio software.
Il software moderno è la somma di tanti componenti
Gli applicativi moderni, inclusi quelli sviluppati direttamente dalle organizzazioni, non sono quasi mai scritti da zero ma nascono dall'integrazione di componenti proprietari e di terze parti, orchestrati attraverso pipeline automatizzate che compilano, testano e rilasciano l'applicazione anche più volte al giorno. Questo approccio risponde a una vera e propria necessità strutturale e di mercato, perché la velocità con cui evolvono librerie, framework e requisiti applicativi rende insostenibile lo sviluppo interamente proprietario.
Rispetto alle supply chain fisiche tradizionali, quella del software è molto più dinamica: nuove dipendenze vengono introdotte quotidianamente nel codice, le pipeline vengono aggiornate in automatico, le release si susseguono a ritmo continuo.
Gli elementi che la compongono sono numerosi e naturalmente interconnessi.
- Codice proprietario, sviluppato internamente dai team;
- Librerie e pacchetti open source, che coprono una parte sostanziale della codebase di un'app moderna;
- Container e le relative dipendenze;
- Plugin e binari di terze parti per estendere funzionalità senza svilupparle da zero;
- Strumenti di build: compilatori, assemblatori e analizzatori statici del codice;
- Pipeline di CI/CD, che automatizzano build, test e deployment;
- Repository che archiviano e distribuiscono codice sorgente e pacchetti;
- Infrastruttura cloud e API, su cui l'applicazione viene eseguita e attraverso cui comunica.
A rendere il quadro ancora più articolato, il software non è solo codice, librerie, infrastruttura e strumenti, ma anche persone e processi: team DevOps, sviluppatori, ma anche fornitori esterni che realizzano parti di codice o intere funzionalità di applicativi proprietari complessi. Tutto questo, nel suo insieme, costituisce l'intricata supply chain del software.
I rischi della software supply chain, dalle dipendenze alle pipeline CI/CD
La complessità del software moderno non è un problema in sé, ma lo diventa se si introducono vulnerabilità al di fuori del codice core dell'applicazione.
Più le organizzazioni accelerano lo sviluppo, più si affidano ad automazione, librerie e fornitori esterni, col risultato di aumentare esponenzialmente i rischi cui sono soggetti. Quelli che seguono, infatti, rappresentano solo una piccola parte del fenomeno.
-
Dipendenze open source
Una grande azienda utilizza nel proprio software migliaia di dipendenze open source, spesso con un controllo parziale su ciascuna di esse. Ogni libreria importata porta con sé, a sua volta, le proprie dipendenze creando alberi di componenti troppo estesi per essere verificati manualmente. Una singola libreria compromessa può propagarsi a tutte le applicazioni che la includono, come dimostrato dagli incidenti riportati in apertura. - Vulnerabilità infrastrutturali
Server, macchine virtuali, storage e reti su cui il software gira sono esposti a errori di configurazione. Alla base c'è quasi sempre un errore umano, ma la complessità degli strumenti cloud e la velocità del provisioning automatizzato amplificano il fenomeno, potenzialmente replicandolo su più ambienti prima che qualcuno se ne accorga. -
Esposizione delle pipeline CI/CD
La pipeline CI/CD non è un prodotto ma un processo orchestrato da strumenti come GitHub Actions, Jenkins o GitLab CI. È dunque un bersaglio ad alto valore, perché ha accesso al codice sorgente e alle chiavi di deploy. Se un attaccante riesce a infiltrarsi, può modificare direttamente il processo su cui si basa l’impalcatura dell’app, e tutto ciò che ne esce viene compromesso. - Perdita di segreti e credenziali
Può capire che API Key, token e password finiscano per errore dentro repository, log o file di configurazione, offrendo un accesso diretto a sistemi in produzione.
AI e software supply chain: nuovi componenti, nuovi rischi
Il rischio legato all'AI è più recente degli altri, ma non meno significativo. Merita dunque una trattazione separata, distinguendo tra due piani.
-
Modelli AI come componenti della supply chain
Ogni mese nascono migliaia di modelli AI che possono essere integrati dalle aziende e dai vendor nei loro applicativi. Come prevedibile, i ricercatori di sicurezza segnalano un aumento significativo di modelli malevoli o non sicuri distribuiti attraverso i principali canali. - Assistenti AI di coding
Quasi tutte le aziende adottano sistemi di assistenza allo sviluppo del codice, ma questi possono suggerire dipendenze inesistenti o non più aggiornate a livello di sicurezza. Chi sviluppa con l'assistenza dell'AI dovrebbe verificare ogni dipendenza suggerita prima di integrarla.
Cos'è, quindi, un attacco alla software supply chain
Messi in fila, tutti i rischi citati (e molti altri) disegnano un pattern preciso. Un attacco alla software supply chain non prende di mira l'applicazione finale in modo diretto, ma uno dei componenti fidati che contribuiscono a costruirla.
L'obiettivo non è abbattere le difese di un singolo bersaglio, ma inserirsi in un anello a monte di cui tutti si fidano, e lasciare che sia la catena stessa a distribuire il danno a valle.
Software Supply Chain Security, anche una questione di compliance
Fino a pochi anni fa la sicurezza della supply chain software era una questione di best practice volontarie. Non lo è più: normative e regolamenti hanno iniziato a trasformarla in un obbligo legale, spesso con sanzioni concrete per chi non si adegua.
- In Europa il riferimento è il Cyber Resilience Act, che impone requisiti di sicurezza informatica ai prodotti con elementi digitali venduti nel mercato UE. Tra i requisiti tecnici, il CRA rende obbligatoria la SBOM (Software Bill of Materials): i produttori devono predisporre e mantenere aggiornato un elenco machine-readable di almeno le dipendenze di primo livello del proprio software, da fornire alle autorità su richiesta.
- A questo si affianca l'AI Act, che introduce obblighi specifici per i sistemi di intelligenza artificiale in base al livello di rischio e che, alla luce di quanto detto sui modelli AI come componenti della supply chain, inizia a intersecarsi sempre più con il tema.
Accanto agli obblighi normativi, si sono affermati framework che definiscono controlli minimi e standard condivisi per l'intero settore. Tra questi segnaliamo:
- NIST SSDF (Secure Software Development Framework), un insieme di pratiche per integrare la sicurezza in ogni fase del ciclo di sviluppo software.
- SLSA (Supply-chain Levels for Software Artifacts) definisce livelli progressivi di integrità per il processo di build: più si sale di livello, più si riduce la possibilità che un artefatto venga manomesso lungo la catena.
- OpenSSF (Open Source Security Foundation) promuove diversi progetti e strumenti per la sicurezza dell'ecosistema open source.
Sicurezza della supply chain software: da dove partire
Non esiste un singolo strumento che risolve il problema della sicurezza della supply chain o che rende l’azienda conforme a framework e regolamenti vincolanti. Un approccio efficace lavora su più livelli contemporaneamente, partendo da ciò che oggi manca più spesso: la visibilità.
Un percorso efficace potrebbe essere questo.
-
Mappare tutte le dipendenze con una SBOM
Generare e mantenere aggiornata una Software Bill of Materials permette di sapere, in caso di vulnerabilità, se e dove un componente compromesso è in uso senza doverlo scoprire a incidente in atto. - Scansione codice e dipendenze in modo continuo
Strumenti di software composition analysis (SCA) e analisi statica del codice (SAST) integrati direttamente nelle pipeline permettono di intercettare librerie vulnerabili o malevole prima che arrivino in produzione. - Formulare priorità in base all’impatto
Le scansioni automatizzate possono produrre centinaia di segnalazioni, ma non hanno tutte lo stesso peso. Va valutato quali componenti sono raggiungibili da un attaccante e quali gestiscono dati sensibili o processi critici, per concentrare lì tutti gli sforzi di prevenzione. - Blindare la pipeline CI/CD
Accessi con privilegi minimi, validazione delle configurazioni, log e audit trail su ogni modifica al processo di build e deploy sono basilari per evitare soprese indesiderate. - Gestire al meglio segreti e credenziali
Vault dedicati, rotazione periodica, niente credenziali hardcoded nel codice o nei file di configurazione. Sono principi semplici, ma in molti casi ancora disattesi. - Valutare la sicurezza di fornitori e terze parti
Non basta fidarsi di un fornitore in quanto riconosciuto sul mercato. Il vendor deve effettuare e fornire verifiche periodiche, consentire l’inserimento di requisiti contrattuali di sicurezza e, dove possibile, fornire visibilità sulle sue pratiche di sviluppo. - Allinearsi a framework riconosciuti
Adottare pratiche coerenti con NIST SSDF o SLSA non è solo una questione di compliance: significa applicare controlli già pensati, testati e condivisi da tutto il settore, invece di reinventarli da zero.
In Kirey, la sicurezza del software è una priorità assoluta
In Kirey sviluppiamo e implementiamo software da sempre, e lo facciamo soprattutto in ambiti e aziende fortemente regolamentate, dove la sicurezza non è un'opzione ma un requisito di partenza.
Siamo perfettamente consapevoli che la sicurezza di un sistema informatico parta dal software, ma anche che questa non dipenda solo dal codice proprietario, bensì da un intero ecosistema di soggetti, strumenti e processi che va costantemente monitorato, valutato e testato.
Per questo adottiamo pratiche di sviluppo sicuro che si estendono all'intero ecosistema della supply chain, fornendo ai nostri clienti non solo garanzie di performance e capacità innovativa, ma anche di solidità e resilienza nel tempo.
Contattaci per scoprire come innovare la tua azienda in modo sicuro e sostenibile.
