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

Definizione della distinta base del software

La distinta base del software (SBOM) elenca tutte le parti componenti e le dipendenze software coinvolte nello sviluppo e nella consegna di un'applicazione. Le SBOM sono simili alle distinte materiali (BOM) utilizzate nelle catene di fornitura e nella produzione. Non esiste una caratteristica comune a tutti i fornitori del settore IT per descrivere accuratamente i componenti fondamentali del codice su cui è costruita un'applicazione.

Una SBOM tipica include informazioni sulla licenza, numeri di versione, dettagli sui componenti e fornitori. Un elenco formale di tutti i fatti riduce i rischi sia per il produttore che per l'utente consentendo ad altri di comprendere cosa c'è nel loro software e di agire di conseguenza. Le SBOM non sono una novità per l'industria del software, ma stanno diventando sempre più vitali man mano che lo sviluppo diventa più sofisticato e costoso. Negli ultimi tempi sono diventati un requisito fondamentale in numerose aziende.

Vantaggi dell'SBOM

Si occupa delle minacce all'integrità

Gli attacchi possono verificarsi in qualsiasi punto della normale catena di fornitura del software e nel mondo di oggi questi attacchi stanno diventando sempre più visibili, distruttivi e costosi. L'integrità può essere mantenuta utilizzando una SBOM verificando che i componenti e i file in essa contenuti siano gli stessi previsti. Ad esempio, uno dei componenti del formato CycloneDX è un valore hash che può essere utilizzato nella corrispondenza esatta di file e componenti. Poiché una SBOM non è un documento statico, deve essere aggiornata ogni volta che si verifica una modifica nel software descritto o nei suoi componenti.

Consente la visibilità dei componenti del prodotto

Le aziende devono creare la fiducia dei clienti per generare fedeltà e promuovere acquisti ripetuti. Piuttosto che garanzie o promesse, le SBOM condivise forniscono una maggiore visibilità sulla qualità delle tecnologie utilizzate.

Consente una scansione delle vulnerabilità più semplice

Le aziende possono utilizzare le SBOM per identificare ed eliminare le vulnerabilità prima che raggiungano la produzione. Le nuove vulnerabilità nel software di produzione possono essere risolte rapidamente. Le SBOM, infine, aiutano gli ingegneri a scoprire e risolvere più rapidamente i difetti di sicurezza.

Sfrutta la governance delle licenze per il tuo prodotto

L'adozione della distinta base del software può contribuire a migliorare la governance delle licenze software. Ogni software viene fornito con una licenza che specifica come può essere utilizzato e distribuito legalmente. I componenti costitutivi di una catena di fornitura che costituiscono un'applicazione completa potrebbero avere una varietà di licenze diverse. Qualsiasi azienda che utilizza il programma è legalmente obbligata a seguire la licenza. Potrebbe non essere possibile determinare cosa richiedono le licenze o come rispettarle senza una distinta base del software.

Principi di una SBOM ben formata

I componenti minimi di una SBOM ben formata sono suddivisi in tre categorie:

Campi dati

Lo scopo di questi campi è fornire un'adeguata identificazione di questi componenti. Ciò consente di monitorarli lungo la catena di fornitura del software e di collegarli ad altre fonti di dati utili, come database di vulnerabilità o licenze. Alcuni esempi di campi dati sono nome fornitore, nome componente, versione del componente, altri identificatori univoci, relazione di dipendenza, autore dei dati SBOM e timestamp.

Supporto per l'automazione

Le organizzazioni che desiderano tenere d'occhio i dati dei componenti SBOM dovranno fornirli in uno stile coerente e di facile comprensione. Questo problema viene affrontato nella sezione dei requisiti di base SBOM in "Supporto di automazione". Quando si inviano SBOM oltre i confini dell'organizzazione, è possibile scegliere tra tre standard:

1. Scambio di dati del pacchetto software (SPDX)
2. CicloneDX
3. Tag di identificazione del software (SWID).

Questi verranno discussi ulteriormente un po' più avanti in questo articolo.

Pratiche e processi

Infine, la sezione “Pratiche e processi” definisce sei standard su come e quando le SBOM dovrebbero essere aggiornate e fornite. Sono i seguenti:

