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

I team di sviluppo software hanno iniziato a utilizzare le SBOM oltre un decennio fa per gestire le librerie open source e i repository di terze parti. I problemi di cybersecurity hanno portato le SBOM al centro della scena dopo che importanti attacchi alla supply chain hanno evidenziato i suoi punti deboli critici. Durante la violazione di SolarWinds del 2020, gli aggressori hanno inserito codice dannoso in aggiornamenti software affidabili, colpendo 18.000 organizzazioni, tra cui diverse agenzie governative. Poco dopo, è stata scoperta la vulnerabilità Log4j del 2021, che ha interessato centinaia di milioni di dispositivi in tutto il mondo  e ha ulteriormente evidenziato come i componenti compromessi possono minacciare interi sistemi.

Questi attacchi informatici hanno evidenziato una dura realtà: le organizzazioni, comprese le agenzie governative, non avevano visibilità sui componenti e sulle dipendenze all'interno dei loro sistemi software. Questa mancanza rende difficile valutare i rischi per la cybersecurity e rispondere efficacemente alle minacce. L'urgenza della minaccia ha stimolato un'azione decisiva da parte della Casa Bianca. L'ordine esecutivo 14028 ha imposto le SBOM per tutti gli acquisti federali di software nel maggio 2021.

La National Telecommunications and Information Administration (NTIA) ha stabilito gli elementi minimi per le SBOM  che i fornitori di software devono rispettare quando vendono a enti governativi. Nel settembre 2024, la CISA ha pubblicato un documento intitolato "Framing Software Component Transparency", che amplia questi requisiti minimi e fornisce linee guida più dettagliate sull'implementazione e la gestione delle SBOM in tutto l'ecosistema software.

Questa direttiva federale funge ora da modello per la trasparenza del software in tutti i settori. Ad esempio, nel settore dei servizi finanziari, la versione 4.0 del Payment Card Industry Data Security Standard (PCI DSS) include requisiti per la gestione dell'inventario software per proteggere i sistemi di pagamento e risolvere le vulnerabilità. Nel settore sanitario, la FDA richiede le SBOM per i dispositivi medici, mentre l'International Medical Device Regulators Forum (IMDRF) ne raccomanda l'uso per salvaguardare i dispositivi medici e i sistemi di dati dei pazienti.

Queste linee guida e raccomandazioni del settore riflettono un più ampio passaggio verso l'adozione delle SBOM in tutto il settore privato. Gartner prevede che entro il 2025il 60% delle organizzazioni che realizzano o acquistano software per infrastrutture critiche imporrà le SBOM, rispetto a meno del 20% nel 2022. Questa adozione è dettata dalla necessità: alcune analisi recenti mostrano che oltre il 90% delle moderne applicazioni software contiene dipendenze open source, il 74% delle quali contiene dipendenze ad alto rischio. Le organizzazioni utilizzano sempre più le SBOM per soddisfare i requisiti di conformità, convalidare i componenti e affrontare le vulnerabilità di sicurezza non appena vengono scoperte.

Come le etichette degli alimenti che descrivono in dettaglio gli ingredienti e le loro fonti, le SBOM forniscono una documentazione strutturata dei componenti software, dei loro fornitori e delle relazioni tra le dipendenze.

I requisiti SBOM si sono evoluti in modo significativo dalla loro introduzione nell'Ordine Esecutivo 14028 (2021). Quelli che erano iniziati come requisiti minimi dell'NTIA si sono ampliati grazie all'adozione da parte del settore e al perfezionamento normativo. L'attuale framework, pubblicato dalla CISA nel settembre 2024, si basa su queste basi con linee guida migliorate per un'implementazione più ampia.

Le organizzazioni devono affrontare requisiti SBOM diversi a seconda del loro settore e dei loro rapporti con il governo federale. Gli appaltatori governativi, i fornitori di infrastrutture critiche e le organizzazioni dei settori regolamentati devono rispettare requisiti SBOM specifici. Mentre il governo impone l'adozione della SBOM ai suoi fornitori, le organizzazioni al di fuori dei contratti governativi possono adottarla su base volontaria volontaria, anche se l'implementazione delle pratiche SBOM è diventata sempre più importante per la sicurezza della supply chain e la fiducia dei clienti.

Il framework 2024 della CISA introduce un modello di maturità a tre livelli che aiuta le organizzazioni a migliorare progressivamente le loro pratiche SBOM:

• Minimo previsto: elementi essenziali richiesti per la funzionalità e la conformità di base della SBOM
  
  
• Procedura consigliata: documentazione avanzata che supporta casi d'uso più ampi di sicurezza e conformità
  
  
• Obiettivo previsto: caratteristiche avanzate che consentono una visibilità completa della catena di fornitura

I seguenti attributi rappresentano gli elementi essenziali richiesti in una SBOM completa:

• Meta-informazioni SBOM: dati fondamentali del documento SBOM stesso, incluso l'autore dei dati SBOM, il timestamp della sua creazione e il componente principale documentato
  
  
• Nome fornitore: l'entità che crea, definisce e produce il componente software
  
  
• Nome componente: il nome designato del componente software, assegnato dal fornitore originale
  
  
• Versione del componente: acquisisce le modifiche specifiche della versione per tenere traccia con precisione degli aggiornamenti e delle modifiche
  
  
• Altri identificatori univoci: include tipi di riferimento come Common Platform Enumeration (CPE), tag SWID o URL di pacchetti (PURL) per un tracciamento preciso dei componenti
  
  
• Hash crittografico: un'impronta digitale univoca per ogni componente software che consente la verifica dell'integrità e un'identificazione precisa
  
  
• Relazione di dipendenza: una mappa strutturata che mostra come i componenti sono interconnessi, coprendo sia le dipendenze dirette che quelle transitive
  
  
• Informazioni sulla licenza: documentazione delle condizioni legali per i componenti software forniti
  
  
• Avviso sul copyright: entità che detiene diritti esclusivi e legali sui componenti elencati

Le dipendenze software creano interconnessioni complesse all'interno delle applicazioni moderne. Una SBOM deve catturare chiaramente queste relazioni, facendo distinzione tra dipendenze dirette (componenti esplicitamente inclusi nel software) e dipendenze transitive (componenti inseriti da altre dipendenze).

Nel documentare le dipendenze, le organizzazioni devono indicare esplicitamente la completezza delle proprie conoscenze. Il presupposto predefinito è che le informazioni sulle dipendenze potrebbero essere incomplete, a meno che non sia esplicitamente dichiarato il contrario. Questa trasparenza aiuta gli utenti a valle a comprendere i potenziali punti ciechi nella loro supply chain del software.

Le organizzazioni devono anche tenere conto delle dipendenze dinamiche caricate in tempo di esecuzione e delle dipendenze remote chiamate da servizi esterni. Anche se potrebbero non far parte della build tradizionale del software, comprendere queste relazioni è fondamentale per una valutazione completa della sicurezza.

Nelle implementazioni del mondo reale, la conoscenza completa di tutti i componenti del software non è sempre possibile. Le organizzazioni devono gestire queste lacune in modo trasparente, documentando in modo esplicito le dipendenze sconosciute e le informazioni incomplete. Quando alcuni componenti non possono essere completamente documentati a causa di obblighi contrattuali o altri vincoli, la SBOM deve indicare queste omissioni preservando la struttura complessiva delle dipendenze.

Piuttosto che omettere informazioni incerte, le organizzazioni devono contrassegnare esplicitamente queste aree come sconosciute o incomplete. Questo approccio aiuta gli utenti a valle a prendere decisioni informate sulla gestione del rischio e sulle ulteriori esigenze di indagine. Per i componenti omessi, le organizzazioni devono mantenere sia le SBOM interne complete che le versioni adeguatamente oscurate in modo appropriato per la condivisione esterna.

Il processo di creazione e manutenzione delle SBOM coinvolge più stakeholder durante l'intero ciclo di vita dello sviluppo del software (SDLC). Le organizzazioni devono generare SBOM sia per i componenti software proprietari che per quelli open source (OSS). I fornitori e gli sviluppatori di software sono i principali responsabili della generazione delle SBOM iniziali nelle prime fasi del processo di sviluppo. Queste SBOM acquisiscono una visione completa dei componenti dell'intera base di codice. Gli acquirenti di software svolgono un ruolo fondamentale nella convalida e nella manutenzione di questi documenti per le applicazioni da loro distribuite.

I team di sviluppo software integrano la generazione delle SBOM direttamente nei loro pipeline di integrazione continua e distribuzione continua (CI/CD). Durante il processo di compilazione, gli strumenti di scansione automatici analizzano il codice sorgente per avere l'inventario di tutti i componenti, rilevando le dipendenze dirette e transitive. Questi strumenti generano file SBOM standardizzati in formati come SPDX e CycloneDX. (I tag SWID sono un'opzione meno frequente, ma comunque valida.) Documentano i metadati, le informazioni sulla versione e i dettagli sulla licenza di ogni componente.

