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

Una distinta base del software (SBOM) è un elenco dettagliato e completo di tutti i componenti all'interno di un'applicazione software, incluso l'uso di software open source, le dipendenze dei componenti, le licenze e le vulnerabilità note. Le SBOM forniscono un inventario di ogni singolo componente che comprende l'applicazione, proprio come un elenco di ingredienti in una ricetta. Le SBOM hanno iniziato a guadagnare terreno nel 2018 come sforzo collaborativo della comunità della sicurezza informatica e negli ultimi anni sono state in gran parte guidate dalla National Telecommunications and Information Administration (NTIA) e dal governo degli Stati Uniti.

Le SBOM sono documenti molto importanti che forniscono informazioni critiche per le organizzazioni che cercano di minimizzare e ridurre i rischi operativi, legali e della catena di fornitura del software, ma molte organizzazioni devono ancora affrontare sfide nell'implementazione delle SBOM nei loro processi esistenti o non sono consapevoli dei loro vantaggi. Questo articolo esaminerà in che modo le SBOM possono aiutare le organizzazioni a essere meglio informate sul software che utilizzano e perché le SBOM dovrebbero essere adottate come best practice.

Scopri come UpGuard aiuta le aziende a ottenere una migliore visibilità delle vulnerabilità del loro software >

Perché le SBOM sono importanti?

Poiché l'azienda media utilizza fino a 130 applicazioni SaaS nelle operazioni quotidiane e le aziende più grandi possono utilizzare oltre 200 applicazioni al giorno, le SBOM diventano ancora più essenziali per ridurre i rischi per la sicurezza. Più applicazioni un'organizzazione utilizza quotidianamente, maggiore è l'esposizione al rischio che l'organizzazione deve affrontare. Se una singola applicazione o componente dovesse essere violato a causa di una vulnerabilità, potrebbe potenzialmente compromettere l'intera catena di fornitura del software.

Le SBOM aiutano le organizzazioni a identificare i rischi operativi e di sicurezza associati a determinati software, nonché a ottenere ulteriore visibilità sulla composizione del software. Le organizzazioni possono gestire meglio le vulnerabilità, rispettare le licenze ed eseguire altre importanti attività di gestione del software sapendo esattamente cosa c'è all'interno di un prodotto software. Le SBOM stanno diventando uno strumento sempre più importante nel mondo della sicurezza informatica, dei cicli di vita dello sviluppo software (SDLC) e dei processi DevSecOps.

Nel maggio 2021, il governo federale degli Stati Uniti ha emesso l'ordine esecutivo 14028, che richiede a tutte le agenzie governative degli Stati Uniti di trattare solo con i fornitori di software che forniscono SBOM. Questa nuova legge fa parte del più ampio sforzo di sicurezza informatica per proteggere l'infrastruttura digitale della nazione e spingere più fornitori di software a garantire che i prodotti siano costruiti in modo sicuro. L'EO 14028 incentiva inoltre i fornitori a soddisfare gli standard federali di sicurezza informatica, poiché i contratti governativi sono opportunità potenzialmente redditizie.

Le applicazioni e i servizi software moderni sono costruiti con diversi componenti e dipendenze provenienti da più fonti. Tali componenti e dipendenze possono includere software open source, codice proprietario, API personalizzate, framework di linguaggi di programmazione e librerie software. L'insieme delle fonti che compongono le applicazioni software sono considerate parte della catena di fornitura del software.

Una distinta base software differisce dai metadati software in quanto i metadati software possono fornire maggiori informazioni sull'uso e lo scopo più ampi dell'applicazione, mentre le SBOM si concentrano sui singoli componenti all'interno dell'applicazione e sulle loro dipendenze.

Le organizzazioni si affidano alle loro SBOM anche per affrontare:

Conformità legale
Prestazioni di sicurezza informatica
Gestione del rischio
Risposta agli incidenti
Efficienza operativa
Gestione delle vulnerabilità

Cosa includono le SBOM?

La National Telecommunications and Information Administration (NTIA) ha pubblicato una guida che descrive in dettaglio gli elementi minimi per una SBOM, comprese le seguenti aree fondamentali:

Nomi e versioni dei componenti: ogni componente software deve essere identificato ed elencato, inclusi nome, numero di versione, informazioni sulla licenza, nome del fornitore, autore e un timestamp per la generazione dei dati SBOM. Queste informazioni consentono alle organizzazioni di assicurarsi di utilizzare le versioni più recenti e sicure di ciascun componente. Se un componente o un sottocomponente viene aggiornato, la distinta base SBOM deve essere aggiornata e riemessa.
Dipendenze software: la SBOM deve includere l'albero delle dipendenze tra i componenti software, comprese le dipendenze transitive, per mantenere la funzionalità del software e supportare pratiche efficienti di gestione delle dipendenze. Se una dipendenza viene modificata o un componente diventa obsoleto, la distinta base di progettazione orizzontale deve essere aggiornata per riflettere tali modifiche.
Automazione: la NTIA raccomanda livelli minimi di automazione per la generazione di SBOM e il trasferimento dei dati in modo che altri sistemi possano comprendere e utilizzare i dati SBOM generati. Poiché le applicazioni software possono essere estremamente complesse, la NTIA sconsiglia vivamente di generare una SBOM utilizzando processi manuali.
Processi: le SBOM richiedono processi di raccolta dati continui che definiscono le modalità di generazione delle SBOM, le modalità di accesso e chi ha l'autorizzazione per accedervi.
Licenze software open source: se il software utilizza licenze software open source, è importante documentare il tipo di licenza di ciascun componente, nonché i termini e le condizioni, per evitare problemi legali. Le organizzazioni possono assicurarsi di aderire ai termini e alle condizioni stabiliti dai creatori del componente tenendo traccia di tutte le licenze. Inoltre, i dati sulle licenze consentono alle organizzazioni di tenere traccia delle vulnerabilità o degli exploit del codice open source e di porvi rimedio prima che possano provocare una violazione informatica.
Vulnerabilità note: l'elenco delle vulnerabilità di sicurezza note per ogni componente aiuta le organizzazioni a mitigare i potenziali rischi e a migliorare la sicurezza complessiva del software. Queste informazioni consentono ai team IT di assegnare priorità agli aggiornamenti e alle patch per mantenere un ambiente software sicuro.

