Che cos'è una distinta base del software (SBOM)?

La SBOM aiuta a migliorare la visibilità delle catene di fornitura elencando i componenti coinvolti in questi processi. Pertanto, per elaborare una strategia di gestione dei rischi della catena di fornitura del software, è necessario comprendere la SBOM.

In questo periodo dell'anno scorso, nel 2023, la Security and Exchange Commission ha pubblicato un comunicato stampa relativo a una causa contro una società di software con sede ad Austin, in Texas. La causa ha fatto eco a una preoccupazione che ha lasciato perplesse le società di software di tutto il mondo: la sicurezza della catena di fornitura del software. I cyber attori delle minacce prendono di mira da tempo le catene di fornitura del software, sfruttando vulnerabilità come quella del framework Log4j per installare malware.

Questa crescente preoccupazione per la sicurezza della catena di fornitura è uno dei motivi principali per cui la Software Bill Of Materials (SBOM) sta trovando spazio nelle normative amministrative ufficiali per la sicurezza informatica. Le catene di fornitura del software sono spesso complesse e coinvolgono molteplici processi. La SBOM aiuta a migliorare la visibilità delle catene di fornitura elencando i diversi componenti e le dipendenze con cui questi processi interagiscono direttamente. Pertanto, per elaborare in modo efficiente una strategia di gestione dei rischi della catena di fornitura del software, è necessario comprendere la SBOM e il suo ambito di applicazione.

Introduzione alla SBOM (Software Bill of Materials)

Una Software Bill Of Materials (SBOM) è un elenco dettagliato delle varie parti di un software, inclusi i suoi componenti open source, le librerie e le loro relazioni. L'idea è quella di fornire agli stakeholder una comprensione approfondita di tutto ciò che il software comporta, garantendo così la trasparenza nel contesto della sicurezza informatica. Con le trasformazioni nei modi in cui il software viene sviluppato e distribuito, sono emerse complessità che consentono ai cyber-aggressori di inventare modi creativi per agire. SBOM, quindi, è una rete di sicurezza essenziale che consente una maggiore visibilità delle nostre applicazioni.

Perché SBOM è essenziale per la sicurezza informatica?

Quando il presidente Biden ha sottolineato l'importanza dell'SBOM nel suo ordine esecutivo relativo al miglioramento della sicurezza informatica, era consapevole delle vulnerabilità della catena di fornitura che sono bersaglio di campagne dannose. Un elenco nidificato come SBOM essenzialmente scompone il software nei suoi ingredienti e aiuta a identificare queste vulnerabilità. Ecco tre motivi che rendono SBOM essenziale per la sicurezza informatica:

• Trasparenza nel software: SBOM aiuta le parti interessate a identificare se nel software sono presenti componenti obsoleti o a rischio. Se, ad esempio, è presente una libreria di crittografia obsoleta o un framework di registrazione come Log4j, gli esperti di sicurezza possono facilmente identificare il rischio associato.
• Tracciamento dei componenti open source: Molte soluzioni software moderne incoraggiano l'integrazione di componenti e librerie open source. Questi potrebbero non essere sempre controllati dal punto di vista della sicurezza e SBOM, quindi, aiuta a monitorarli per i loro potenziali rischi.
• Valutazione delle dipendenze: Sebbene alcuni componenti possano non rappresentare visibilmente alcuna minaccia alla sicurezza informatica, la loro dipendenza da altri componenti o librerie potrebbe farlo. Pertanto, SBOM aiuta anche gli esperti di sicurezza a esaminare queste dipendenze e a identificare eventuali lacune di sicurezza.
• Sicurezza della catena di fornitura: La trasparenza all'interno della relativa alla sicurezza dei vari componenti software contribuisce a garantire strategie di sicurezza proattive contro potenziali sfruttamenti. SBOM offre agli acquirenti tutte le informazioni necessarie che possono consentire queste strategie per la sicurezza della catena di approvvigionamento.
• Gestione della conformità: SBOM aiuta anche le parti interessate a valutare le soluzioni software e i loro componenti per la conformità normativa. Con normative rigorose in tutti i settori, tra cui sanità, fintech, difesa e altri, è possibile rilevare facilmente qualsiasi mancata conformità da parte di qualsiasi componente software.