I sistemi di controllo delle versioni mantengono i registri storici delle modifiche SBOM, monitorando l'evoluzione della composizione del software nel tempo. Le organizzazioni possono tenere traccia delle modifiche alla versione e delle patch di sicurezza all'interno dei componenti software per ogni versione, il che è fondamentale per gestire le vulnerabilità e gestire gli incidenti di sicurezza.

I team di sviluppo in genere configurano le proprie pipeline per attivare gli aggiornamenti SBOM in base a eventi specifici: quando vengono aggiunte nuove dipendenze, quando i componenti esistenti vengono aggiornati o quando vengono applicate patch di sicurezza. Questo processo di aggiornamento continuo mantiene l'allineamento tra la composizione effettiva del software e la sua documentazione.

I punti di controllo qualità in tutta la pipeline di sviluppo convalidano la completezza e l'accuratezza della SBOM. Queste fasi di convalida verificano che ogni SBOM soddisfi gli standard richiesti e contenga tutte le informazioni necessarie sui componenti prima del rilascio del software. La convalida automatizzata riduce le lacune nella documentazione e migliora la coerenza tra le versioni.

L'ecosistema di strumenti a supporto della creazione di SBOM continua ad espandersi. I generatori di SBOM costituiscono la base, scansionando automaticamente il codice sorgente per identificare i componenti e le loro relazioni. Gli strumenti di convalida verificano poi le SBOM generate rispetto agli standard e alle specifiche stabilite, segnalando le informazioni mancanti o errate. Un'automazione SBOM di successo si basa su best practice consolidate: standardizzare i formati tra i team, implementare convenzioni di denominazione coerenti, mantenere una documentazione chiara delle regole di automazione e stabilire circuiti di feedback per il miglioramento continuo.

Le piattaforme di gestione si basano su queste caratteristiche e offrono funzionalità di storage, analisi e distribuzione SBOM tra le organizzazioni. Le piattaforme avanzate vanno ancora oltre, integrando i dati SBOM in workflow di rischio e conformità più ampi.

Ad esempio, gli strumenti di automazione possono mappare le vulnerabilità su componenti software specifici, dare priorità agli sforzi di correzione in base alla gravità e tenere traccia delle modifiche nel tempo per identificare i rischi appena introdotti. Consolidando i dati e fornendo insight in tempo reale, questi strumenti consentono ai team di sviluppo, sicurezza e conformità di collaborare efficacemente.

La scelta del formato SBOM corretto è fondamentale per un'implementazione efficace. Le SBOM devono supportare la generazione automatica e la leggibilità automatica per scalare tutti gli ecosistemi software. L'automazione dei processi SBOM elimina gli errori di input manuale durante la creazione e consente una perfetta integrazione con gli strumenti di sicurezza e sviluppo.

Esistono diversi formati standardizzati utilizzati per consentire la generazione, la convalida e il consumo automatici di dati SBOM, supportando al contempo l'integrazione con gli strumenti di sicurezza e sviluppo esistenti. Le organizzazioni devono implementare la generazione automatica di SBOM all'interno delle loro pipeline CI/CD per assicurarsi che la documentazione rimanga aggiornata con le modifiche al software.

L'attuale framework CISA riconosce principalmente due formati: SPDX e CycloneDX. Ognuni approccio affronta la documentazione dei componenti software in modo diverso, offrendo vari livelli di precisione e concentrandosi su casi d'uso specifici all'interno del ciclo di vita dello sviluppo del software.

Software Package Data Exchange (SPDX) è stato sviluppato dalla Linux Foundation e ha ottenuto un'ampia adozione nell'ecosistema open source e nei fornitori di software commerciale. Il formato supporta la verifica crittografica dei pacchetti e offre diverse opzioni di formato leggibili dalla macchina, tra cui JSON, RDF, XML e YAML. Il suo ricco supporto di metadati consente di tracciare in modo dettagliato la sicurezza e la provenienza lungo tutta la supply chain del software.

SPDX eccelle negli scenari di conformità open source, fornendo informazioni dettagliate sulle licenze e aiutando le organizzazioni a gestire efficacemente l'utilizzo dei componenti open source. I principali fornitori di software e provider di servizi cloud hanno adottato SPDX per le sue specifiche robuste e il supporto dell'ecosistema.

