Cos'è un SBOM?

Un SBOM, ovvero una distinta dei materiali software, è un elenco dei componenti e delle dipendenze che costituiscono un determinato prodotto software. Comprende tutte le librerie, i moduli, i framework e le altre risorse esterne necessarie per la realizzazione del software, nonché le relazioni tra di essi. In sostanza, un SBOM rappresenta la catena di fornitura digitale di un sistema software. E ora tale requisito è obbligatorio per tutti i fornitori che vendono software al governo federale. Anche tutti coloro che sviluppano o gestiscono software possono trarne vantaggio.

Gli SBOM fanno parte dell’ Community open source da oltre un decennio, ma hanno attirato maggiore attenzione negli ambienti della sicurezza informatica a seguito dell’ondata di attacchi alla catena di approvvigionamento del software ai danni di aziende e agenzie governative statunitensi negli anni 2020 e 2021.

L’attacco informatico ai danni di SolarWinds ( ), in particolare — in cui alcune agenzie federali, tra cui il Dipartimento per la Sicurezza Interna e il Dipartimento del Tesoro, avevano inconsapevolmente implementato un componente infettato da un trojan che ha consentito agli autori dell’attacco di accedere ai sistemi informatici delle vittime — ha portato all’emanazione di un ordine esecutivo in maggio 2021 che impone a qualsiasi fornitore che venda software al governo federale di specificarne i componenti in un SBOM.

Data la complessità della catena di approvvigionamento del software, un singolo componente software può avere un impatto sproporzionato sulla sicurezza dello stesso. Tuttavia, gli utenti dispongono di una visibilità minima sui componenti integrati nelle loro applicazioni più critiche per l’attività aziendale. Disporre di un elenco degli “ingredienti” dei prodotti può fornire loro un quadro più chiaro dei rischi per la sicurezza e offre una linea guida per individuare le vulnerabilità prima che queste provochino una crisi.

Qual è l'origine dell'SBOM?

La nuova attenzione rivolta agli SBOM deriva dal decreto presidenziale (EO) n. 14028 del presidente Biden, intitolato “ ” (Migliorare la sicurezza informatica della nazione) , che incarica il National Institute of Standards and Technology (NIST ) e altre agenzie federali di potenziare la sicurezza informatica attraverso una serie di iniziative relative alla sicurezza e all’integrità della catena di fornitura del software, al fine di proteggere meglio le reti del governo federale.

Il decreto esecutivo è stato in gran parte una risposta all’ondata di attacchi informatici contro le aziende statunitensi e il governo degli Stati Uniti negli anni 2020 e ’21. Gli attacchi verificatisi in quel periodo sono stati più frequenti e più gravi; due dei più devastanti — quello ai danni di SolarWinds e l’attacco ransomware alla Colonial Pipeline — hanno determinato l’emanazione del decreto presidenziale.

Nell’attacco a SolarWinds, un singolo componente infettato da un trojan presente nel software Orion dell’azienda con sede in Texas — utilizzato per monitorare e gestire reti e infrastrutture IT — ha consentito agli hacker di accedere ai sistemi di migliaia di organizzazioni, tra cui aziende della classifica Fortune 500 , diverse agenzie del governo federale e persino la stessa società statunitense specializzata in sicurezza informatica che alla fine ha individuato la violazione. Fino a 18.000 vittime del settore privato e pubblico hanno scaricato il software infetto, sebbene in seguito il numero di quelle effettivamente compromesse sia risultato inferiore.

L'attacco ransomware ai danni della Colonial Pipeline ha preso di mira una singola organizzazione, ma ha avuto ripercussioni di vasta portata sulle infrastrutture del Paese. Quando l’azienda, che fornisce circa il 45 % del carburante della costa orientale, ha scoperto l’attacco, è stata costretta a mettere fuori servizio i sistemi informatici critici per contenere la minaccia, interrompendo di fatto le proprie attività. La conseguente carenza di carburante ha provocato una corsa agli acquisti dettata dal panico e un’impennata dei prezzi della benzina.

[Leggi anche: Cosa comporta il decreto presidenziale di Biden per i dirigenti del settore tecnologico]

Il decreto presidenziale tiene conto degli insegnamenti tratti da questi e da altri incidenti di sicurezza e mira a promuovere la collaborazione tra il settore pubblico e quello privato al fine di mitigare gli attacchi informatici sempre più sofisticati. In particolare, il documento delinea diversi obiettivi:

• Migliorare la condivisione delle informazioni —Il decreto esecutivo dispone che vengano rimosse tutte le barriere contrattuali alla condivisione delle informazioni sulle minacce tra il governo e il settore privato e impone ai fornitori di servizi informatici di condividere le informazioni relative a minacce, vulnerabilità e incidenti che potrebbero avere un impatto sul governo federale.
• Modernizzare la sicurezza informatica della pubblica amministrazione —Il decreto presidenziale incarica il governo federale di introdurre standard di sicurezza informatica più rigorosi e migliori pratiche. Tra queste figurano l’adozione di servizi cloud sicuri , l’utilizzo di un modello di sicurezza “zero-trust” e l’implementazione dell’autenticazione a più fattori (MFA) e di procedure di crittografia.
• Rafforzare la sicurezza della catena di approvvigionamento del software —Il governo intende stabilire standard minimi di sicurezza per lo sviluppo del software che acquista dai fornitori. Il Dipartimento del Commercio e l’Amministrazione Nazionale delle Telecomunicazioni e dell’Informazione (NTIA) devono pubblicare gli elementi costitutivi di una distinta dei materiali software che elenchi e descriva in dettaglio i singoli componenti che costituiscono un prodotto software.
• Istituire un comitato di revisione per la sicurezza informatica —Il governo istituirà un comitato di revisione per la sicurezza informatica ( ) , presieduto congiuntamente da esperti del settore pubblico e privato, che si riunirà a seguito di un incidente significativo di sicurezza informatica per analizzare quanto accaduto e formulare raccomandazioni volte al miglioramento della sicurezza.

[Leggi anche: Il piano d’azione del governo statunitense per rafforzare le catene di approvvigionamento]

• Creare un manuale operativo per la risposta agli incidenti —I responsabili IT del settore pubblico devono elaborare un manuale operativo standard per la risposta agli incidenti di sicurezza, al fine di garantire che tutte le agenzie federali siano in grado di reagire efficacemente agli attacchi informatici e di porvi rimedio.
• Migliorare il rilevamento degli incidenti —L’EO richiede l’implementazione di un sistema di rilevamento e risposta (EDR ) a livello governativo endpoint e il miglioramento della condivisione delle informazioni all’interno del governo federale al fine di garantire un più efficace rilevamento degli incidenti di sicurezza informatica.
• Migliorare le indagini e le misure correttive —Il governo definirà i requisiti relativi ai registri degli eventi di sicurezza informatica per tutte le agenzie federali, al fine di migliorare le indagini e le misure correttive relative agli incidenti di sicurezza informatica sulle reti del governo federale.

Il decreto esecutivo ha definito gli obiettivi immediati che diverse agenzie governative devono raggiungere, ma sta provocando un effetto a cascata lungo l’intera catena di approvvigionamento degli appalti federali. Nello specifico, il decreto presidenziale riguarda tre gruppi:

• Le agenzie esecutive federali —— Le agenzie governative di primo livello hanno il compito di modernizzare il proprio ambiente tecnologico e le proprie pratiche di sicurezza.
• Appaltatori federali —Gli appaltatori che intrattengono rapporti commerciali con il governo degli Stati Uniti, compresi i fornitori di software commerciale pronto all’uso (COTS), possono aspettarsi che nei termini contrattuali vengano inseriti nuovi standard di sicurezza informatica. Sono inoltre tenuti a condividere un maggior numero di informazioni relative agli incidenti informatici.
• Imprese private —Le imprese private saranno soggette a una nuova normativa in materia di sicurezza informatica e a un’applicazione più rigorosa delle leggi e delle politiche esistenti, con particolare attenzione alla sicurezza della catena di fornitura del software “ ” e alla segnalazione degli incidenti informatici . Si pone inoltre maggiore enfasi sulla trasparenza attraverso la proposta di un'etichettatura di sicurezza per i consumatori relativa al software e ai dispositivi dell'Internet delle cose (IoT), il che comporta nuovi requisiti di sicurezza e standard di valutazione per tali fornitori.

Perché gli SBOM sono importanti oggi?

Gli SBOM sono importanti in quanto consentono alle organizzazioni di individuare e correggere eventuali vulnerabilità presenti nel proprio software e nelle relative dipendenze. Le applicazioni moderne vengono sviluppate avvalendosi di una catena di fornitura di componenti software altrettanto complessa di quelle utilizzate dai produttori di beni fisici. Un tipico sistema di gestione dei rischi ( App ) è costituito da decine di componenti che combinano codice proprietario e componenti riutilizzabili di terze parti. Sebbene uno sviluppatore possa verificare il codice da lui scritto alla ricerca di errori e imperfezioni, ha una minore visibilità sul codice di terze parti. Gli autori degli attacchi ne sono consapevoli e ne approfittano, prendendo di mira componenti di terze parti nella certezza che probabilmente riusciranno a eludere il rilevamento.