• Se il componente software viene aggiornato con una nuova build o release, è necessario produrre nuove SBOM.
• Gli autori delle SBOM dovrebbero includere i componenti di primo livello nonché le relative dipendenze transitive.
• Se la SBOM non offre un albero delle dipendenze completo, l'autore della SBOM deve spiegare se ciò è dovuto al fatto (a) che il componente non ha più dipendenze o (b) l'esistenza delle dipendenze è sconosciuta e incompleta.
• Le SBOM devono essere distribuite e consegnate in modo “tempestivo”, con “diritti di accesso e ruoli adeguati”.
• Le aziende che desiderano mantenere segreti alcuni componenti di una SBOM devono specificare i parametri di controllo dell'accesso, che conterrebbero regole e procedure specifiche per incorporare le informazioni relative alla SBOM nel manuale e negli strumenti dell'utente. Per dirla semplicemente: se c'è qualcosa che deve essere tenuto segreto per il bene dell'organizzazione, allora il processo per mantenerlo segreto è definito in questa sezione. 
• Poiché gli standard che controllano la generazione della SBOM sono nuovi, si consiglia agli utenti della SBOM di perdonare errori o omissioni (non intenzionali).

Diversi formati SBOM

Naturalmente, puoi generare manualmente una fattura SBOM elencando i numerosi componenti all'interno del software che hai prodotto. Tuttavia, mantenere enormi codebase con dozzine o addirittura centinaia di dipendenze e componenti di terze parti è un compito noioso e dispendioso in termini di tempo, soprattutto per gli sviluppatori che gestiscono codebase di grandi dimensioni con più componenti e dipendenze di terze parti. Alcuni sviluppatori potrebbero aver incluso componenti di terze parti in un'applicazione senza documentarla. Di conseguenza, gli attuali sviluppatori potrebbero non avere familiarità con l'intera base di codice.

Per rendere l'adozione una realtà, le SBOM devono aderire agli standard accettati dal settore che consentano l'interoperabilità tra diversi settori e organizzazioni. Le organizzazioni dispongono già dell'architettura per sviluppare, gestire e distribuire i dati dei componenti software, grazie ad alcuni standard.

SPDX: scambio di dati di pacchetti software

I Scambio di dati del pacchetto software (SPDX) è lo standard aperto principale per i formati di distinta base del software sviluppato dalla Linux Foundation nel 2010. Componenti software, copyright, licenze e riferimenti di sicurezza sono tutti inclusi nei file SPDX. La specifica SPDX è compatibile con quella proposta da NTIA Standard minimi SBOM e casi d'uso. Le organizzazioni possono utilizzare SPDX Lite per scambiare dati poiché è una versione ridotta dello standard SPDX. L'SPDX ha ottenuto uno standard ufficiale come ISO/IEC 5962 nell'agosto 2021.

documento spdx

SWID: tag di identificazione del software

I Organizzazione internazionale per gli standard (ISO) iniziò a stabilire uno standard per contrassegnare i componenti software con ID leggibili dalla macchina prima della fine del decennio. I tag SWID, come sono ora conosciuti, sono metadati strutturati incorporati nel software che trasmettono informazioni come il nome del prodotto software, la versione, gli sviluppatori, le relazioni e altro ancora. I tag SWID possono aiutare ad automatizzare la gestione delle patch, la convalida dell'integrità del software, il rilevamento delle vulnerabilità e a consentire o vietare l'installazione di software, in modo simile alla gestione delle risorse software. Nel 2012 è stata confermata la norma ISO/IEC 19770-2, modificata nel 2015. Esistono quattro tipi principali di tag SWID utilizzati nelle varie fasi del ciclo di vita dello sviluppo del software:

1. Tag del corpo: Vengono utilizzati per identificare e caratterizzare i componenti software che non sono pronti per essere installati. Secondo il National Institute of Standards and Technology, i tag Corpus sono "progettati per essere utilizzati come input per strumenti e procedure di installazione del software".
2. Tag primari: Lo scopo di un tag primario è identificare e contestualizzare gli elementi software una volta installati.
3. Tag della patch: I tag patch identificano e descrivono la patch (in contrapposizione al prodotto principale stesso). I tag patch possono anche, e spesso lo fanno, incorporare informazioni contestuali sulla relazione della patch con altri beni o patch.
4. Tag supplementari: I tag supplementari consentono agli utenti del software e agli strumenti di gestione del software di aggiungere utili informazioni sul contesto dell'utilità locale come chiavi di licenza e informazioni di contatto per le parti interessate.

Quando si tratta di determinare quali tag e dati precisi offrire con i loro prodotti, le aziende hanno un notevole margine di manovra. Oltre ai dati obbligatori, lo standard SWID specifica una serie di componenti e caratteristiche opzionali. Infine, per un tag di base valido e conforme sono necessarie solo alcune caratteristiche che caratterizzano il prodotto software (come nome e Tag ID) e l'entità che lo ha generato.

CicloneDX

