Per creare prodotti software o applicazioni sicuri in quest'epoca è necessaria una conoscenza completa degli esatti componenti dell'applicazione che si sta creando. Le dipendenze, le licenze, i file e le altre risorse che compongono il pacchetto software sono potenziali punti di vulnerabilità attraverso i quali gli autori malintenzionati possono lanciare un attacco al software e ad altre applicazioni lungo la catena di fornitura.
Nell'ambito degli sforzi per combattere il recente aumento della frequenza e dell'impatto di attacchi alle catene di fornitura del software, il governo federale, in coordinamento con la NTIA, ha emesso un ordine esecutivo che descrive dettagliatamente varie misure per migliorare la sicurezza informatica e garantire l'integrità dei componenti di terze parti utilizzati nei pacchetti software. Una di queste misure è la Distinta base software.
Si tratta di un documento formale che contiene tutti i componenti di un pacchetto software e le relazioni della catena di fornitura tra questi componenti. La preparazione di una distinta base software completa non è solo una pratica standard, ma è anche richiesta dalla legge. Questo post definisce l'ambito della distinta base del software e il elementi minimi che deve essere incluso in una distinta base completa.
Cosa forniscono i componenti minimi NTIA di una SBOM?
La SBOM funge da guida formale per le aziende che realizzano, acquistano o utilizzano software, fornendo tutte le informazioni necessarie per migliorare la loro comprensione della catena di fornitura del software. Aiuta anche a rintracciare facilmente le vulnerabilità emergenti qualora si verificassero ridurre i rischi della catena di fornitura del software. Tuttavia, affinché la SBOM soddisfi i requisiti stabiliti dal governo federale, ci sono alcuni elementi di base che dovrebbe contenere. Questi elementi sono spesso classificati in tre categorie:
- Campi dati: Si prevede che una SBOM fornisca dati importanti sui componenti software come il nome del componente, il nome del fornitore, la versione del software e altri identificatori univoci. Dovrebbe anche dettagliare le relazioni tra le dipendenze. Questi dati consentono di identificare con precisione tutti i componenti software e di rintracciarli lungo tutta la catena di fornitura del software.
- Supporto all'automazione: La distinta base del software dovrebbe essere leggibile dalla macchina e anche in grado di essere generata automaticamente. Ciò consente il monitoraggio continuo dei dati inclusi nella SBOM. Di solito, questi documenti sono in formati standard come i tag SPDX, CycloneDX e SWID e questo li rende leggibili anche dall'uomo.
- Pratiche e processi: Si prevede inoltre che la documentazione SBOM descriva in dettaglio le pratiche e i processi standard per la preparazione e l'aggiornamento della SBOM. Dovrebbe includere anche pratiche per la distribuzione e l'accesso alla SBOM nonché misure per la gestione degli errori accidentali.
Gli elementi minimi richiesti da NTIA della documentazione SBOM forniscono un criterio chiaro di ciò che è previsto in una linea guida SBOM per i casi d'uso di base della distinta base del software, come la gestione delle vulnerabilità, l'inventario dei componenti software e la gestione delle licenze software. Il framework è in fase di aggiornamento e potrebbe includere elementi aggiuntivi che ne estendono l'usabilità nel prossimo futuro. Nelle sezioni successive di questa pagina, spiegheremo più dettagliatamente questi componenti chiave della distinta base del software. Gli elementi minimi richiesti di una distinta base del software includono sette campi dati come specificato di seguito.
Campi dati: requisiti minimi
Lo scopo della distinta base del software è fornire informazioni che aiutino gli utenti e le altre parti interessate a identificare facilmente i componenti del software. Presumibilmente, uno dei primi e più importanti elementi della SBOM sono i dati che dovrebbero essere inclusi per ogni componente dettagliato nel documento. Oltre a facilitare l'identificazione dei singoli componenti, i dati facilitano anche il tracciamento dei componenti nei vari punti in cui vengono utilizzati nella catena di fornitura del software.
- Nome del fornitore: Il fornitore è l'ideatore o il produttore del componente software in questione. Questo è il nome dell'individuo o dell'organizzazione che crea, definisce e identifica i componenti software.
- Nome Componente: si riferisce al nome designato assegnato al software come definito dal fornitore o produttore originale. Nei casi in cui sono presenti più nomi e alias per il software, è possibile che vengano annotati anche questi.
- Versione componente: La SBOM dovrebbe includere il numero di rilascio o il numero di categoria come specificato dal fornitore o dal produttore. I dati della versione fungono da identificatore che specifica qualsiasi modifica nel software rispetto a una versione precedentemente identificata della successiva versione del software.
- Altri identificatori univoci: Si riferisce a identificatori aggiuntivi diversi dal nome e dalla versione del componente. Questi identificatori aggiuntivi forniscono un ulteriore livello di identificazione per il componente e possono essere utilizzati anche come chiave di ricerca per trovare il componente nei database pertinenti.
- Relazione di dipendenza: Questo è uno dei componenti di dati più importanti di una distinta base software, poiché la SBOM ha lo scopo di dettagliare il modo in cui i componenti software si incastrano tra loro. La relazione di dipendenza specifica la relazione tra il software X utilizzato all'interno dell'applicazione e i suoi componenti a monte.
- Autore dei dati SBOM: Si riferisce all'individuo che ha creato i dati SBOM. A volte, il fornitore del software può anche fungere anche da autore. Tuttavia, in molti casi, l'autore è un altro individuo o gruppo.
Supporto per l'automazione: requisiti minimi
L'uso della distinta base del software spesso supera i confini dell'organizzazione. Ciò significa che i dati contenuti nella SBOM vengono spesso utilizzati da più reparti all'interno di un'organizzazione e anche da più organizzazioni. Per garantire la facilità d'uso di questa documentazione, NTIA consiglia che la SBOM sia in un formato leggibile sia dalla macchina che dall'uomo. La preparazione e la trasmissione della SBOM in formati automatizzati standard come questo migliora l'interoperabilità di questo documento per i vari scopi previsti.
La NTIA riconosce tre formati di consegna per la generazione e la trasmissione di SBOM. La distinta base del software deve corrispondere a uno di questi formati per essere conforme agli standard stabiliti dal ordine esecutivo del governo sulla sicurezza informatica. Questi formati standard includono:
- Scambio di dati del pacchetto software (SPDX)
- Tag di identificazione del software (SWID).
- CicloneDX
Scambio di dati del pacchetto software (SPDX)
SPDX è uno standard aperto per la fornitura di dati SBOM. Cattura informazioni importanti sul software inclusi i suoi componenti, provenienza, licenze e copyright. Fornisce inoltre riferimenti alla sicurezza. IL SPDX la versione 2.2 è la versione più recente e supporta il tipo di file YAML 1.2, JavaScript Object Notation e Resource Description Framework (RDF/XML). tag: file di testo flat di valore e fogli di calcolo .xls
Tag di identificazione del software (SWID).
I tag SWID sono progettati per aiutare a identificare e contestualizzare i componenti di qualsiasi prodotto software. Il progetto Tag di identificazione del software (SWID Tags) è un insieme di strumenti per generare e validare i tag di identificazione di un software. Questi strumenti basati su Java supportano tag SWID XML basati sul formato standardizzato definito da ISO/IEC 19770-2:2015 e Concise Binary Object Representation (CBOR). IL Il NIST ha un sito web con un elenco di risorse utili per:
- Creazione di tag SWID e CoSWID
- Convalida dei tag SWID e CoSWID in base ai requisiti specifici dello schema e alle linee guida sulle migliori pratiche
- Un'app Web che fornisce un servizio di convalida dei tag SWID che può essere distribuito su un server di applicazioni Java
- Client repo SWID per la pubblicazione di tag nel database nazionale delle vulnerabilità
CicloneDX
CicloneDX afferma di essere uno "standard leggero di distinta base software (SBOM)". È utile per l'analisi dei componenti della catena di fornitura e la sicurezza delle applicazioni. Le organizzazioni che adottano CycloneDX possono soddisfare perfettamente i requisiti minimi SBOM e maturare nel tempo in casi d'uso più sofisticati della documentazione SBOM.
Le SBOM CycloneDX vengono generalmente presentate nei formati XML, JSON o Buffer di protocollo. La specifica spesso include questi cinque campi:
- Metadati della distinta base: includono le informazioni generali sull'applicazione o sul prodotto software stesso.
- Componenti: si tratta di un inventario completo che copre tutti i componenti proprietari e open source del software.
- Informazioni sui servizi: dettaglia tutte le API esterne che l'applicazione probabilmente chiamerà durante il suo funzionamento. Include tutti gli URL degli endpoint, i requisiti di autenticazione e gli attraversamenti dei limiti di attendibilità.
- Dipendenze: la documentazione descrive in dettaglio anche tutti i componenti e i servizi all'interno del pacchetto software. Ciò include sia le relazioni dirette che quelle transitive.
- Composizioni: si riferisce alla completezza di tutte le parti costitutive compresi i singoli componenti, servizi e relazioni di dipendenza. Ogni composizione viene in genere descritta in termini di complete, incomplete, solo di terze parti incomplete, solo di terze parti incomplete o completamente sconosciute.
Pratiche e processi: requisiti minimi
L'elemento finale della distinta base del software si concentra sui meccanismi di utilizzo della SBOM stessa. Le pratiche e i processi coprono i dettagli operativi della generazione e dell'utilizzo della SBOM e devono essere inclusi in qualsiasi politica o contratto che lo richieda. Di seguito sono riportati i requisiti chiave che devono essere dettagliati nella sezione Pratiche e processi della distinta base del software:
- Frequenza: Questa sezione descrive in dettaglio la frequenza con cui un'organizzazione deve generare una nuova fattura software per i materiali. In genere, NTIA consiglia di generare una nuova SBOM ogni volta che il componente software viene aggiornato o viene rilasciata una nuova versione. Si prevede inoltre che i fornitori generino nuove SBOM ogni volta che rilevano un errore nella versione originale o apprendono nuovi dettagli sui componenti del loro software che non erano inclusi nella documentazione iniziale.
- Profondità: La profondità della tua SBOM dipende da cosa è incluso nel documento. Per essere conforme, è previsto che la SBOM includa tutti i componenti di livello superiore e tutte le dipendenze transitive. Nelle situazioni in cui l'autore non è in grado di includere tutte le dipendenze transitive, il documento dovrebbe indicare al consumatore dove trovarle.
- Esistono casi in cui l'autore della SBOM non può fornire un grafico delle dipendenze completo per un motivo o per l'altro. Ciò può accadere perché il componente non ha ulteriori dipendenze oppure non si sa se queste dipendenze esistono o meno. L'autore della SBOM è tenuto a specificare questo motivo.
- Distribuzione e consegna: L'obiettivo di questo requisito è garantire che le SBOM vengano consegnate rapidamente e in un formato facilmente digeribile. Sebbene questo requisito non specifichi il numero di giorni o settimane entro i quali è prevista la consegna delle SBOM, è necessario consegnarle il più rapidamente possibile. Inoltre, la SBOM dovrebbe disporre di ruoli e autorizzazioni di accesso appropriati impostati al momento della consegna. Infine, il requisito prevede che la SBOM possa essere distribuita con ogni istanza del prodotto o resa disponibile in qualsiasi altro modo facilmente accessibile, ad esempio tramite un sito Web pubblico.
- Controllo di accesso: Nei casi in cui il fornitore decide di limitare l'accesso ai dati SBOM a specifici utenti o clienti, l'autore è tenuto a specificare i termini di controllo degli accessi. È inoltre necessario offrire agevolazioni specifiche ai consumatori che desiderano integrare i dati SBOM nei propri strumenti di sicurezza.
- Sistemazione degli errori: SBOM può aiutare a migliorare la sicurezza del software e gestione del rischio della catena di fornitura del software. Tuttavia, è ancora lontano dall’essere perfetto. Pertanto, i consumatori devono essere tolleranti nei confronti degli errori o delle omissioni occasionali e non intenzionali che possono verificarsi nella preparazione delle SBOM.
Pensare oltre i requisiti minimi di NTIA
Finora abbiamo discusso gli elementi minimi richiesti nella distinta base del software. Questi elementi minimi rappresentano i requisiti consigliati, in particolare per i casi d'uso più basilari di questa documentazione. Sebbene costituiscano una buona base per la provenienza e la sicurezza del software, è necessario guardare oltre questi requisiti. Di seguito sono riportati alcuni consigli da considerare per i casi d'uso SBOM più avanzati.
Campi dati aggiuntivi
Oltre ai campi dati trattati nel documento sui requisiti minimi, esistono campi dati aggiuntivi consigliati nei casi in cui è necessario un livello di sicurezza più elevato. Alcuni di questi campi dati aggiuntivi includono:
- Un hash crittografico dei componenti software
- Dati sulla fase del ciclo di vita del software
- Relazioni tra altri componenti
- Informazioni sulla licenza
Software basato su cloud e Software-as-a-Service
Un'altra potenziale area in cui i requisiti SBOM potrebbero andare oltre i fondamenti è la gestione dei prodotti Software-as-a-Service (SaaS). Questi tipi di prodotti software presentano sfide uniche per quanto riguarda i dati SBOM. Innanzitutto, i rischi per la sicurezza nel contesto cloud sono unici. Inoltre, la responsabilità della gestione di tali rischi spetta al fornitore di servizi. Anche la preparazione della documentazione SBOM per il software basato su cloud è più complessa poiché tendono ad avere un ciclo di rilascio più breve.
Integrità e autenticità di SBOM
Un altro probabile problema che vale la pena notare è il processo di autenticazione dell'origine dei dati SBOM stessi. Attualmente, le firme e l'infrastruttura a chiave pubblica sono le soluzioni di riferimento per verificare l'integrità del software nel mondo digitale di oggi. Gli autori e i fornitori di SBOM potrebbero dover sfruttare queste firme software esistenti per migliorare l'affidabilità dei dati SBOM.
Vulnerabilità e sfruttabilità nelle dipendenze
Sebbene lo scopo delle SBOM sia facilitare il rilevamento delle vulnerabilità, è importante notare che non tutte le vulnerabilità nelle dipendenze costituiscono rischi importanti per il software che si basa su di esse. Per evitare sprechi di tempo e risorse, i fornitori di software dovranno mettere in atto misure per determinare i potenziali impatti di una vulnerabilità di dipendenza sul software che utilizza a valle e comunicare il livello di rischio (o la mancanza di esso in questo caso) agli utenti della SBOM dati a valle.
Flessibilità vs. Uniformità nell'implementazione
Ogni volta che si parla di sicurezza del software, la questione della flessibilità e dell’uniformità viene sempre in primo piano. Ciò vale anche per i casi d'uso avanzati delle SBOM. Per implementare con successo le SBOM saranno necessarie politiche di ampio respiro che si applichino a tutte le aree, nonché a casi specifici in cui sarà necessaria flessibilità.