“Quandoviene individuata o resa nota una vulnerabilità, gli SBOM possono aiutare a determinare in quali punti dell’organizzazione sia in uso quella versione del software.”

Oltre al ormai tristemente famoso incidente di SolarWinds, una serie di attacchi alla catena di approvvigionamento verificatisi negli ultimi anni ha messo in luce gli effetti devastanti che tale scenario può comportare. Gli autori degli attacchi hanno sfruttato una vulnerabilità critica nel software open source Apache Log4j , una libreria di registrazione quasi onnipresente che registra le attività in milioni di applicazioni basate su Java. Gli hacker hanno inoltre sfruttato quattro distinte vulnerabilità zero-day di tipo “ ” presenti nel server Microsoft Exchange per ottenere l’accesso alle reti di 30.000 organizzazioni statunitensi.

Un SBOM può aiutare un’azienda a proteggersi meglio da questo tipo di attacchi alla catena di fornitura e a stabilire le priorità nella gestione dei rischi. Ad esempio, può avvalersi delle SBOM per eliminare innanzitutto l’uso di librerie con vulnerabilità note e, successivamente, per garantire che venga utilizzata la versione più recente di ciascuna libreria open source. Quando viene individuata o resa nota una vulnerabilità, gli SBOM possono aiutare a individuare in quali punti dell’organizzazione viene utilizzata quella versione del software. Più in generale, gli SBOM consentono alle organizzazioni di prendere decisioni più consapevoli riguardo al software che utilizzano e incoraggiano i fornitori di software a realizzare prodotti più sicuri.

Quali sono le componenti di una SBOM?

All’indirizzo luglio 2021, la NTIA ha pubblicato il documento “The Minimum Elements For a Software Bill of Materials” (Elementi minimi per una distinta dei materiali software), in cui vengono delineati i requisiti federali previsti dalla legge “ ” relativi alla SBOM. Esso suddivide le componenti di base di uno SBOM in tre categorie: campi dati, supporto all’automazione, nonché pratiche e processi. Ecco una panoramica più dettagliata di ciascuno di essi.

Campi dati
I campi dati devono identificare in modo univoco ciascun componente, in modo che possa essere monitorato lungo tutta la catena di fornitura del software e incrociato con i database relativi alle vulnerabilità e alle licenze. La NTIA specifica sette campi di dati:

• Nome del fornitore: Il nome dell'organizzazione che crea e identifica il componente.
• Nome del componente: Il nome assegnato a un'unità software dal fornitore originale.
• Versione del componente: I dettagli relativi alla build e alla versione del componente utilizzato in un prodotto software.
• Altri identificatori univoci: Chiavi di ricerca e altre informazioni, quali un identificatore tratto dal Dizionario CPE di NIST', che possono essere utilizzati per identificare un componente.
• Relazioni di dipendenza: Una descrizione delle dipendenze tra il componente e altri software. Ad esempio, il componente A è incluso nel software B.
• Autore dei dati SBOM: Il nome dell’organizzazione che ha creato i dati SBOM del componente.
• Data e ora: Data e ora in cui sono stati compilati i dati SBOM.

Supporto all’automazione
Poiché non è fattibile per i professionisti della sicurezza cercare manualmente i componenti compromessi in ogni SBOM, la NTIA richiede che ogni SBOM supporti l’automazione attraverso uno dei tre formati leggibili da macchina:

• Cyclone DX
• Dati relativi ai pacchetti software ( Exchange , SPDX)
• Etichette di identificazione software (SWID)

[Read also: Here’s your security automation playbook for 2023]

Pratiche e processi
Le pratiche e i processi garantiscono l’accuratezza di un documento SBOM durante l’intero ciclo di vita di un prodotto software. La NTIA delinea diversi elementi minimi da prendere in considerazione, tra cui:

• Frequenza: Ogni volta che un componente software viene aggiornato con una nuova build o versione, è necessario generare una nuova SBOM che rifletta la nuova versione del software. Ciò comprende le build del software volte a integrare un componente o una dipendenza aggiornati. Analogamente, qualora il fornitore intenda correggere un errore o aggiornare le informazioni contenute nei dati SBOM esistenti, dovrà emettere una nuova SBOM revisionata.
• Approfondimento: Uno SBOM dovrebbe includere tutti i componenti di primo livello ed elencarne le dipendenze.
• Inconosciuti noti: A volte gli sviluppatori si rendono conto di non conoscere tutte le relazioni di dipendenza relative a un componente. In tali casi, l’SBOM dovrebbe indicare chiaramente che i dati sono incompleti e spiegare dove potrebbero sussistere delle relazioni.