Formati SBOM standard

Esistono alcuni formati standard per la creazione e la condivisione di SBOM. I formati standardizzati garantiscono la coerenza dei dati SBOM lungo tutta la catena di fornitura del software, promuovendo la piena trasparenza e la collaborazione tra le diverse parti interessate. I formati SBOM più comunemente utilizzati oggi includono:

CycloneDX, sviluppato dall'Open Web Application Security Project (OWASP)
Software Identification Tags (SWID), sviluppato dal NIST

Software Package Data Exchange (SPDX), sviluppato da ISO/IEC secondo ISO/IEC 5962

Vantaggi dell'implementazione delle SBOM

L'implementazione delle SBOM può essere un processo difficile, ma può fornire molti vantaggi che possono aiutare le organizzazioni a mantenere meglio la propria sicurezza e ridurre al minimo i rischi a lungo termine, tra cui:

Posizioni di sicurezza migliorate: le SBOM forniscono ulteriore profondità e visibilità sui componenti software, aiutando le organizzazioni a identificare, monitorare e correggere le vulnerabilità note.
Conformità delle licenze: le SBOM aiutano le organizzazioni a soddisfare i requisiti di licenza tenendo traccia di tutti i componenti proprietari e open source in uso. Queste informazioni sulle licenze aiutano anche le organizzazioni a soddisfare i requisiti legali e gli standard normativi.
Trasparenza della catena di approvvigionamento: la creazione di trasparenza del software è particolarmente importante per le organizzazioni che iniziano a scalare. Comprendere l'origine di ciascun prodotto software consente alle organizzazioni di valutare correttamente l'affidabilità e la sicurezza di ciascun componente.
Audit efficienti del software: gli audit del software devono essere eseguiti regolarmente per valutare la conformità, l'efficacia, la criticità e la necessità del prodotto. Le SBOM aiutano a facilitare questo processo fornendo un elenco completo di ogni componente utilizzato, risparmiando tempo e risorse necessarie per completare l'audit.
Gestione efficace dei rischi e delle vulnerabilità: il monitoraggio di ogni componente utilizzato all'interno delle applicazioni software consente alle aziende di identificare i potenziali rischi e mitigarli o risolverli prima che possano essere sfruttati.

Sfide per l'implementazione delle SBOM

Sebbene le SBOM possano aiutare l'ecosistema IT di un'azienda a rimanere organizzato, molti processi sono ancora in fase di standardizzazione e definizione. Poiché la creazione e l'uso delle SBOM sono ancora varie, le organizzazioni possono riscontrare alcune sfide e inefficienze iniziali, come ad esempio:

Processi di implementazione e manutenzione complessi: le aziende più grandi che utilizzano un'ampia varietà e numero di prodotti software e basi di codice possono affrontare sfide significative nell'acquisizione di SBOM per ogni applicazione. A loro volta, i fornitori di software hanno anche il compito di lavorare ulteriormente durante la generazione delle SBOM, soprattutto quando il software viene aggiornato. I prodotti software che vengono aggiornati frequentemente significano che anche le SBOM devono essere aggiornate frequentemente.
Mancanza di standardizzazione: poiché le SBOM sono ancora una pratica relativamente nuova, ci sono ancora problemi di standardizzazione, che possono portare a incongruenze tra i formati e problemi di compatibilità tra i tipi di strumenti e piattaforme utilizzati durante la generazione dei dati.
Forte intensità di risorse: la grande quantità di lavoro necessaria per generare e mantenere le SBOM significa che i fornitori devono dedicare tempo e risorse significativi all'attività. Inoltre, sarà necessario formare personale speciale all'interno di ogni team di sicurezza, il che può rappresentare una sfida per le organizzazioni più piccole con priorità più elevate. Le organizzazioni che utilizzano il software avranno anche bisogno di team o individui dedicati per rintracciare le SBOM per includerle nei processi di approvvigionamento e auditing.
Sicurezza dei dati SBOM: ogni documento SBOM contiene informazioni critiche sui componenti software, che possono portare a nuove opportunità di violazione sia per il fornitore che per l'organizzazione che utilizza l'applicazione. I dati SBOM devono essere mantenuti riservati e sicuri, con nuovi processi di sicurezza interni che ne definiscono la sicurezza.
Mancanza di capacità di integrazione: poiché le SBOM non sono ancora una pratica comune, l'integrazione dei suoi processi con lo sviluppo e l'implementazione del software esistente potrebbe non essere possibile o può essere estremamente impegnativa. Tuttavia, è possibile ottenere maggiori capacità di integrazione del software man mano che più organizzazioni adottano le SBOM nei loro processi.
Partecipazione dei fornitori: con le organizzazioni che potenzialmente lavorano con centinaia o migliaia di fornitori che forniscono applicazioni software, convincere i fornitori di terze parti ad adottare nuovi processi e produrre SBOM aggiornati e accurati può rivelarsi difficile, soprattutto se non ne vedono i vantaggi o ritengono che il lavoro extra non sia necessario. Inoltre, i fornitori di software potrebbero non voler fornire i dettagli dei componenti se ritengono che stiano rivelando informazioni riservate e proprietarie.