La distinta materiali del software (SBOM) è un elenco di tutti i componenti, le librerie e le altre dipendenze utilizzate in un'applicazione software. I formati standard per le SBOM includono SPDX, CycloneDX e CPE (Common Platform Enumeration). Questi formati forniscono un modo strutturato per rappresentare i componenti e le dipendenze in un'applicazione software, semplificando la comprensione e la gestione dei rischi per la sicurezza associati a tali componenti.
In questo articolo spiegheremo, in dettaglio, quali sono i vari formati e standard SBOM, cosa dovrebbe includere una SBOM e perché tutte le organizzazioni devono utilizzarla.
Che cos'è uno standard SBOM?
La complessità e la natura dinamica delle catene di fornitura dei moderni sistemi software rappresentano una sfida significativa per la trasparenza. Questa mancanza di trasparenza contribuisce ai rischi per la sicurezza informatica e aumenta i costi associati allo sviluppo, all’approvvigionamento e alla manutenzione. Le conseguenze di ciò sono di vasta portata e riguardano non solo le imprese ma anche questioni collettive come la sicurezza pubblica e la sicurezza nazionale nel nostro mondo interconnesso.
Una maggiore trasparenza nelle catene di fornitura del software può portare a una riduzione dei rischi e dei costi della sicurezza informatica:
- Migliorare l’identificazione dei sistemi vulnerabili e identificare la causa principale degli incidenti
- Diminuzione del lavoro non pianificato e improduttivo
- Consentire una differenziazione del mercato e una selezione dei componenti più informate
- Standardizzare i formati in più settori, con conseguente riduzione della duplicazione degli sforzi
- Rilevamento di componenti software sospetti o contraffatti
Raccogliere e condividere queste informazioni in un formato chiaro e coerente può aiutare a ridurre i costi, migliorare l’affidabilità e aumentare la fiducia nella nostra infrastruttura digitale.
Per quello scopo, il gruppo di lavoro sulla trasparenza del software NTIA su standard e formati è stata fondata nel 2018 per valutare i formati attuali delle distinte materiali del software e identificare potenziali usi futuri. Il gruppo ha esaminato gli standard e le iniziative esistenti relativi all'identificazione dei componenti esterni e delle librerie condivise utilizzate nei prodotti software e alla comunicazione di queste informazioni in un formato leggibile dalla macchina. Il gruppo non ha considerato formati proprietari. Il sondaggio originale è stato pubblicato alla fine del 2019 ed è stato aggiornato nel 2021, con l'obiettivo di evidenziare i vantaggi dell'ecosistema di strumenti SBOM e l'importanza del coordinamento e dell'armonizzazione nel mondo tecnico SBOM. Il punto fondamentale è che i dati SBOM possono essere trasmessi in vari formati e l’ecosistema dovrebbe supportare l’interoperabilità tra di loro.
Il gruppo di lavoro ha scoperto che vengono comunemente utilizzati tre formati:
- Software Package Data Exchange (SPDX®), un formato open source leggibile dalle macchine sviluppato dalla Linux Foundation e ora uno standard ISO/IEC
- CycloneDX (CDX), un formato open source leggibile dalla macchina sviluppato dalla comunità OWASP
- Software Identification (SWID), uno standard di settore ISO/IEC utilizzato da vari editori di software commerciale
Vale la pena notare che questi tre formati condividono alcune informazioni comuni. Tuttavia, sono stati tradizionalmente utilizzati in diverse fasi del processo di sviluppo del software e sono destinati a pubblici diversi. Discuteremo ciascuno di questi formati in modo molto dettagliato in questo articolo.
Cosa dovrebbe includere una SBOM?
I componenti minimi della NTIA di una SBOM, detti elementi, sono costituiti da tre aree ampie e correlate. Questi elementi consentono un approccio flessibile alla trasparenza del software, affrontando sia la tecnologia che il funzionamento funzionale. Maggiori dettagli o avanzamenti tecnici potrebbero essere aggiunti in futuro. Come accennato in precedenza, al momento questi sono i componenti minimi e le organizzazioni potrebbero richiederne di più. La capacità di trasparenza nella catena di fornitura del software può migliorare ed evolversi nel tempo.
Strumenti Bowman per analizzare le seguenti finiture: elementi minimi richiesti per SBOM sono tipicamente raggruppati in tre categorie:
- Campi dati: Una SBOM dovrebbe includere dati importanti sui componenti software, come il nome del componente, il nome del fornitore, la versione e gli identificatori univoci. Dovrebbe includere anche informazioni sulle dipendenze tra i componenti, consentendo l'identificazione e il tracciamento accurati di tutti i componenti software lungo tutta la catena di fornitura.
- Pratiche e processi: La documentazione SBOM dovrebbe inoltre delineare pratiche e procedure standard per la creazione e l'aggiornamento della SBOM, la distribuzione e l'accesso ad essa, nonché la gestione degli errori.
- Supporto all'automazione: La distinta base del software dovrebbe essere leggibile dalla macchina e in grado di essere generata automaticamente per il monitoraggio continuo dei dati. In genere è in formati standard come i tag SPDX, CycloneDX e SWID che li rendono leggibili anche per gli esseri umani.
Formato standard SPDX SBOM
La specifica SPDX® (Software Package Data Exchange) è uno standard ISO/IEC per la condivisione di informazioni su componenti software, licenze, copyright e dettagli di sicurezza in più formati di file. Questo progetto ha sviluppato e continua a migliorare una serie di standard per lo scambio di dati che consentono alle aziende e alle organizzazioni di condividere i metadati del software in un formato che possa essere compreso sia dagli esseri umani che dalle macchine, semplificando i processi della catena di fornitura del software.
Le informazioni SPDX possono essere collegate a prodotti software specifici, componenti o set di componenti, singoli file o anche piccoli frammenti di codice. Il progetto SPDX è focalizzato sulla creazione e il perfezionamento di un linguaggio per descrivere i dati che possono essere scambiati come parte di una SBOM e sulla capacità di presentare questi dati in più formati di file (RDF/XML, XLSX, tag-value, JSON, YAML e XML) per semplificare la raccolta e la condivisione delle informazioni sui pacchetti software e sui relativi contenuti, con conseguenti miglioramenti in termini di tempo e precisione.
La specifica SPDX delinea i campi e le sezioni necessari per un documento valido, ma è importante notare che non tutte le sezioni sono obbligatorie: è richiesta solo la sezione delle informazioni sulla creazione. Il creatore del documento può scegliere quali sezioni e campi desidera includere, che descrivono le informazioni sul software e sui metadati che intende condividere.
SPDX può acquisire in modo efficace i dati della distinta base del software rappresentando tutti i componenti presenti nello sviluppo e nella distribuzione del software. Viene utilizzato per documentare immagini distro .iso, contenitori, pacchetti software, file binari, file sorgente, patch e persino piccoli frammenti di codice incorporati in altri file. SPDX offre una serie completa di relazioni per connettere elementi software all'interno dei documenti e tra documenti SBOM. Un documento SBOM SPDX può anche fare riferimento a fonti esterne come il National Vulnerability Database e altri metadati del sistema di packaging.
Esistono diversi componenti che compongono un documento SPDX: informazioni sulla creazione, informazioni sul pacchetto, informazioni sul file, informazioni sullo snippet, altre informazioni sulla licenza, relazioni e annotazioni.
Ogni documento SPDX può essere rappresentato da un'implementazione completa del modello di dati e da una sintassi dell'identificatore, consentendo lo scambio tra diversi formati di output dei dati (RDF/XML, tag-value, XLSX) e la convalida formale dell'accuratezza del documento. La versione 2.2 della specifica SPDX include formati di output aggiuntivi come JSON, YAML e XML e affronta anche le "incognite note" come identificato nel documento SBOM originale. Maggiori informazioni sul modello di dati sottostante di SPDX possono essere trovate nell'Appendice III delle Specifiche SPDX e sul sito web di SPDX.
Formato standard SBOM CycloneDX
Il progetto CycloneDX è stato istituito nel 2017 con l'obiettivo di sviluppare uno standard SBOM completamente automatizzato e incentrato sulla sicurezza. Il gruppo di lavoro principale rilascia annualmente versioni immutabili e compatibili con le versioni precedenti, utilizzando un processo di standard basato sul rischio. CycloneDX include specifiche esistenti come URL del pacchetto, CPE, SWID e ID ed espressioni di licenza SPDX. Gli SBOM possono essere rappresentati in diversi formati tra cui XML, JSON e Buffer di protocollo (protobuf).
CycloneDX è una specifica SBOM leggera destinata all'uso nell'analisi dei componenti della catena di fornitura e nella sicurezza del software. Consente la comunicazione dell'inventario dei componenti software, dei servizi esterni e delle relazioni tra loro. È uno standard open source sviluppato da OWASP (Open Web Application Security Project).
CycloneDX può catturare la natura dinamica dei componenti open source il cui codice sorgente è accessibile, modificabile e ridistribuibile. La specifica può rappresentare l'albero genealogico di un componente, inclusi i suoi antenati, discendenti e varianti, descrivendo la discendenza del componente da qualsiasi prospettiva, nonché i commit, le patch e le differenze che lo rendono unico.
Il progetto CycloneDX mantiene un elenco di strumenti proprietari e open source noti che supportano o sono compatibili con lo standard, che è supportato dalla comunità.
La specifica CycloneDX definisce un modello a oggetti dettagliato che garantisce coerenza tra tutte le implementazioni. Può essere convalidato utilizzando XML Schema e JSON Schema oppure utilizzando l'interfaccia della riga di comando CycloneDX. Vengono inoltre forniti tipi di media per XML e JSON per la distribuzione e l'utilizzo automatizzati dei formati supportati.
Le SBOM CycloneDX possono contenere le seguenti informazioni: metadati della distinta base, componenti, servizi, dipendenze, composizioni ed estensioni
CycloneDX è uno standard SBOM completo in grado di caratterizzare vari tipi di software, tra cui applicazioni, componenti, servizi, firmware e dispositivi. È ampiamente utilizzato in tutti i settori per descrivere pacchetti software, librerie, framework, applicazioni e immagini di contenitori. Il progetto è compatibile con i principali ecosistemi di sviluppo e offre implementazioni per fabbriche di software come le azioni GitHub, consentendo alle organizzazioni di automatizzare completamente la creazione di SBOM.
Etichetta SWID
I tag SWID, o tag di identificazione del software, sono stati creati per consentire alle organizzazioni di tenere traccia del software installato sui propri dispositivi gestiti in modo trasparente. Lo standard è stato stabilito dall'ISO nel 2012 e rivisto come ISO/IEC 19770-2:2015 nel 2015. Questi tag contengono informazioni dettagliate su una versione specifica di un prodotto software.
Lo standard SWID delinea un ciclo di vita per il monitoraggio del software: un tag SWID viene aggiunto a un endpoint durante l'installazione di un prodotto software e rimosso dal processo di disinstallazione del prodotto. L'esistenza di uno specifico Tag SWID corrisponde direttamente alla presenza del software che descrive. Molteplici organizzazioni di standardizzazione, come il Trusted Computing Group (TCG) e l'Internet Engineering Task Force (IETF), incorporano i tag SWID nei loro standard.
Per tenere traccia del ciclo di vita di un componente software, la specifica SWID prevede quattro tipi di tag: primario, patch, corpus e supplementare. I tag corpus, primario e patch hanno scopi simili in quanto descrivono l'esistenza e la presenza di diversi tipi di software, come programmi di installazione software, installazioni software e patch software, nonché i possibili stati dei prodotti software. D'altro canto, i tag supplementari forniscono dettagli aggiuntivi non presenti nei tag corpus, primari o patch.
I tag supplementari possono essere collegati a qualsiasi altro tag per fornire metadati aggiuntivi che potrebbero essere utili. Insieme, i tag SWID possono eseguire una varietà di funzioni, come il rilevamento del software, la gestione della configurazione e la gestione delle vulnerabilità.
I tag SWID possono funzionare come SBOM, poiché forniscono informazioni di identificazione per un componente software, un elenco di file e hash crittografici per gli artefatti del componente e informazioni sulla provenienza del creatore della SBOM (tag) e del componente software. I tag possono anche collegarsi ad altri tag, consentendo la rappresentazione di un albero delle dipendenze.
I tag SWID possono essere generati durante il processo di creazione e confezionamento, consentendo la creazione automatica di una SBOM basata su tag SWID quando viene creato il pacchetto del componente software corrispondente.
Perché le distinte materiali del software sono importanti?
Le distinte materiali del software (SBOM) stanno diventando sempre più importanti per le organizzazioni poiché mirano a gestire e proteggere il software che utilizzano. Non esiste una risposta breve alla domanda cos'è una SBOM. Le SBOM forniscono un elenco completo di tutti i componenti e le dipendenze che compongono un pacchetto software, incluse informazioni quali numeri di versione, autori e informazioni sulla licenza. Queste informazioni sono fondamentali per la sicurezza e la conformità, nonché per monitorare la provenienza dei componenti software.
Molte organizzazioni, comprese quelle dei settori regolamentati, utilizzano le SBOM per garantire la conformità a normative come il Regolamento generale sulla protezione dei dati (GDPR) e il Payment Card Industry Data Security Standard (PCI DSS). Le SBOM possono anche aiutare a identificare e gestire le vulnerabilità nel software, nonché a monitorare la provenienza dei componenti software. Inoltre, le SBOM possono assistere nella gestione delle licenze software, garantendo che le organizzazioni utilizzino il software in conformità con i termini delle loro licenze.
Le SBOM possono essere utilizzate anche per tenere traccia dell'utilizzo di software open source, che sta diventando sempre più comune nello sviluppo di software. Fornendo informazioni dettagliate sui componenti open source utilizzati in un pacchetto software, gli SBOM possono aiutare le organizzazioni a garantire la conformità con le licenze open source.
Inoltre, le SBOM possono essere utilizzate per supportare lo sviluppo e la manutenzione del software. Fornendo informazioni dettagliate sui componenti utilizzati in un pacchetto software, le SBOM possono aiutare gli sviluppatori a comprendere le dipendenze di un pacchetto software, il che può aiutarli a identificare potenziali problemi di compatibilità e a prendere decisioni informate sull'uso di nuovi componenti.