Componenti chiave di un SBOM (Software Bill of Materials)

Il rapporto della NTIA’s, in conformità con l'ordine esecutivo del Presidente, ha suggerito tre componenti interconnessi in un SBOM che sono ritenuti in grado di offrire la trasparenza richiesta nel software. Questi "elementi minimi" possono fornire una visione dettagliata della tecnologia e del progetto funzionale del software, rendendolo visibile per una valutazione approfondita della sicurezza.

• Campi dati: Questo elemento verifica i dettagli relativi ai componenti software in una struttura SBOM formale. I campi dati includono il nome del fornitore, la versione del componente e la relazione di dipendenza, tra gli altri, per aiutare a tracciare potenziali vulnerabilità di sicurezza.

• Supporto all'automazione: I supporti di automazione offrono i formati di dati richiesti che consentono una facile navigazione dei dati SBOM e la leggibilità automatica dei componenti software. Si tratta di un elemento essenziale per garantire un controllo più rapido e autonomo del software. CycloneDX,  SPDX e SWID sono i tre formati accettabili secondo il rapporto.

• Processi: Si tratta delle pratiche necessarie che aiuterebbero a integrare la generazione e la gestione degli SBOM nel ciclo di vita dello sviluppo sicuro del software. Queste pratiche determinano vari aspetti dell'SBOM, tra cui la frequenza di generazione, i componenti di profondità e le dipendenze incluse, nonché le dipendenze note/sconosciute.

Vantaggi dell'implementazione dell'SBOM (Software Bill of Materials)

A survey nel 2022 suggerisce che il 53% delle aziende di tutti i settori ritiene che le SBOM siano uno strumento utile per la rendicontazione e la conformità. Un'accoglienza così positiva delle SBOM può essere attribuita solo all'attenzione intrinseca ai dettagli che queste distinte offrono. È proprio questa attenzione ai dettagli che, a sua volta, porta a numerosi vantaggi offerti dagli SBOM:

• Trasparenza lungo tutta la catena di fornitura: I campi di dati e le relazioni indicati dagli SBOM aiutano a fornire una panoramica dettagliata dell'intera catena di fornitura del software. Le diverse versioni dei componenti software, le loro dipendenze e compatibilità all'interno del software e i loro rischi per la sicurezza possono essere facilmente identificati e analizzati.
• Posizione di sicurezza coerente: Anche per i software acquistati nonostante i potenziali rischi suggeriti dalla loro SBOM, gli amministratori della sicurezza possono essere meglio preparati ad affrontare eventuali vulnerabilità. È possibile adottare misure proattive basate sulla SBOM per mitigare eventuali rischi per la sicurezza.
• Gestione della conformità: Sebbene la SBOM sia di per sé un obbligo normativo, essa aiuta anche le parti interessate ad aderire alla rigorosa conformità alle normative previste per determinati componenti del software. Inoltre, con audit regolari, la SBOM può anche aiutare a identificare eventuali deviazioni nella conformità.
• Minacce di terze parti: Qualsiasi rischio per la sicurezza rappresentato dai componenti open source di terze parti nel software può essere facilmente monitorato con l'aiuto di SBOM. Anche se il fornitore trascura consapevolmente o inconsapevolmente una vulnerabilità di sicurezza, SBOM può aiutare a risalire al componente di terze parti responsabile.

Come creare e gestire un SBOM?

Esistono strumenti disponibili per creare un SBOM con tutti i suoi elementi necessari. Tali strumenti svolgono la funzione essenziale di tradurre la loro analisi dei componenti software in uno qualsiasi degli standard SBOM desiderati, come SPDX, CycloneDX e altri. Questi strumenti di generazione SBOM possono anche aiutare le parti interessate a tracciare eventuali dipendenze obsolete, licenze e altri aspetti simili che possono portare a vulnerabilità di sicurezza. Ecco come funzionano questi strumenti:

• Fase 1 – Integrazione dello strumento SBOM nella pipeline CI/CD: Per registrare i vari componenti del codice software, gli strumenti SBOM devono essere integrati nella pipeline CI/CD. Questi strumenti possono essere installati in loco o in un ambiente cloud, a seconda delle esigenze.
• Fase 2 – Scansione del repository del codice: Successivamente, lo strumento esegue la scansione del codice per identificare i diversi componenti, le librerie, i framework open source e altro ancora presenti nel software.
• Fase 3 – Traduzione dell'analisi del codice: Una volta che il codice base è stato scansionato per tutti i componenti e le dipendenze, i dati vengono tradotti in uno dei formati SBOM standard desiderati.
• Fase 4 – Generazione di SBOM: I dati SBOM tradotti possono infine essere esportati in formato XML o JSON per un'ulteriore revisione. La NTIA richiede la generazione di un nuovo SBOM ogni volta che viene effettuato un aggiornamento del componente software.

Standard e linee guida SBOM

Gli standard e le linee guida per la generazione di SBOM aiutano a mantenere l'uniformità nella struttura SBOM, coprendo al contempo tutte le basi nell'elenco nidificato di componenti software, librerie e altro ancora. Queste linee guida sono necessarie anche per incoraggiare la generazione e l'elaborazione automatizzata di SBOM.

• System Package Data Exchange (SPDX): Questo standard aperto può aiutare a creare un linguaggio leggibile che può essere tradotto in formati di file come XML, JSON, YAML e altro ancora. Lo standard può delineare in modo efficiente i diversi componenti software durante lo sviluppo e l'implementazione, raccogliendo dati sotto forma di informazioni sulla creazione, informazioni sui file, informazioni sui pacchetti e altro ancora.
• CycloneDX: Questo formato è stato rilasciato con un'attenzione particolare alla sicurezza e alla generazione automatizzata di SBOM. Le specifiche leggere possono garantire un'analisi approfondita dei componenti software, della loro interazione con i servizi esterni e delle relazioni tra di essi. Lo standard open source si adatta bene anche ai componenti open source dinamici che vengono modificati e ridistribuiti regolarmente.
• Software Identification Tags (SWID Tags): Istituiti dall'ISO nel 2012, i tag SWID hanno lo scopo di tracciare il componente software durante il suo ciclo di vita. Questi tag, ovvero primario, patch, corpus e supplementare, vengono aggiunti una volta installato il software per fornire dettagli sull'installatore, l'installazione, le patch e altri aspetti di un componente software.

Sfide SBOM (Software Bill of Materials)

Le sfide relative alla SBOM riguardano principalmente la parte relativa alla generazione, data la sua natura profondamente strutturata e formale. Ecco come si manifestano queste sfide:

• Maturità degli strumenti SBOM: Sebbene gli strumenti siano in continua evoluzione per conformarsi ai formati e alle strutture SBOM standardizzati, esistono ancora alcune lacune. Inoltre, l'utilizzo di questi strumenti è anche una seccatura che i diversi stakeholder trovano difficile da gestire, data la mancanza di interfacce adeguate, interfacce e interoperabilità, tra gli altri fattori.
• Lenta adozione e integrazione: Ci sono ancora fornitori terzi che non rispettano il mandato SBOM, il che comporta un ritardo nell'adozione e nell'integrazione delle risorse SBOM, in particolare con il software open source.
• Continuità nella generazione di SBOM: Le aziende non sono ancora riuscite a rendere la generazione di SBOM un processo continuo, in modo che avvenga in diverse fasi dell'SDLC. Sebbene sia un obiettivo ambizioso per la maggior parte delle aziende che si occupano di SBOM, molte di esse non lo hanno ancora raggiunto.
• Ulteriori preoccupazioni relative alla sicurezza: Alcuni esperti di sicurezza sostengono inoltre che una gestione generica delle vulnerabilità non sia in grado di proteggere gli ecosistemi digitali dalle minacce esterne. Le organizzazioni devono stabilire quali vulnerabilità affrontare in via prioritaria e definire una strategia di conseguenza. Si tratta di un'impresa difficile da realizzare quando si lavora con gli SBOM, a causa della maggiore complessità.