CycloneDX, sviluppato dalla OWASP Foundation, è appositamente progettato per la sicurezza delle applicazioni e la gestione dei rischi della supply chain del software. Fornisce caratteristiche essenziali per la gestione delle vulnerabilità, il tracciamento dei componenti e la sicurezza della supply chain, con una forte enfasi sull'integrazione VEX e sul supporto all'analisi dei container.

I suoi elementi incentrati sulla sicurezza lo rendono particolarmente adatto alle organizzazioni che implementano programmi completi di sicurezza della supply chain del software. Il supporto nativo per i casi d'uso di sicurezza ha favorito l'adozione da parte dei team di sicurezza e dei workflow di gestione delle vulnerabilità.

I tag Software Identification (SWID) forniscono un meccanismo standardizzato per l'identificazione e la gestione del software. Il formato supporta il monitoraggio completo dell'asset con caratteristiche per la gestione del ciclo di vita, il monitoraggio delle patch e il controllo dell'inventario in ambienti aziendali. In particolare, i tag SWID non sono più elencati come formato supportato nelle linee guida del 2024 per la mappatura degli attributi, ma rimangono un'opzione valida come identificatore univoco all'interno delle SBOM.

L'analisi della composizione del software (SCA) è un processo di cybersecurity attivo (con strumenti associati) che analizza il codice alla ricerca di vulnerabilità, mentre una distinta base del software (SBOM) fornisce un inventario standardizzato di tutti i componenti software di un prodotto. Sebbene entrambi supportino la sicurezza della supply chain del software, hanno scopi diversi negli ambienti di sviluppo moderni.

Sebbene entrambi gli strumenti si concentrino sui componenti software, gli strumenti SCA scansionano e analizzano attivamente il codice durante lo sviluppo, concentrandosi principalmente sui componenti open source e sulle dipendenze di terze parti. Questi strumenti forniscono insight in tempo reale per il rilevamento delle vulnerabilità, la conformità delle licenze e l'applicazione delle politiche di sicurezza.

Una SBOM funziona come un documento di inventario standardizzato che raccoglie tutti i componenti software, incluso il codice proprietario. Le SBOM forniscono trasparenza nella composizione del software attraverso formati strutturati come SPDX e CyclonedX, ma non includono intrinsecamente funzionalità di analytics. Sebbene gli strumenti SCA in genere supportino le pratiche di sicurezza interne, le SBOM stanno diventando sempre più obbligatorie secondo le normative e gli standard di settore.

Le organizzazioni in genere implementano entrambe le soluzioni, utilizzando strumenti SCA per monitorare attivamente la sicurezza durante lo sviluppo e mantenendo le SBOM per i requisiti di conformità e la visibilità della supply chain. Gli strumenti SCA spesso generano e convalidano le SBOM in modo automatico, mentre la documentazione SBOM aiuta a informare le politiche di scansione.

La complessità delle moderne supply chain del software ha reso l'adozione delle SBOM essenziale per una gestione completa del rischio e la garanzia della sicurezza. Le organizzazioni utilizzano sempre più piattaforme automatizzate in grado di consolidare i dati SBOM con altre informazioni di sicurezza e conformità per un processo decisionale più efficace.

I team di sicurezza integrano i dati SBOM nelle loro strategie di gestione del rischio delle applicazioni più ampie attraverso piattaforme automatizzate che consentono il rilevamento e la risposta alle vulnerabilità in tempo reale. Quando emergono nuove vulnerabilità ed esposizioni comuni (CVE), queste piattaforme possono mapparle istantaneamente ai componenti interessati dell'intero portfolio software utilizzando gli inventari SBOM. Questo aiuta le organizzazioni a supportare pratiche software sicure.

Questa integrazione consente di ottenere insight basati sull'AI per definire le priorità dei rischi, aiutando i team a indirizzare per primi i CVE più critici. Durante la risposta agli incidenti, i dati dettagliati dei componenti delle SBOM forniscono informazioni cruciali sui componenti potenzialmente compromessi. In questo modo, è possibile effettuare interventi di correzione mirati e valutazioni del rischio più accurate.

Le SBOM svolgono un ruolo importante nella gestione delle vulnerabilità fornendo un inventario completo dei componenti software e consentendo una rapida identificazione dei sistemi interessati quando vengono scoperte nuove vulnerabilità.

