Gli attacchi alla supply chain sono in aumento, ma molte organizzazioni non sono pronte ad affrontarli. In questa Newsletter di LinkedIn, Gonda Lamberink, Cybersecurity Executive di Bureau Veritas, spiega come gli SBOM possano aiutarla a prepararsi alle future minacce alla catena di approvvigionamento. Sottolinea che capire il contesto delle vulnerabilità, come ad esempio se il software è veramente exploitabile, è indispensabile per massimizzare il valore degli SBOM.

La minaccia: aumento degli attacchi alla catena di fornitura

L'uso diffuso di componenti open-source nel software e le vulnerabilità come Log4j e SolarWinds hanno esposto la fragilità delle catene di fornitura.

Nel 2024, Sonatype nel suo 10° Rapporto Annuale sullo Stato della Catena di Fornitura del Software afferma che gli attacchi alla catena di fornitura del software hanno subito un'impennata, raddoppiando rispetto all'anno precedente. Ad agosto, erano stati identificati più di 700.000 pacchetti di software open source (OSS) dannosi - un aumento impressionante del 156% rispetto all'anno precedente - sottolineando i rischi crescenti per le organizzazioni che non riescono a gestire in modo efficace le loro dipendenze OSS.

Nonostante l'aumento dei rischi per le catene di approvvigionamento, la capacità di risposta delle organizzazioni è bassa. Secondo il Global Cybersecurity Outlook 2024 del World Economic Forum (WEF), il 55,9% dei leader ritiene che tecnologie come l'IA generativa diano attualmente un vantaggio agli aggressori, mentre solo l'8,9% vede il panorama informatico a favore dei difensori. Per quanto riguarda gli attacchi alla catena di fornitura, il 54% delle organizzazioni non ha una comprensione sufficiente delle vulnerabilità informatiche della propria catena di fornitura.

SBOM: parte della soluzione

In qualità di professionista del settore della cybersecurity, ritengo che gli SBOM siano una parte importante della soluzione a questo problema di sicurezza della catena di fornitura e soprattutto all'attuale mancanza di trasparenza della catena di fornitura del software. Hanno il potenziale per diventare un elemento essenziale delle pratiche di sicurezza del software: possono facilitare la collaborazione e la responsabilità della catena di fornitura per mitigare i rischi.

Innanzitutto: cos'è una SBOM?

Un SBOM (Software Bill of Materials) è essenzialmente un elenco dettagliato di tutti i componenti che costituiscono un software, come l'elenco degli ingredienti di un alimento confezionato, scritto in un formato standard. Cataloga tutti i componenti software open-source e proprietari. Gli SBOM offrono alle organizzazioni la trasparenza della loro catena di fornitura del software, in modo da poter gestire meglio i rischi di sicurezza, i requisiti di conformità e le vulnerabilità operative.

Perché le SBOM sono importanti?

Poiché gli SBOM documentano i componenti di un sistema o prodotto software, sono fondamentali per creare visibilità sulle potenziali vulnerabilità e dipendenze. Due incidenti di alto profilo evidenziano l'importanza degli SBOM:

• SolarWinds (2020): Gli aggressori hanno iniettato codice maligno durante il processo di creazione del software, compromettendo oltre 18.000 clienti, tra cui agenzie federali e grandi aziende. Anche se gli SBOM non avrebbero potuto impedire l'attacco, avrebbero fornito un supporto cruciale: avrebbero potuto aiutare le organizzazioni a verificare se stavano utilizzando la versione del software interessata e ad agire più rapidamente per affrontare i rischi.
• Log4j (2021): Tutti ricordano questo attacco. Una falla critica in una libreria Java molto utilizzata ha avuto un impatto su milioni di applicazioni. A differenza di SolarWinds, dove l'attacco ha preso di mira un processo, Log4j ha evidenziato i rischi della dipendenza dai componenti. Molte organizzazioni non sapevano di dipendere da Log4j, causando ritardi nella risposta. In questo caso, gli SBOM sarebbero stati trasformativi. Fornendo alle organizzazioni una visibilità dettagliata sulle dipendenze del software, gli SBOM avrebbero potuto consentire di identificare rapidamente l'utilizzo di Log4j, dare priorità alla riparazione e ridurre realmente l'enorme impatto della vulnerabilità.

Spinta normativa per l'uso degli SBOM

I regolatori e i politici di tutto il mondo hanno riconosciuto l'importanza degli SBOM. Ecco alcuni esempi chiave di normative e politiche che fanno riferimento all'uso degli SBOM e ne impongono l'uso:

• Cyber Resilience Act (CRA) dell'UE: Richiede gli SBOM per tutti i prodotti digitali per affrontare le vulnerabilità del software e rafforzare la responsabilità nelle catene di fornitura.
• Ordine esecutivo statunitense 14028: impone gli SBOM per gli acquisti federali di software, con linee guida di NTIA, NIST e CISA a supporto dell'adozione.
• Regole specifiche del settore: Settori come l'assistenza sanitaria, i trasporti e le infrastrutture critiche ora enfatizzano gli SBOM per allinearsi, ad esempio, alle linee guida sulla Cybersecurity della FDA, al regolamento UNECE per l'omologazione dei veicoli e al regolamento NIS2.

Come utilizzare gli SBOM nella pratica

Naturalmente, le normative e le politiche non equivalgono all'azione. Vedo alcune cose che il settore può fare per aiutare gli SBOM a decollare e consiglierei ai fornitori di software e agli utenti di fare quanto segue:

• Fornitori: Generare SBOM in ogni fase del ciclo di vita del software (sorgente, compilazione, distribuzione) in conformità ai formati standard SBOM ampiamente utilizzati, come SPDX e CycloneDX. Implementare sistemi automatizzati per gli aggiornamenti in tempo reale per mantenere l'accuratezza.
• Integratori: Incorporare gli SBOM nelle loro soluzioni e mantenere una comunicazione aperta con i proprietari di asset sul loro utilizzo e impatto.
• Proprietari e operatori di asset: Sfruttare gli SBOM per allineare i processi di approvvigionamento, operazioni, gestione delle vulnerabilità e incident response con le best practice di sicurezza del software.

L'adozione degli SBOM diventa molto più efficace quando le organizzazioni seguono standard consolidati o anche ancora emergenti, non solo per la loro generazione - come i formati SPDX e CycloneDX - ma anche per la loro condivisione e consumo.

Inoltre, il mio consiglio principale è quello di integrare le SBOM con gli strumenti esistenti, tra cui l'Analisi della Composizione del Software (SCA), le pipeline di Integrazione Continua/Distribuzione Continua (CI/CD), i sistemi di Analisi del Rischio e della Conformità (GRC) e le soluzioni di gestione delle vulnerabilità, che aumentano notevolmente la loro utilità, soprattutto se utilizzate insieme ad altri artefatti, altrettanto importanti di una SBOM, come un file VEX (Vulnerability Exploitability eXchange), contenente lo stato e l'impatto delle vulnerabilità associate a una SBOM.

Questo approccio trasforma le SBOM da un elenco statico in una conoscenza attuabile che rafforza la sicurezza, la Compliance e i flussi di lavoro operativi:

• Gli strumenti di automazione possono semplificare la creazione, l'aggiornamento, la condivisione e il consumo delle SBOM nel ciclo di vita del software, riducendo gli errori e aumentando l'efficienza.
• Il collegamento delle SBOM con i dati di vulnerabilità contestualizzati, i feed di intelligence sulle minacce e i framework di governance consente alle organizzazioni di affrontare le vulnerabilità e i rischi in modo più efficace.

La mia conclusione: sì, gli SBOM cambiano le carte in tavola.

Concludendo: Gli SBOM stanno trasformando la sicurezza della catena di approvvigionamento, rispondendo all'esigenza di visibilità e responsabilità, in particolare nei settori critici. Offrono approfondimenti che consentono alle organizzazioni di gestire i rischi e identificare le vulnerabilità in modo più efficace, come si vede in settori come quello dell'energia, dove gli SBOM svolgono un ruolo chiave nel soddisfare le esigenze di Compliance e nel mantenere le operazioni.

Quindi sì, per rispondere alla domanda al centro di questo articolo: Ritengo che le SBOM siano un fattore di svolta per la sicurezza della catena di approvvigionamento, soprattutto quando sono combinate con il contesto dell'exploit delle vulnerabilità attraverso i file VEX. Gli SBOM identificano le vulnerabilità, mentre i file VEX aiutano efficacemente a stabilire le priorità e a rimediare ai rischi reali. Nessuno dei due dovrebbe essere un artefatto statico: il loro pieno potenziale si realizza attraverso l'integrazione, tra l'altro, con le pipeline CI/CD e i sistemi di gestione delle vulnerabilità, con l'automazione che garantisce un aggiornamento costante e la possibilità di agire.