Best practice per garantire un utilizzo efficace delle SBOM

La generazione delle SBOM è già una buona pratica. La best practice sarebbe quella di generarle in modo coerente e durante tutto il ciclo di vita dello sviluppo del software (SDLC). Ecco alcune altre pratiche che possono rendere possibile tutto ciò e massimizzare l'utilità delle SBOM per la sicurezza della catena di fornitura:

• Generare tempestivamente e aggiornare regolarmente: È essenziale che gli SBOM siano generati il più presto possibile nel ciclo di vita dello sviluppo del software (SDLC), in modo che ogni dipendenza aggiunta possa essere registrata sin dall'inizio. Gli aggiornamenti regolari degli SBOM garantiranno che tutte le build e le versioni dei vari componenti software siano debitamente annotate nella distinta.
• Generazione automatizzata di SBOM: Poiché il supporto all'automazione è una parte essenziale degli SBOM, è logico disporre di risorse di automazione per la loro generazione. L'automazione garantirebbe inoltre la generazione regolare di fatture attraverso l'SDLC.
• Formati standardizzati: Formati come SPDX o CycloneDX hanno la profondità necessaria per acquisire realmente i dati SBOM sensibili dal punto di vista della sicurezza. L'utilizzo di tali formati standardizzati garantirebbe l'interoperabilità e la leggibilità automatica della fattura.
• Controllo delle versioni: Il controllo delle versioni negli SBOM garantirà che qualsiasi nuova modifica apportata o rilasciata nel componente software possa essere facilmente tracciata per la valutazione della sicurezza. Ciò rende anche l'SBOM più affidabile nella gestione delle dipendenze.

Casi d'uso degli SBOM

Sebbene la sua utilità principale sia quella di fornire informazioni critiche sulla vulnerabilità del software, gli SBOM possono soddisfare molti casi d'uso, tra cui:

• Sicurezza del software: Gli SBOM possono aiutare i team di sicurezza a identificare con precisione le parti vulnerabili del codice software. I team possono utilizzarli per individuare e risolvere eventuali parti del software soggette ad attacchi informatici.

• Sicurezza della catena di fornitura: Molte istituzioni governative, tra cui gli Stati Uniti e alcuni governi europei, hanno reso obbligatoria l'inclusione degli SBOM nelle catene di fornitura del software. Gli esperti prevedono che presto potrebbero essere disponibili anche per i clienti finali.

• Facilità di approvvigionamento: Con le aziende di tutti i settori preoccupate per gli incidenti di sicurezza informatica, gli SBOM ispirano un senso di fiducia nei team di approvvigionamento alla ricerca di una soluzione software. La trasparenza offerta ha contribuito a creare fiducia tra le due parti.

• Facilità di sviluppo: Poiché gli SBOM contengono un'analisi dettagliata delle dipendenze e delle relazioni tra i componenti software, è più facile per gli sviluppatori lavorare su nuovi componenti senza interrompere il funzionamento precedente.

Differenze tra SBOM e SCA

Sicuramente, la Software Bill of Materials (SBOM) e la Software Composition Analysis (SCA) hanno caratteristiche sovrapposte che possono aiutare a comprendere i diversi componenti del software. Pertanto, una scelta informata tra le due dipende dall'ambito del ciclo di vita del software per il quale si desidera utilizzarle.

Ecco cosa devono sapere i leader aziendali per fare questa scelta:

Aspetto	SBOM	SCA
Focus	Focus dedicato alla registrazione di componenti software eterogenei e alla generazione di un elenco dettagliato.	L'attenzione è rivolta alla gestione e all'analisi dei componenti per individuare eventuali vulnerabilità.
Offerte	Offre un inventario gerarchico di componenti, librerie e dipendenze	Offre l'identificazione e la correzione delle vulnerabilità di sicurezza dovute a componenti a rischio.
Utilità	L'ambito di utilità è più ampio e copre sviluppatori, team di sicurezza, team di approvvigionamento, ecc.	Limitata principalmente ai team di sicurezza che necessitano di strumenti SCA per affrontare i componenti vulnerabili.

Differenze tra BOM e SBOM

BOM e SBOM sembrano così simili nella loro natura che spesso si può fare confusione tra l'uno e l'altro. Tuttavia, entrambi appartengono a domini molto distinti. Mentre la BOM è un inventario più rilevante per il settore manifatturiero, la SBOM ha un ruolo molto specifico nell'ingegneria del software. Ecco come i responsabili delle decisioni possono distinguere le due cose:

Aspetto	Distinta base (BOM)	Distinta base software (SBOM)
Applicazione	Più applicabile a prodotti fisici come hardware o elettronica.	Applicazione dedicata ai prodotti software e alle loro catene di fornitura.
Conformità	Conformità incentrata sulle normative di produzione o costruzione.	Conformità incentrata su licenze software, esigenze di sicurezza, ecc.
Utenti	Produttori, responsabili della catena di approvvigionamento.	Sviluppatori, team di sicurezza e revisori normativi.

Conclusione

Essendo parte integrante delle normative amministrative in materia di sicurezza informatica, l'SBOM occupa già un posto fondamentale nel ciclo di vita del software. La sicurezza delle catene di fornitura del software è uno dei vari casi d'uso a cui può servire. Con architetture distribuite, infrastrutture codificate e reti diffuse, le soluzioni software stanno ora servendo casi d'uso aziendali più complessi che mai. I componenti chiave e i formati standard di SBOM lo rendono un potente alleato nel contenere incidenti come quelli di Uber e Solarwinds.

Sulla base della discussione in questo blog, i leader aziendali e gli esperti di sicurezza possono seguire le migliori pratiche per automatizzare la generazione di SBOM e sfruttarle per la sicurezza della catena di fornitura.

SentinelOne può aiutarti a utilizzare funzionalità come SBOM per proteggere la tua catena di fornitura software. Scopri di più sulla nostra esperienza qui.

"

FAQs

Che cos'è un SBOM e perché è importante?

Una distinta dei materiali software, o SBOM, è una ripartizione dettagliata dei vari componenti software, librerie, dipendenze e altro ancora sotto forma di elenco gerarchico. È importante garantire la visibilità delle parti del codice software soggette a rischi, che potrebbero essere sfruttate per attacchi informatici.

In che modo una SBOM migliora la sicurezza della catena di fornitura del software?

Grazie alla profonda visibilità offerta dalla SBOM, è più facile per gli esperti di sicurezza individuare potenziali vulnerabilità nella catena di fornitura del software e risolverle in modo efficace.

Quali sono i componenti chiave di un SBOM?

In base alle normative amministrative, gli elementi chiave di SBOM includono campi dati, pratiche e processi e supporto all'automazione.

In che modo le organizzazioni possono implementare una strategia SBOM efficace?

Per una strategia SBOM efficace, è essenziale seguire le migliori pratiche come la generazione precoce, gli aggiornamenti regolari, la generazione automatizzata e l'integrazione con le pipeline CI/CD.

Quali standard devono essere seguiti nella creazione di un SBOM?

I tre standard che funzionano meglio con SBOM sono SPDX, CycloneDC e SWID Tags.

Come posso ottenere una distinta dei materiali software?

Per generare una distinta dei materiali software è possibile utilizzare strumenti di automazione che aiutano a ottenere i formati e i risultati richiesti. Gli esperti di SentinelOne possono fornire assistenza in tal senso.