Il concetto di Software Supply Chain sta registrando un’importanza crescente da quando l’approccio Cloud Native ha cominciato ad essere sempre più centrale nello sviluppo di applicazioni moderne. Come nell’industria tradizionale, una catena di approvvigionamento sempre più articolata espone un numero più alto di punti di attacco malevolo, e richiede tracciamenti e verifiche che prima potevano essere ignorate.
Lo dimostrano alcuni eventi significativi accaduti negli ultimi anni che hanno fortemente influenzato il nostro modo di comprendere la sicurezza. Nel panorama attuale, è importante porre l’attenzione su nuovi elementi quali gli artefatti OCI e su come anch’essi possono essere colpiti da vulnerabilità all’interno della Supply Chain nella sua interezza. È per questo che risulta sempre più importante conoscere tecniche e strumenti open source che consentano di proteggerci da tali minacce.
LEGGI ANCHE:La Software Supply Chain Security (SSCS) è diventata un argomento di crescente importanza nell'ambito della sicurezza informatica. La SSCS riguarda l'intera catena di approvvigionamento del software, che comprende il processo di sviluppo, distribuzione, gestione e manutenzione dei componenti software utilizzati in un sistema, ed è fondamentale per garantire che il software utilizzato sia privo di vulnerabilità e di componenti malevoli. Una minaccia nella catena di approvvigionamento del software potrebbe consentire a un attaccante di compromettere la sicurezza e l'affidabilità dei sistemi informatici, con conseguenze potenzialmente devastanti.
Secondo Wikipedia la Supply Chain è un network di individui ed aziende che sono coinvolti nel creare un prodotto e poi consegnarlo ai consumatori.
Si tratta di una definizione ultra generica che ovviamente può essere applicata ad ogni tipologia di prodotto, da una scarpa fino ad un cluster Kubernetes.
L’infografica qui di seguito mostra quanto la supply chain tradizionale sia molto simile a quella del software, a partire dai nostri sorgenti che sono le nostre materie prime, fino alla consegna del prodotto finito ai nostri utenti.
Ovviamente, la supply chain software soffre di una serie di specifiche vulnerabilità, che sono ben rappresentate da quest’ulteriore infografica derivata da SLSA ("salsa"), un security framework specificatamente studiato per aiutare a mettere in sicurezza ogni collegamento della catena, e anche i punti intermedi. Qui con framework non si intende un framework software, bensì una serie di linee guida e di implementazioni pratiche e reali, come la generazione di SBOM o la firma crittografica, build attestations e tanto altro. Vi consigliamo di approfondire e di iniziare ad adottarlo in modo incrementale, dato che si tratta di un progetto a livelli, adottabile progressivamente.
La security non è un tool, ma una cultura, e soprattutto è sempre in uno stato transitorio: quello che oggi è sicuro domani potrebbe non esserlo più, per cui è sempre bene adottare più buone pratiche possibili.
Tante volte si tende a pensare che le vulnerabilità della supply chain arrivino principalmente dall’uso di dipendenze malevole, quando nella realtà delle cose ogni blocco della catena è soggetto a vulnerabilità, così come i loro punti di interconnessione.
Gli attacchi recenti dimostrano quanto siano proprio questi ultimi ad essere vettori di attacco in crescita.
Prendiamo ad esempio il punto C nell’immagine qui sopra: rappresenta il momento in cui una vulnerabilità ha compromesso i build server.
Immaginiamo questo scenario e quanto sarebbe complicato poterlo individuare. Potremmo essere stati infettati da un malware che si sveglia solo durante il processo di compilazione, producendo un binario compromesso con una backdoor all’interno, che viene potenzialmente anche firmato crittograficamente.
Questo binario verrà dato in pasto ai nostri utenti che di fatto, si vedranno recapitare qualcosa di legittimo e firmato da noi.
Proprio questo è stato il vettore di uno degli attacchi più importanti e gravi degli ultimi anni. Le minacce alla Software Supply Chain Security possono presentarsi in diverse forme.
Un esempio noto è rappresentato dall'attacco al fornitore di software SolarWinds, avvenuto nel dicembre 2020. Gli attaccanti hanno infiltrato il processo di sviluppo del software compromettendo una versione aggiornata del software Orion. Questa versione compromessa è stata quindi distribuita agli utenti finali, aprendo la porta a una serie di attività malevole. L'attacco a SolarWinds ha dimostrato come una minaccia alla catena di approvvigionamento del software possa colpire organizzazioni di ampia portata, compresi governi e aziende di alto profilo.
Un altro esempio recente è stato l'attacco ransomware alla società Colonial Pipeline negli Stati Uniti nell'aprile 2021. L'attacco ha sfruttato una vulnerabilità nel software di gestione delle pipeline e ha causato la sospensione delle operazioni, provocando gravi interruzioni nell'approvvigionamento di carburante nella regione. Questo evento ha evidenziato la vulnerabilità della catena di approvvigionamento del software e l'importanza di garantire la sicurezza dei componenti software critici per le infrastrutture critiche.
I dati dell’annual report di Sonatype sullo stato della supply chain, indicano come dal 2020 ad oggi, il numero degli attacchi sia in crescita esponenziale. La domanda è perché ciò stia accandendo. Esistono diverse ragioni.
La prima è sicuramente la crescita della domanda di software open-source che negli anni si è affermato come modello di riferimento. Oggi non c’è software in alcun settore che non sia basato su componenti open source: si stima che oltre il 98% del software di mercato ne contenga almeno l’1% - e il restante 2% probabilmente non sa di averlo.
Inoltre, oggi oltre più dell’80% del software che viene prodotto è rappresentato da dipendenze dipendenze transitive, che sono quelle più pericolose.
Proviamo a farne un elenco.
Sfrutta la caratteristica di quasi tutti i più popolari package manager, cioè verifica la presenza di un pacchetto prima in un registry pubblico e solamente dopo in quello privato. In altre parole, ad un attacker basterebbe venire a conoscenza di un nome di pacchetto privato, caricarlo nel registry pubblico con una versione maggiore, cosi da renderlo prioritario, e quindi forzarne lo scaricamento da parte del package manager.
Può avvenire in diversi modi, tramite una compromissione oppure guadagnando fiducia nel progetto fingendo di essere un contributor e quando ottenuta la fiducia, inserendo codice malevolo direttamente o tramite una dipendenza.
oppure inserendo un errore nel nome (un esempio “electorn” invece che “electron”). A quel punto non rimane che attendere il download degli utenti. Esempi interessanti li trovate qui Bytesafe.
Gli attaccanti possono falsificare o sostituire componenti software legittimi con versioni compromesse o malevole. Questo può avvenire durante il trasporto dei componenti o tramite fornitori terzi non attendibili.
Gli attaccanti cercano di compromettere i processi di sviluppo del software, infiltrandosi nei sistemi di gestione del codice sorgente o nei repository di distribuzione dei pacchetti software. Questo consente loro di introdurre codice malevolo o vulnerabilità all'interno dei componenti software.
Gli attaccanti possono compromettere i server utilizzati per distribuire gli aggiornamenti software legittimi. In questo modo, possono diffondere versioni di software compromesse ai clienti.
Le infrastrutture critiche, come reti energetiche o sistemi finanziari, possono essere soggette a attacchi mirati alla Software Supply Chain. Gli attaccanti cercano di compromettere i componenti software critici per queste infrastrutture al fine di causare danni significativi o interruzioni nel funzionamento.
Tra gli attacchi diventati popolari negli ultimi mesi in ambito supply chain, si annovera quello chiamato come “Protestware”, un attacco dove il mantainer del progetto sabota deliberatamente il progetto per causare danni o malfunzionamenti, in segno di protesta. Ci sono stati casi importanti nel 2022, ma sicuramente il più famoso è il progetto colors/fakers che ha aggiunto codice DoS verso le grandi corporation.
Il recente incremento degli attacchi alla Supply Chain ha, tra le sue conseguenze, una ricaduta molto pesante sull’economia dell’intera industria, con implicazioni che riguardano la possibile sfiducia in questo modello di sviluppo e un impatto negativo in termini di reputazione. Si stima che solo il costo degli attacchi di tipo supply chain potrebbe superare i 46 miliardi di dollari quest’anno, e raggiungere ampiamente gli 80 già nel 2026.
Questo scenario ha portato i principali governi mondiali a promulgare nuove leggi con l’obiettivo di regolamentare in modo più attento l’industria, entrando nel dettaglio anche degli aspetti di supply chain e della produzione del software, dei suoi processi e delle responsabilità in campo lungo la filiera.
Negli Stati Uniti la strategia nazionale segue l’ordine esecutivo emanato nel 2022 e sta già entrando in vigore nei vari Stati. L’obiettivo principale è la regolamentazione dei rapporti tra pubblico e privato, scendendo nello specifico delle tecnologie, fino al livello di SBOM (Software Bill of Material) e di responsabilità.
In Europa, invece, la questione è molto più delicata. Il CRA (Cyber Resiliency Act) ha il compito di regolamentare qualsiasi prodotto contenga elementi digitali. Usando un parallelismo, è come definire un bollino CE da applicare al software, così come avviene per i componenti elettronici.
Sono ovviamente iniziative fondamentali ed importanti, e riteniamo che sia giusto che vengano portate al tavolo, ma pongono un problema di sostenibilità del modello di sviluppo Open Source: da un lato si schierano i requisiti tecnici obbligatori che potrebbero aumentare notevolmente per poter pubblicare del software approvato, dall’altra il concetto di responsabilità che potrebbe ricadere su chi produce del codice per renderlo disponibile alla comunità, un’eventualità che ovviamente non è compatibile in un modello che su larga scala si basa su lavoro volontario e indipendente.
Come era facile aspettarsi, le risposte non sono arrivate solo dai governi, ma anche dalla community che ha risposto in modo forte ed organizzato.
È stata creata una nuova fondazione, la OpenSSF, come branch della Linux Foundation, con la missione di sostenere la security dell’ecosistema open source. Si lavora su standard, come CycloneDX e SPDX per la generazione di SBOM, sono stati sviluppati nuovi software per semplificare la firma con chiave asimmetrica dei software grazie a Sigstore e tanto altro.
Si tratta di un ottimo segnale di presa di coscienza da parte della community, che deve aiutare a guidare i governi e le organizzazioni a decidere per il meglio.
Ne abbiamo accennato in apertura di articolo, ma per dare concretezza a quanto detto sinora, riprendiamo e approfondiamo uno degli attacchi più importanti di Supply Chain avvenuti dal 2020 ad oggi.
Parliamo del caso SolarWinds, la dimostrazione pratica e su larga scala di uno degli attacchi più gravi della storia di questo settore. SolarWinds è un' azienda americana che sviluppa soluzioni per il monitoraggio e la gestione dell'Information Technology (IT). Tra i clienti hanno le più grandi enterprise al mondo e molte agenzie governative, come il Pentagono, Homeland Security, l’Agenzia per la Sicurezza Nazionale. Uno dei suoi prodotti più famosi e popolari è la piattaforma Orion, ed è da qui che parte la storia.
A gennaio 2021 Crowdstrike, un’azienda di Cybersecurity tra le prime ad essere state colpite, scopre l’esistenza del malware Sunspot, progettato per sostituire in fase di compilazione i sorgenti legittimi con una versione malevola contenente la backdoor Sunburst. Sunspot aveva infettato i build system di Solarwinds. Il risultato di questo processo ha permesso di distribuire una nuova release di Orion, contenente un malware, a tutti i clienti, come fosse un normale patch di sicurezza. SolarWinds è l’ennesima riprova che a oggi non esiste alcuna organizzazione al sicuro dal rischio di compromissione.
Nel 1984, Ken Thompson in un famoso paper chiamato “Reflections on trusting trust” si chiedeva proprio come fino a che punto dobbiamo fidarci del fatto che il codice non contenga cavalli di troia. La morale è semplice: non possiamo mai fidarci del codice che non abbiamo creato, nessuna verifica estensiva fatta sui sorgenti potrà mai proteggerci completamente.
Però possiamo fidarci delle persone che lo scrivono, vediamo come possiamo fare.
Per ridurre la vulnerabilità nella catena di approvvigionamento del software, sono necessarie una serie di misure preventive e di mitigazione. Proviamo a proporre una panoramica il più esaustiva possibile, ma come detto, si tratta di un ambito in evoluzione rapida.
Guarda il video del talk di Paolo Mainardi, CTO di SparkFabrik, e di Andrea Panisson, Cloud Architect di SparkFabrik, al KCD Italy 2023
Nel paragrafo precedente, abbiamo identificato le azioni più di alto livello per mitigare le vulnerabilità della catena di approvigionamento software. Volendo csendere ancora più in profondità, su piattaforme come Kubernetes, che sfruttano l'architettura a container per distribuire le applicazioni, è possibile proteggere la Supply Chain utilizzando gli artefatti OCI (Open Container Initiative).
Gli artefatti OCI rappresentano il punto di partenza per creare le immagini dei container utilizzate in un ambiente Kubernetes. La loro sicurezza è dunque fondamentale per evitare l'iniezione di codice malevolo o vulnerabilità con ricadute a cascata. Quali le best practice? Eccone alcune:
Abbiamo parlato di Secure Software Supply Chain, di quali siano le minacce che oggi esistono (non più limitate all’applicativo come in passato, ma distribuite lungo tutta la filiera di approvigionamento), di quali siano le prossime regolamentazioni di mercato e cosa fare per mitigarle. Ma cosa può fare SparkFabrik per il tuo team e il tuo business?
Possiamo aiutarti in un audit iniziale che possa permetterti di diagnosticare lo stato della supply chain in cui il tuo software opera. Andremo a fare un’analisi dei rischi identificando soluzioni azionabili per poter risolvere le criticità, che si tratti di un adattamento applicativo, o un aggiustamento della CI/CD.
Risaliremo tutto il processo per capire dove poter intervenire al fine di ridurre al minimo il rischio di vulnerabilità.
Queste sono solo alcune delle azioni che possiamo intraprendere insieme. La nostra esperienza nel campo dello sviluppo software e della security può essere un prezioso contributo per migliorare la sicurezza complessiva del tuo ambiente di sviluppo. Chiedici un audit iniziale.