SPDX e CycloneDX: scegliere un formato SBOM
Sytance · Aggiornato
SPDX e CycloneDX descrivono entrambi i componenti software e le relative relazioni. La scelta dipende dalle informazioni richieste dal destinatario e dalle versioni elaborabili dai suoi strumenti. Concordare un formato significa quindi concordarne anche la versione, la codifica e i campi obbligatori.
Esigenze informative del destinatario
Un fornitore di firmware che invia una SBOM a un fabbricante può avere requisiti diversi da quelli di un team che la carica in un servizio di gestione delle vulnerabilità. Le versioni e le codifiche supportate dal destinatario determinano quali file può elaborare. Un file rappresentativo aiuta a confermare tale supporto.
Documentare le informazioni richieste, tra cui identità del prodotto, identificativi dei componenti, relazioni, licenze ed eventuali dati su vulnerabilità o provenienza. Se il destinatario supporta solo una parte del formato, stabilire se i campi omessi incidano sullo scopo dello scambio.
Versioni delle specifiche e supporto degli strumenti
SPDX 2.3 e SPDX 3.0.1 sono specifiche pubblicate distinte. SPDX 3.0.1 usa un modello con profili, tra cui una classe SBOM software. Non si deve presumere che un consumatore che accetta JSON SPDX 2.3 accetti anche un documento 3.x.
La panoramica della specifica CycloneDX elenca la versione 1.7. Il suo modello a oggetti comprende componenti, servizi, relazioni di dipendenza e informazioni sulle vulnerabilità. Un produttore può supportare una specifica recente mentre un importatore a valle supporta una versione precedente.
| Dettaglio dello scambio | Esempio SPDX | Esempio CycloneDX |
|---|---|---|
| Versione | 2.3 o 3.0.1 | 1.7 |
| Identità del documento | Modello documentale specifico della versione | Numero seriale e versione della BOM |
| Dipendenze | Relazioni tipizzate | Grafo delle dipendenze |
| Convalida | Regole per la versione selezionata | Schema per la versione selezionata |
Relazioni e campi delle licenze
In SPDX 2.3, CONTAINS indica il contenimento e DEPENDS_ON una dipendenza. Un pacchetto incluso in un archivio è cosa diversa da un pacchetto necessario a un altro per la compilazione o l’esecuzione. Durante l’importazione, conservare il tipo e la direzione della relazione.
SPDX 2.3 distingue anche tra licenza dichiarata e licenza conclusa. La dichiarazione di un fornitore e la conclusione di un analista non dovrebbero confluire silenziosamente nello stesso campo. Se la distinzione è rilevante per la revisione, lo strumento ricevente deve conservarla.
Per CycloneDX, esaminare il grafo delle dipendenze e i riferimenti ai componenti della versione scelta. Dopo la conversione, un elenco piatto dei componenti può restare leggibile ma perdere i percorsi necessari per capire quali prodotti utilizzino un componente.
Verifica delle informazioni convertite
Un piccolo file di prova può rivelare informazioni perse durante la conversione. Includere un prodotto, una dipendenza diretta e una indiretta. Due versioni dello stesso componente, un’espressione di licenza e un campo esplicitamente contrassegnato come sconosciuto consentono verifiche più approfondite della semplice accettazione del file.
- Convalidare l’originale rispetto alla versione della specifica dichiarata.
- Importarlo nello strumento ricevente e controllare il prodotto di destinazione.
- Confrontare identità dei componenti, versioni e direzione delle relazioni.
- Verificare i campi delle licenze e la rappresentazione delle informazioni sconosciute.
- Se supportato, esportarlo di nuovo e confrontare il significato, non la formattazione del file.
Scelta del formato per la consegna
Se un cliente richiede SPDX 2.3, fornire tale versione con i campi concordati e conservare il record sorgente più ricco se la conversione elimina altri dati. Se il flusso ricevente importa già CycloneDX e conserva il grafo necessario, usare la versione CycloneDX supportata.
Se i clienti necessitano di entrambi i formati, mantenere e collaudare le mappature dei campi tra i due. Documentare le informazioni perse o spostate nelle estensioni durante la conversione. La conversione deve trasformare i dati secondo la specifica di destinazione.
Dopo l’importazione, verificare che il destinatario possa ancora usare le informazioni come previsto. Per l’analisi delle vulnerabilità, ciò significa poter partire da un componente e trovare i prodotti e le release che lo utilizzano.