[Leggi anche: Avete valutato i vostri “ignoti noti”?] Ottimo, ma non si fermi qui: per i leader è utile immaginare anche le “incognite sconosciute”]

• Distribuzione e consegna: Gli SBOM devono essere messi a disposizione di coloro che ne hanno bisogno in modo tempestivo e che dispongono delle autorizzazioni di accesso e dei ruoli appropriati.
• Controllo degli accessi: Le organizzazioni che intendono mantenere riservati i dati SBOM devono specificare i termini, comprese le deroghe e le agevolazioni concesse agli utenti per l’integrazione dei dati SBOM nei propri strumenti di sicurezza.
• Gestione degli errori: Poiché la gestione dei dati SBOM è una pratica in continua evoluzione, gli utenti dovrebbero mostrare tolleranza nei confronti degli errori accidentali. I fornitori dovrebbero fornire dati aggiornati man mano che vengono individuati problemi nelle SBOM precedenti, e gli utenti dovrebbero accogliere con favore tali aggiornamenti e correzioni senza incorrere in sanzioni, al fine di incoraggiare un miglioramento continuo.

È probabile che i requisiti relativi alla SBOM continuino ad aumentare e ad evolversi. Le linee guida aggiornate potrebbero prevedere l’aggiunta di ulteriori campi di dati, nonché l’inserimento di punteggi di sicurezza, elenchi di vulnerabilità e altre informazioni. Sebbene le organizzazioni siano tenute solo a soddisfare i requisiti minimi previsti per un SBOM, l’inserimento di ulteriori informazioni rilevanti relative a un prodotto software dimostrerà un forte impegno nei confronti della trasparenza e della sicurezza.

In cosa consiste il ciclo di vita dello sviluppo dell’SBOM?

Idealmente, gli SBOM dovrebbero essere generati automaticamente ogni volta che viene distribuito un software e includere un inventario il più completo possibile. Il ciclo di vita dell’SBOM contribuisce a facilitare tale processo, fornendo una procedura per l’identificazione delle applicazioni, la creazione degli SBOM e la loro messa a disposizione degli utenti finali.

«GliSBOM dovrebbero essere generati automaticamente ogni volta che viene distribuito un software e includere un inventario il più completo possibile.”

Si articola nelle seguenti cinque fasi:

• Asset discovery—Il primo passo consiste nell’individuare l’applicazione per la quale è necessario fornire un SBOM. Si consiglia di utilizzare uno strumento di individuazione delle risorse , in particolare , per garantire una visibilità completa su tutte le vostre applicazioni.
• Analisi dei dati dell’applicazione —Vengono raccolti i dati dell’applicazione necessari per la SBOM.
• Creazione dell'SBOM —Viene creato il file SBOM, che include tutti i dati rilevanti relativi all'applicazione. Tale operazione dovrebbe essere eseguita ogni volta che viene rilasciata una nuova versione dell’ App , al fine di garantire che l’SBOM corrisponda sempre allo stato attuale del software.
• Archiviazione degli SBOM —Gli SBOM devono essere archiviati in modo centralizzato e sicuro mediante crittografia.
• Ricercabilità dell’SBOM —La fase finale consiste nel garantire la funzionalità di ricerca dell’SBOM, in modo che l’utente finale possa individuare eventuali vulnerabilità.

Quali sono gli standard relativi agli SBOM?

Uno standard SBOM è uno schema che consente di descrivere in dettaglio la composizione di un software in un file leggibile da un computer, che può essere utilizzato da altri strumenti quali scanner di vulnerabilità e sistemi di tracciamento delle licenze software. Attualmente esistono tre standard principali per la generazione degli SBOM e la loro condivisione con gli utenti finali:

• SPDX —Lo standard SPDX (Software Package Data Exchange), sviluppato dalla Fondazione Linux , è un formato ampiamente adottato per la comunicazione dei dati SBOM, quali i componenti di un’ App, le licenze, i diritti d’autore e le informazioni sulla sicurezza, in diversi formati di file.
• CycloneDX —CycloneDX è un altro standard aperto, sviluppato dall’OWASP Community. Si basa sullo standard SPDX, ma è stato semplificato per facilitarne l'implementazione e l'utilizzo
• SWID —Gli SWID, acronimo di Software Identification Tags, sono un tipo di metadati che possono essere generati automaticamente da numerose applicazioni per descrivere e contestualizzare i componenti del software.

