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:Cos’è la Software Supply Chain Security?
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.
Quali sono le principali tipologie di attacchi in ambito Supply Chain?
Proviamo a farne un elenco.
Dependency confusion o namespace confusion
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.
Sfruttamento di una libreria popolare come vettore per codice malevolo
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.
Creazione di un componente con un nome molto simile ad uno esistente
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.
Falsificazione di componenti
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.
Infiltrazione dei processi di sviluppo
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.
Compromissione dei server di aggiornamento
Gli attaccanti possono compromettere i server utilizzati per distribuire gli aggiornamenti software legittimi. In questo modo, possono diffondere versioni di software compromesse ai clienti.
Attacchi mirati alle infrastrutture critiche
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.
Storia recente di attacchi in ambito Software Supply Chain
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.
Come ridurre le vulnerabilità della Software Supply Chain?
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.
- Verifica della sicurezza dei fornitori: è essenziale eseguire una rigorosa valutazione della sicurezza dei fornitori di software. Ciò implica l'analisi delle pratiche di sicurezza implementate durante lo sviluppo del software, la valutazione dei processi di test e revisione del codice, e la verifica delle misure di protezione dei dati.
- Validazione delle componenti software: è importante verificare l'integrità e l'autenticità delle componenti software utilizzate. Questo può essere fatto attraverso l'implementazione di meccanismi di firma digitale, l'utilizzo di repository di distribuzione affidabili e l'adozione di pratiche di verifica delle componenti.
- Monitoraggio costante: è cruciale monitorare costantemente la catena di approvvigionamento del software per rilevare eventuali anomalie o intrusioni. Sistemi di rilevamento delle minacce avanzati possono aiutare a identificare attività sospette e segnalare potenziali violazioni.
- Collaborazione e condivisione delle informazioni: la condivisione di informazioni sulla sicurezza tra le organizzazioni può contribuire a rafforzare la resilienza della catena di approvvigionamento del software. Le organizzazioni possono beneficiare della collaborazione per identificare e affrontare le minacce comuni.
Guarda il video del talk di Paolo Mainardi, CTO di SparkFabrik, e di Andrea Panisson, Cloud Architect di SparkFabrik, al KCD Italy 2023
Come ridurre le vulnerabilità utilizzando gli artefatti OCI?
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:
- Utilizzare artefatti OCI verificati: Assicurati di utilizzare solo artefatti OCI provenienti da fonti affidabili e verificate. Verifica le firme digitali degli artefatti per garantire che non siano stati alterati o compromessi durante il trasferimento o l'archiviazione.
- Aggiornamenti regolari degli artefatti: Mantieni gli artefatti OCI aggiornati con le ultime versioni rilasciate dagli sviluppatori. Le nuove versioni spesso includono patch di sicurezza per risolvere vulnerabilità note. Monitora le notifiche di sicurezza e agisci prontamente per applicare gli aggiornamenti necessari.
- Valutazione delle dipendenze dei pacchetti: È fondamentale valutare e monitorare le dipendenze dei pacchetti per rilevare versioni obsolete o vulnerabili. Utilizza strumenti di analisi delle dipendenze per identificare e risolvere eventuali problemi di sicurezza.
- Verifica dell'integrità degli artefatti: Durante il trasferimento e l'archiviazione degli artefatti OCI, è importante garantire la loro integrità. Utilizza connessioni sicure per il trasferimento dei pacchetti e implementa meccanismi di controllo dell'integrità, come le firme digitali, per garantire che gli artefatti non siano stati alterati o corrotti.
- Implementazione di controlli di sicurezza: È utile implementare pipeline di rilascio che includano analisi statica del codice, analisi delle vulnerabilità, test di sicurezza e revisioni dei processi di approvazione. In questo modo, puoi rilevare e risolvere le vulnerabilità durante tutto il processo di sviluppo del software.
- Monitoraggio delle minacce: Utilizza strumenti di intelligence sulle minacce e mantieniti aggiornato sulle ultime tendenze e tecniche di attacco per poter adottare misure preventive adeguate.
La sicurezza della catena di approvvigionamento del software è una responsabilità condivisa tra gli sviluppatori, gli operatori di Kubernetes e i fornitori di artefatti OCI. Collaborazione e adozione delle migliori pratiche sono essenziali per garantire un ambiente Kubernetes sicuro e affidabile.
Osservabilità significa semplicemente utilizzare tutte e tre queste fonti di informazione in modo aggregato per analizzare e prevedere il funzionamento di un sistema complesso, altrimenti impossibile da gestire con sicurezza.
Cosa può fare SparkFabrik per te?
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à.
- Audit della tua Software Supply Chain: SparkFabrik può condurre un'analisi completa della tua catena di approvvigionamento del software per identificare eventuali vulnerabilità. Questa analisi può includere la valutazione delle dipendenze dei pacchetti, l'individuazione di versioni obsolete o vulnerabili, l'identificazione di componenti con problemi noti di sicurezza e l'analisi delle procedure di gestione dei fornitori.
- Aggiornamento regolare dei componenti: SparkFabrik può aiutarti a mantenere i tuoi componenti software aggiornati. Questo include l'identificazione delle ultime versioni rilasciate, la valutazione delle note sulla versione per rilevare patch di sicurezza e la pianificazione e l'esecuzione degli aggiornamenti necessari per rimuovere eventuali vulnerabilità, inoltre è possibile predisporre sistemi automatici in grado di identificare ed aggiornare le dipendenze software.
- Monitoraggio delle minacce: possiamo implementare sistemi di monitoraggio delle minacce per rilevare tempestivamente le nuove vulnerabilità che potrebbero influire sulla tua catena di approvvigionamento del software. Questo può includere l'utilizzo di strumenti di intelligence sulle minacce e di monitoraggio delle notifiche di sicurezza.
- Formazione e consapevolezza: SparkFabrik può fornire formazione e consapevolezza sulle migliori pratiche di sicurezza informatica per il personale coinvolto nella catena di approvvigionamento del software. Ciò include l'educazione sulle minacce più comuni, l'importanza della sicurezza nel processo di sviluppo del software e la promozione di pratiche di sicurezza solide, soprattutto all’interno del complesso ambito Cloud Native, fino all’aiuto della definizione del ruolo di un OSPO all’interno della vostra organizzazione.
- Implementazione del framework SLSA: SparkFabrik può collaborare con te per implementare fino a L3 del framework SLSA. Questi controlli possono includere la verifica dell'integrità dei pacchetti, la firma digitale dei componenti software, audit dei registri software, la produzione di SBOM e di attestati di provenienza e la creazione di processi di revisione e approvazione per i nuovi componenti.
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.
- Post precedente
- Vedi tutti i post
- Post successivo