Tuttavia, non tutte le vulnerabilità presentano lo stesso rischio, e determinare il possibile livello di sfruttabilità può essere difficile. È qui che entra in gioco il Vulnerability Exploitability eXchange (VEX). VEX è un framework di sicurezza che rafforza l'utilità delle SBOM fornendo un contesto essenziale sulle vulnerabilità note. Sebbene una SBOM possa identificare tutti i componenti di un prodotto software, non indica se le vulnerabilità scoperte siano sfruttabili. VEX colma questa lacuna chiarendo l'impatto delle vulnerabilità nel mondo reale.

VEX informa i Product Security Incident Response Teams (PSIRT) e i team di sicurezza sull'eventuale impatto di vulnerabilità specifiche sui loro ambienti software. Utilizzando il Common Security Advisory Framework (CSAF), un VEX fornisce aggiornamenti di stato leggibili dalla macchina sull'impatto delle vulnerabilità. Con queste informazioni, i team di sicurezza possono prendere decisioni più rapide e informate.

Integrando i dati VEX con le SBOM, le organizzazioni possono ridurre i falsi positivi, dare priorità ai rischi effettivi e semplificare i workflow di gestione delle vulnerabilità. Questo approccio combinato segna un progresso significativo nella valutazione automatizzata dei rischi di sicurezza e nella correzione mirata.

Con l'evolversi dei requisiti normativi, le organizzazioni hanno bisogno di sofisticate funzionalità di gestione della conformità in grado di gestire requisiti SBOM complessi. Le SBOM fungono da forma di attestazione, fornendo una documentazione verificabile che i componenti software aderiscono a standard come le linee guida del NIST e l'Ordine Esecutivo 14028. Offrendo registrazioni trasparenti della composizione e della sicurezza del software, le SBOM semplificano gli audit e dimostrano l'allineamento normativo tra i settori.

Le agenzie federali e i settori regolamentati devono dimostrare la conformità con vari framework, tra cui le linee guida del NIST e l'Ordine Esecutivo 14028. Le piattaforme di conformità avanzate possono verificare automaticamente che i componenti soddisfino gli standard di sicurezza, tracciare lo stato di conformità su più framework e fornire avvisi in tempo reale quando i componenti si discostano dai requisiti. Queste funzionalità aiutano le organizzazioni a mantenere la conformità continua, riducendo al contempo la supervisione manuale.

Gli ambienti cloud-native e containerizzati pongono sfide uniche per la gestione delle SBOM. La natura dinamica di questi ambienti richiede approcci specializzati per gestire architetture di microservizi complesse, immagini dei container che cambiano frequentemente e implementazioni che si estendono su più provider di cloud e piattaforme.

Le organizzazioni affrontano queste sfide attraverso strumenti SBOM specializzati che si integrano direttamente con le piattaforme di indirizzo dei container. Si tratta di soluzioni che consentono la generazione di SBOM in tempo reale man mano che le immagini dei container vengono costruite e distribuite, fornendo al contempo una visibilità unificata negli ambienti di hybrid cloud.

Automatizzando il monitoraggio dei componenti e integrandosi con gli strumenti di sicurezza cloud esistenti, le organizzazioni possono mantenere inventari accurati dei componenti software e rispondere rapidamente alle minacce alla sicurezza in tutta la loro infrastruttura cloud. Questa funzionalità si applica sia che le applicazioni vengano eseguite in contenitori, come funzioni serverless o in ambienti tradizionali.

Le SBOM fungono da base per la gestione del rischio della supply chain consentendo una visibilità completa del software di terze parti. Le organizzazioni utilizzano spesso piattaforme basate su AI per analizzare i dati SBOM insieme ad altre metriche di sicurezza, creando una visione olistica dello stato di salute e del livello di rischio.

Queste piattaforme tengono traccia delle versioni dei componenti, valutano i rischi dei fornitori e promuovono la conformità delle licenze, fornendo al contempo insight fruibili per la mitigazione del rischio. L'integrazione dei dati SBOM con processi di gestione del rischio più ampi consente alle organizzazioni di prendere decisioni informate sulle loro dipendenze dal software e mantenere ambienti applicativi più sicuri e conformi.

Le organizzazioni possono affrontare diversi ostacoli significativi nell'implementazione delle pratiche SBOM nel loro ecosistema software. Comprendere e affrontare queste sfide è una parte fondamentale di un'adozione di successo e del mantenimento di una sicurezza dei dati efficace lungo la supply chain.