Nel 2017, la Fondazione OWASP ha rilasciato CicloneDX come parte di Dependency-Track, uno strumento di analisi dei componenti software open source. CycloneDX è uno standard leggero per l'uso multisettoriale, con casi d'uso come il rilevamento delle vulnerabilità, la conformità delle licenze e la valutazione dei vecchi componenti. CycloneDX 1.4 è stato lanciato nel gennaio 2022. Cyclone DX può gestire quattro diversi tipi di dati:

• Metadati del diagramma di flusso dei materiali: Contiene informazioni sull'applicazione/prodotto stesso, come fornitore, produttore e componenti descritti nella SBOM, nonché eventuali strumenti utilizzati per creare una SBOM.
• Componenti: Questo è un elenco completo dei componenti proprietari e open source, insieme alle informazioni sulla licenza.
• Servizi: Gli URI degli endpoint, i requisiti di autenticazione e gli attraversamenti dei confini di fiducia sono tutti esempi di API esterne che il software può utilizzare.
• dipendenze: comprendono collegamenti sia diretti che indiretti.

Fonte: CicloneDX

Che aspetto ha una SBOM?

Per l'identificazione del rischio è necessario un inventario completo e accurato di tutti i componenti di prima e terza parte. Tutti i componenti diretti e transitivi, nonché le dipendenze tra loro, dovrebbero essere inclusi nelle distinte base. Ad esempio, i seguenti tipi di componenti possono essere descritti utilizzando CycloneDX:

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "version": 1, "components": [ { " tipo": "libreria", "nome": "libreria-nacl", "versione": "1.0.0" } ] }

Formato XML:

 libreria-nacl 1.0

Perché firmare la tua SBOM?

Che cos'è una firma digitale?

A firma digitale è esattamente quello che sembra: una versione elettronica della tradizionale firma cartacea e penna. Verifica la validità e l'integrità delle comunicazioni e dei documenti digitali utilizzando un sofisticato approccio matematico. Garantisce che i contenuti di un messaggio non vengano manomessi durante il transito, aiutandoci a superare il problema dell'imitazione e della manomissione nelle comunicazioni digitali. L'adozione delle firme digitali è aumentata nel tempo e rappresenta uno standard crittografico. 

Come funzionano le firme digitali

Le firme digitali vengono create utilizzando la crittografia a chiave pubblica, nota anche come crittografia asimmetrica. Un approccio a chiave pubblica come RSA (Rivest-Shamir-Adleman) genera due chiavi, una privata e una pubblica, che portano a una coppia di chiavi matematicamente correlate. Uno dei meccanismi fondamentali alla base delle firme digitali è l’hashing. Trasforma efficacemente i dati in un output di dimensione fissa indipendentemente dalla dimensione dell'input. Ciò avviene tramite funzioni hash che sono fondamentalmente algoritmi e l'output che producono è chiamato valore hash. Le funzioni di hash crittografiche generano un valore hash che funge da impronta digitale, rendendolo unico per tutti. Allo stesso modo in cui l'impronta digitale di ognuno è diversa, diversi messaggi di input genereranno valori hash diversi. Le due chiavi crittografiche di crittografia a chiave pubblica (PKC) che si autenticano reciprocamente vengono utilizzate principalmente per le firme digitali. Il creatore della firma digitale utilizza una chiave privata per crittografare i dati relativi alla firma e tali dati possono essere decodificati solo utilizzando la chiave pubblica del firmatario. In questo modo il destinatario sa che il mittente non è compromesso e che i dati ricevuti sono corretti. Attualmente, gestire le infrastrutture a chiave pubblica è costoso e complicato come spesso accade perdere le loro chiavi private come se si perdessero le chiavi fisiche. Le autorità di certificazione (CA) agiscono come terze parti fidate ed emettono firme digitali accettando, verificando, emettendo e mantenendo i certificati digitali. Le CA aiutano a prevenire la creazione di certificati digitali falsi. Convalida anche il fornitore di servizi fiduciari (TSP). Un TSP è una persona o entità giuridica che convalida le firme digitali per conto di un'azienda e comunica i risultati della convalida.

Vantaggi di una SBOM con firma digitale

Una SBOM firmata fornisce un checksum, ovvero una lunga stringa di lettere e numeri che rappresentano la somma delle cifre precise di un dato digitale e che possono essere confrontate per individuare errori o modifiche. Un checksum è simile a un'impronta digitale. Su base regolare, verifica la ridondanza (CRC). Le modifiche ai dati grezzi nelle reti digitali e nei dispositivi di archiviazione vengono rilevate utilizzando un codice di rilevamento errori e una funzione di verifica. Poiché la firma digitale è destinata a fungere da strumento convalidato e sicuro per dimostrare l'autenticità delle transazioni – ovvero, una volta firmata, una persona non può pretendere diversamente – vincola tutti i firmatari alle procedure e alle azioni stabilite nella fattura. 

