CycloneDX o SPDX: l’ecosistema più grande non è quello più attivo

SPDX ha un ecosistema di strumenti SBOM più ampio, ma i repository degli strumenti CycloneDX risultano più attivi in alcune metriche. Lo studio comparativo sugli ecosistemi esamina 470 strumenti SPDX e 171 CycloneDX; per i commit normalizzati, la mediana dei repository CycloneDX è 438 contro 122 per SPDX. Sono misure del campione studiato, non un giudizio sulla qualità di ogni singolo strumento.

Per scegliere il formato, parti dal dato che deve arrivare al destinatario. CycloneDX è una scelta sensata quando il flusso riguarda componenti, dipendenze e vulnerabilità, mentre SPDX merita particolare attenzione se gli strumenti di conformità usano i suoi profili per le licenze. La specifica CycloneDX 1.7 comprende anche servizi, licenze, informazioni sulla sfruttabilità e casi VEX: la preferenza iniziale non esclude quindi gli altri usi del formato.

Che cosa misura l’attività degli strumenti

Un catalogo più ampio offre più possibilità di trovare un generatore, un validatore o un sistema capace di ricevere uno SBOM. Questo è il vantaggio pratico dell’ampiezza rilevata per SPDX, soprattutto quando un’azienda deve inserirsi in una pipeline già adottata da clienti o fornitori. Il numero complessivo degli strumenti, però, non indica quali versioni della specifica e quali dati ciascuno sappia trattare.

L’attività di un repository risponde a una domanda diversa: segnala quanto si muove il progetto che sviluppa lo strumento. Commit e contributori possono aiutare a individuare candidati da esaminare, ma non misurano la copertura delle dipendenze nel file prodotto. Anche i progetti che adottano strumenti CycloneDX mostrano maggiore coinvolgimento in alcuni indicatori dello studio: quel risultato riguarda i progetti osservati, non tutti gli utilizzatori del formato.

Sicurezza e licenze: le capacità dei due standard

CycloneDX può collegare componenti e servizi nel grafo delle dipendenze e comunicare vulnerabilità insieme al contesto della loro sfruttabilità. Per un flusso di gestione del rischio, questa struttura permette di associare un problema al componente interessato e di trasmettere una valutazione VEX. Il formato offre i campi; per stabilire se una vulnerabilità incide davvero su un prodotto servono informazioni che il generatore potrebbe non ricavare dall’inventario delle dipendenze.

SPDX tratta a sua volta la sicurezza. Nella specifica SPDX 3.0.1 sulla conformità, il profilo Core è obbligatorio, mentre Security e Licensing sono opzionali: il primo consente di scambiare informazioni sulle vulnerabilità e sul loro effetto, il secondo riguarda licenze e relative espressioni. La dicitura «supporta SPDX» da sola non dice se uno strumento importi o esporti i profili necessari.

Per le licenze, il profilo Licensing di SPDX distingue la licenza rilevata nel software dalla conclusione formulata da chi crea i dati SPDX; se differiscono, prevede una spiegazione. CycloneDX può rappresentare informazioni sulle licenze dei componenti. La differenza utile nella scelta è quindi il contenuto che generatore e destinatario riescono effettivamente a scambiare, non un’esclusiva delle licenze attribuita a un formato.

Una matrice per le esigenze di un fornitore italiano

Per un’impresa italiana che sviluppa software o lo integra in un prodotto, la preferenza iniziale cambia secondo lo scopo della consegna. Questi quattro casi separano il requisito informativo dalla disponibilità concreta degli strumenti.

• Gestione delle vulnerabilità. Parti da CycloneDX se devi trasmettere relazioni fra componenti e servizi insieme a informazioni sulla sfruttabilità o dichiarazioni VEX. Valuta SPDX se generatore e sistema di analisi gestiscono il profilo Security richiesto. In entrambi i casi, un componente identificato in modo incompleto rende difficile collegare l’avviso alla versione presente nel prodotto.
• Verifica delle licenze. Parti da SPDX quando il destinatario richiede il profilo Licensing e deve distinguere la licenza rilevata da quella conclusa nell’analisi. CycloneDX resta utilizzabile se il flusso ricevente accetta le informazioni sulle licenze che esporti. Controlla la provenienza del dato: una licenza copiata dai metadati di un pacchetto non equivale a una conclusione documentata sulle condizioni d’uso.
• Richieste dei clienti. Se il cliente specifica formato, versione e contenuto obbligatorio, sono questi i vincoli della consegna. Se chiede genericamente uno SBOM, chiarisci se gli serve l’inventario dei componenti, un’analisi delle licenze o il contesto delle vulnerabilità. La stessa etichetta può indicare file con informazioni diverse, anche quando entrambi rispettano la sintassi del proprio formato.
• Interoperabilità della pipeline. Scegli il formato che generatore, validatore e sistema ricevente gestiscono nella versione necessaria. Verifica sia l’esportazione sia l’importazione: un file formalmente valido può perdere utilità se il sistema finale ignora relazioni, identificativi o profili. Se i destinatari usano strumenti incompatibili fra loro, considera due esportazioni dello stesso rilascio.

Il generatore determina quanto entra nello SBOM

La capacità di uno standard di descrivere un dato non garantisce che quel dato compaia nel file. Un’analisi empirica dei generatori SBOM ha confrontato tre strumenti su oltre 3.000 progetti JavaScript e Rust, rilevando differenze nella copertura delle dipendenze e nella completezza degli output legate anche a scelte su ambito, nomi e provenienza dei componenti.

Il confronto utile riguarda dunque lo stesso rilascio prodotto dai generatori candidati. Metti a confronto componenti diretti e transitivi, versioni, identificativi e relazioni con le dipendenze note del progetto; poi importa i file nel sistema che dovrà usarli. Per la sicurezza, verifica se il contesto necessario alla valutazione della vulnerabilità sopravvive al passaggio. Per le licenze, distingui i valori rilevati automaticamente dalle conclusioni della revisione.

Quando hanno senso entrambe le esportazioni

Produrre CycloneDX e SPDX è ragionevole se destinatari diversi chiedono contenuti o formati differenti, oppure se gli strumenti già in uso non condividono un formato gestito in modo adeguato. Le due esportazioni dovrebbero riferirsi allo stesso rilascio e alla stessa base di componenti: inventari costruiti separatamente rendono più difficile spiegare eventuali discrepanze. Per SPDX, indica anche i profili richiesti; per entrambi, concorda la versione e i dati indispensabili.

Se un solo formato attraversa la pipeline e conserva tutte le informazioni necessarie, una seconda uscita aggiunge verifiche senza risolvere un’esigenza di scambio. La scelta finale riguarda quindi il contenuto che serve al destinatario e la qualità dell’output degli strumenti disponibili.

Leggi anche:

• Slack o Teams: il prezzo conta meno dell’ecosistema che già paghi
• Comprare IA non basta: il 69% delle aziende ha fermato almeno un progetto
• DNSSEC attivo ma il dominio non risponde: controllare DS, RRSIG e resolver