Ecco alcune sfide che si presentano quando le organizzazioni implementano le pratiche SBOM:

• Gestione di migliaia di componenti software in ambienti diversi
  
  
• Integrazione dei dati SBOM tra diversi strumenti di sviluppo e piattaforme di sicurezza
  
  
• Mantenimento della qualità dei dati, in particolare per software legacy e componenti di terze parti
  
  
• Monitoraggio delle dipendenze negli ambienti cloud con cicli di distribuzione rapidi
  
  
• Bilanciamento dei vincoli delle risorse con la necessità di dati SBOM accurati e attuali
  
  
• Adattamento ad architetture cloud-native dinamiche in cui i componenti cambiano frequentemente

Il successo dell'implementazione della SBOM richiede un approccio strategico in linea con gli standard dei settori e le esigenze organizzative. Gli elementi chiave includono:

• Automatizzare i processi durante il ciclo di vita dello sviluppo del software
  
  
• Integrazione perfetta con i workflow e gli strumenti di sicurezza esistenti
  
  
• Utilizzo di una piattaforma unificata per la gestione delle SBOM

• Implementazione degli elementi essenziali per la funzionalità e la conformità SBOM di base.
  
  
• Miglioramento della documentazione per casi d'uso più ampi in materia di sicurezza e conformità
  
  
• Abilitazione di una visibilità completa della supply chain attraverso caratteristiche avanzate

• Generare e aggiornare le SBOM in tempo reale, in particolare negli ambienti cloud-native
  
  
• Documentare le informazioni sconosciute in modo trasparente anziché ometterle
  
  
• Gestire sia le SBOM interne complete che le versioni redatte per la condivisione esterna
  

• Creare politiche di governance SBOM chiare con audit regolari e convalida automatizzata
  
  
• Connettere i dati SBOM con Vulnerability Exploitability eXchange (VEX) per una migliore gestione delle vulnerabilità

Seguendo queste pratiche, le organizzazioni possono migliorare la visibilità della supply chain, rafforzare la sicurezza e mantenere la conformità mentre affrontano le sfide dell'implementazione della SBOM.

Il panorama della sicurezza della supply chain del software continua ad evolversi, guidando le innovazioni nella tecnologia e nell'adozione delle SBOM. Poiché le organizzazioni devono affrontare minacce sempre più sofisticate, il ruolo delle SBOM nella protezione degli ecosistemi software diventa sempre più critico.

Diverse tendenze chiave stanno plasmando il futuro dell'implementazione e dell'utilizzo delle SBOM:

I progressi dell'intelligenza artificiale stanno trasformando il modo in cui le organizzazioni gestiscono e utilizzano le SBOM. I sistemi di AI moderni ora automatizzano la generazione e l'analisi della SBOM, offrendo al contempo un'analisi predittiva del rischio più accurata e un rilevamento raffinato delle vulnerabilità. Questa automazione si estende all'identificazione proattiva dei rischi di sicurezza in tutte le supply chain del software.

Uno sviluppo significativo è l'emergere di BOM specializzate in AI/ML, che affrontano sfide uniche nel codice e nei modelli generati dall'AI. Queste BOM potenziate documentano le architetture dei modelli AI, i dati di formazione e i metodi di test, fornendo la necessaria trasparenza ai processi di sviluppo AI.

Il landscape della sicurezza per la gestione SBOM Continua ad evolversi. La tecnologia blockchain e la tecnologia dei registri distribuiti offrono nuove soluzioni per il storage e la condivisione sicura di SBOM, creando percorsi di controllo immutabili che risultano particolarmente utili per i sistemi infrastrutturali critici. Le organizzazioni richiedono sempre più dati SBOM fruibili che consentano la rapida identificazione dei componenti compromessi e una correzione semplificata.

La tecnologia blockchain migliora la sicurezza SBOM fornendo un storage a prova di manomissione, consentendo la verifica decentralizzata e facilitando la condivisione sicura tra organizzazioni con rigorosi controlli di accesso.

Questa convergenza tecnologica favorisce l'adozione di piattaforme unificate che si integrano con le pratiche DevSecOps esistenti. Queste soluzioni automatizzano l'intero ciclo di vita della SBOM, dall'unione di diverse fonti di dati alla gestione delle approvazioni su più versioni di software e più branch, fornendo al contempo informazioni per la mitigazione dei rischi.