La NTIA ha ritenuto accettabili questi tre standard SBOM poiché, oltre ad essere leggibili dall’uomo, sono anche leggibili da sistemi automatizzati e possono supportare l’automazione, facilitando così agli utenti finali l’utilizzo e la diffusione degli SBOM all’interno della propria organizzazione.

[Leggi anche: Il futuro della gestione del rischio ruota interamente attorno all’automazione]

Quali sono le sfide legate alla creazione e all’utilizzo di una SBOM?

Come per qualsiasi nuovo sistema, la creazione e l’utilizzo di una SBOM comportano alcune difficoltà.

Uno degli ostacoli principali è la mancanza di standardizzazione. È probabile che gli SBOM risultino più efficaci quando l’intera catena di fornitura adotta gli stessi standard, processi e strumenti. Tuttavia, in questa fase iniziale vi è scarso consenso su ciascuno di questi aspetti, e la mancanza di uniformità tra i fornitori di software e gli utenti finali è inevitabile. Ciò può comportare un dispendio di tempo aggiuntivo per l’analisi e l’adeguamento degli SBOM in base alle esigenze.

“Gli SBOM risultano probabilmente più efficaci quando l’intera catena di fornitura aderisce agli stessi standard, processi e strumenti. Tuttavia, in questa fase iniziale, non vi è un ampio consenso su nessuno di questi aspetti.”

Un’altra sfida è rappresentata dalla necessità di adeguare costantemente gli SBOM. Ogni volta che viene rilasciata una nuova versione di un’ App, questa deve includere una nuova SBOM che rifletta lo stato attuale dell’ App. Ciò rende fondamentale l’adozione di strumenti di gestione degli SBOM in grado di integrare la generazione degli SBOM nel ciclo di vita dello sviluppo del software.

Anche l’adeguamento degli SBOM man mano che si aggiungono nuovi partner alla catena di fornitura può rappresentare un problema se si utilizzano metodi tradizionali per generarli, quali fogli di calcolo ed e-mail. Inoltre, tali metodi manuali richiedono molto tempo, sono soggetti a errori e possono rendere difficile tracciare le relazioni gerarchiche tra i componenti.

Quali sono alcune delle migliori pratiche per la creazione di una SBOM efficace?

Le seguenti buone pratiche possono aiutarLa a creare SBOM efficaci:

• Utilizzi un formato coerente:È importante attenersi a un formato standard nella strutturazione dei dati SBOM. SPDX, CycloneDX e SWID sono i formati più diffusi, ma in definitiva la scelta del formato è meno importante rispetto al suo utilizzo coerente.
• Automatizzare la creazione degli SBOM —La generazione automatica degli SBOM nell’ambito della vostra pipeline di distribuzione del software offre numerosi vantaggi. Innanzitutto, consentirà agli sviluppatori di risparmiare tempo, poiché non dovranno creare manualmente ogni SBOM. Inoltre, ciò aumenta la probabilità che gli SBOM diventino una parte integrante del vostro ciclo di distribuzione del software. Infine, consente di soddisfare i requisiti stabiliti dal decreto esecutivo di Biden per la fornitura di servizi informatici al governo federale.
• Aggiornare gli SBOM ad ogni versione —Uno SBOM deve essere specifico per ogni versione del software, anche ogni volta che un’applicazione viene aggiornata. L’automazione è fondamentale in questo contesto; se gli sviluppatori dovessero aggiornare manualmente la propria SBOM a ogni aggiornamento di App , è molto meno probabile che ciò avvenga.
• Includere metadati completi —Sebbene non esistano standard universali per gli SBOM, è opportuno adottare la prassi di includere il maggior numero possibile di metadati in ogni SBOM. Ciò ridurrà la quantità di informazioni che i Suoi utenti finali dovranno cercare manualmente e dimostrerà il Suo impegno in materia di sicurezza e trasparenza. Inoltre, rende più agevole l'aggiornamento.

Altre risorse

• Che cos’è la sicurezza della catena di fornitura del software?
• La gestione dell’ Risk e della catena di fornitura del software inizia con la visibilità
• La sicurezza della catena di approvvigionamento è una sfida ardua. Allora, come dovrebbe presentarsi una soluzione ottimale?