Problemi con una SBOM non firmata

Poiché uno degli scopi principali delle firme digitali è la verifica, una SBOM non firmata non è verificabile. Consideralo come un contratto: se un contratto non è stato firmato dalle parti partecipanti, non esiste un modo reale per farlo rispettare. Allo stesso modo, una SBOM non firmata è semplicemente un documento non firmato: il tuo cliente non può ritenerti responsabile.  Ciò può anche portare a ulteriori problemi in futuro, poiché una SBOM non firmata può anche comportare rischi per la sicurezza dell'organizzazione. Tutto ciò che altrimenti sarebbe stato protetto da una SBOM firmata ora non è protetto e pertanto i dati e le informazioni possono essere inviati o replicati ovunque. Uno degli scopi principali delle SBOM firmate, ovvero la responsabilità, viene meno quando una SBOM non viene firmata poiché è possibile apportarvi modifiche senza conseguenze da parte del creatore o del cliente. 

Utilizzo di SBOM per migliorare la sicurezza informatica

Le SBOM sono tra i modi migliori con cui le organizzazioni possono mantenere la sicurezza e l'autenticità dei propri dati e procedure. Inoltre, stabiliscono un precedente nel settore aumentando l’apertura tra sviluppatori, fornitori di software e clienti. Le organizzazioni possono comunicare in tutta sicurezza ai partner i dettagli operativi durante tutto il processo contrattuale se sono in vigore degli standard. Le organizzazioni avranno più successo nell’identificare difetti, vulnerabilità e minacce zero-day man mano che le SBOM diventeranno più diffuse. L’adozione della distinta base del software rappresenta un chiaro vantaggio per la sicurezza della catena di fornitura del software in tutto il mondo.

Utilizzo di VEX per ottenere maggiore usabilità dalla tua SBOM

Vulnerability Exploitability eXchange (VEX) è un avviso di sicurezza volto a esporre la sfruttabilità delle vulnerabilità nel contesto del prodotto in cui si trovano. Quando si esegue una scansione di vulnerabilità sulla maggior parte delle applicazioni moderne, i risultati potrebbero facilmente essere centinaia o migliaia di vulnerabilità. Del numero totale di vulnerabilità scoperte, solo il 5% circa è effettivamente sfruttabile. È anche importante ricordare che la sfruttabilità non è quasi mai una questione a sé stante. Nella maggior parte dei casi si tratta di un caso d'uso complesso di librerie open source, moduli e codice che li utilizza lavorando insieme per trasformare una vulnerabilità in un problema realmente sfruttabile. Fino a quando non si modifica l'applicazione e si esegue una nuova SBOM per descriverla, l'inventario descritto in una distinta base rimarrà in genere statico. Le informazioni sulle vulnerabilità sono molto più dinamiche e soggette a cambiamenti. Avere le informazioni VEX disponibili come elenco autonomo rende possibile aggiornare i dati VEX senza dover generare e gestire distinte base aggiuntive. La CISA fornisce un elenco dei dati minimi raccomandati che dovrebbe essere incluso in un utile avviso o documento VEX. Questi sono:

Metadati VEX: Identificatore formato VEX, Stringa identificativa per il documento VEX, Autore, Ruolo autore, Timestamp. 

Dettagli del prodotto: Identificatore/i del prodotto o identificatore della famiglia del prodotto (ad esempio, identificatore univoco o una combinazione di nome del fornitore, nome del prodotto e stringa della versione, come stabilito nelle linee guida SBOM stabilite3). 

Dettagli sulla vulnerabilità: Identificatore della Vulnerabilità (CVE o altri identificatori) e descrizione della vulnerabilità (es. descrizione CVE). 

Stato prodotto Dettagli (ovvero, informazioni sullo stato di una vulnerabilità in quel prodotto): 

• NON INTERESSATO: non è richiesta alcuna riparazione in merito a questa vulnerabilità.
• INTERESSATO – Si consigliano azioni per correggere o affrontare questa vulnerabilità.
• RISOLTO – Queste versioni del prodotto contengono una correzione per la vulnerabilità. 
• SOTTO INDAGINE – Non è ancora noto se queste versioni del prodotto siano interessate dalla vulnerabilità. Un aggiornamento verrà fornito in una versione successiva.

Sommario

In conclusione, sebbene le SBOM siano ancora un’idea nuova per la maggior parte delle organizzazioni, si prevede che la capacità di produrle diventerà più significativa in futuro. Se non hai ancora iniziato a incorporare la creazione della SBOM nel processo di distribuzione del software, questo è il momento ideale per farlo.