💻 computer science

The State of the SBOM Tool Ecosystems: A Comparative Analysis of SPDX and CycloneDX

Questo articolo confronta gli ecosistemi di strumenti SBOM di SPDX e CycloneDX analizzando centinaia di strumenti e migliaia di segnalazioni di problemi, rivelando che mentre SPDX vanta un set di strumenti più ampio e maturo e un'adozione più vasta, CycloneDX dimostra un maggiore coinvolgimento degli sviluppatori e specifici indicatori di salute del progetto, evidenziando i punti di forza complementari di entrambi i formati.

Autori originali: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Pubblicato 2026-06-12

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere uno chef che gestisce un ristorante enorme. Per mantenere i tuoi clienti al sicuro e felici, devi sapere esattamente quali ingredienti ci sono in ogni piatto che servi. Devi conoscere la marca della farina, la data di scadenza del latte e se alcune spezie provengono da un'azienda agricola che ha avuto un recente problema di contaminazione.

Nel mondo del software, questo "elenco degli ingredienti" si chiama Software Bill of Materials (SBOM). È un documento che elenca ogni pezzo di codice e libreria che un programma software utilizza.

Tuttavia, avere solo un elenco non è sufficiente; serve anche avere gli strumenti giusti per scrivere l'elenco, controllarlo e aggiornarlo. Attualmente esistono due "linguaggi" o formati principali per scrivere questi elenchi: SPDX e CycloneDX. Pensa a loro come a due diversi marchi di libri di ricette. Uno (SPDX) esiste dal 2010 ed è molto tradizionale, mentre l'altro (CycloneDX) è nato nel 2017 ed è più nuovo e moderno.

Questo documento è uno studio approfondito che confronta gli ecosistemi di strumenti che circondano questi due libri di ricette. I ricercatori non si sono limitati a guardare le ricette; hanno esaminato gli strumenti da cucina (programmi software) che aiutano gli chef a scrivere e gestire questi elenchi.

Ecco cosa hanno scoperto, suddiviso in modo semplice:

1. La cucina degli strumenti: Chi ha cosa?

I ricercatori hanno esaminato centinaia di strumenti (sia gratuiti/open-source che a pagamento/proprietari) per vedere quali compiti potevano svolgere.

L' "All-rounder" contro lo "Specialista": Hanno scoperto che gli strumenti a pagamento (proprietari) sono come maestri chef che possono fare quasi tutto: scrivere l'elenco, analizzarlo, visualizzarlo e correggerlo. Gli strumenti gratuiti (open-source), pur essendo molto utili, sono un po' più limitati. Sono ottimi per scrivere l'elenco (costruire), ma spesso faticano con la visualizzazione avanzata o l'analisi profonda.
La divisione dei formati:
- Gli strumenti CycloneDX sono come i "costruttori". Sono eccellenti nel generare automaticamente l'elenco mentre il software viene costruito.
- Gli strumenti SPDX sono come i "bibliotecari". Sono molto forti nel confrontare gli elenchi, nel tradurli da un formato all'altro e nel gestire i dettagli legali sulle licenze.

2. Il "vibe" della comunità: Chi è più attivo?

I ricercatori hanno controllato la "salute" delle comunità dietro questi strumenti (quante persone contribuiscono, quanti "stella" hanno su GitHub, quanto velocemente risolvono i bug).

CycloneDX è il nuovo arrivato energico: Anche se ci sono meno strumenti CycloneDX in totale, la comunità intorno a loro è molto più attiva. Hanno più contributori, più "stelle" (mi piace) e risolvono i bug molto più velocemente (circa il 67% più velocemente) rispetto alla comunità SPDX. Sembra una startup frenetica e veloce.
SPDX è il veterano affermato: Ha un numero maggiore di strumenti e un ecosistema molto maturo e stabile. Tuttavia, si muove più lentamente. Impiega più tempo per correggere i bug, ma ha un focus molto forte sui problemi legali e di licenza, il che ha senso dato che è nato come strumento per tracciare le licenze software.

3. Quali problemi stanno risolvendo?

Il team ha esaminato migliaia di "bug report" (reclami o richieste di aiuto) per vedere di cosa si lamentano le persone.

CycloneDX fatica con i "Bug": Essendo più recente, i problemi più comuni riguardano cose che si rompono o non funzionano correttamente. La comunità è impegnata a risolvere questi problemi fondamentali.
SPDX fatica con le "Nuove Funzionalità": Essendo più vecchio e stabile, le richieste più comuni riguardano nuove funzionalità o miglioramenti. Le persone non chiedono tanto "perché questo è rotto?" quanto "puoi aggiungere questa nuova funzione fantastica?".
La velocità delle licenze: Se hai un problema con le licenze software, SPDX lo risolve molto più velocemente. Se hai un bug software generale, CycloneDX lo risolve molto più velocemente.

4. Chi usa cosa?

I ricercatori hanno esaminato i 250 progetti software più popolari per vedere quale "libro di ricette" utilizzano.

I progetti "Cool": I progetti scritti in linguaggi moderni come Go e Python (spesso usati per la sicurezza e il cloud computing) tendono a preferire CycloneDX. Questi progetti sono solitamente molto attivi, hanno molti contributori e si muovono velocemente.
I progetti "Enterprise": I progetti scritti in Java e C# (spesso usati nelle grandi aziende) tendono a preferire SPDX. Questi progetti sono spesso focalizzati sulla conformità rigorosa e sulle regole legali.

Il punto fondamentale

Il documento conclude che scegliere tra SPDX e CycloneDX non è solo una questione di scegliere un formato; si tratta di scegliere l'ecosistema giusto per le proprie esigenze.

Se stai costruendo un progetto veloce, focalizzato sulla sicurezza (come un'app cloud) e hai bisogno di strumenti che risolvano i bug rapidamente e si integrino bene con lo sviluppo moderno, CycloneDX e la sua comunità attiva potrebbero essere la scelta migliore.
Se ti trovi in una grande azienda dove la conformità legale è la priorità e hai bisogno di strumenti che siano ottimi nel tradurre i formati e gestire le licenze, SPDX e il suo ecosistema maturo e stabile sono probabilmente la scelta migliore.

In breve: CycloneDX è una macchina veloce, agile e specializzata nella risoluzione dei bug, mentre SPDX è il veterano affidabile e esperto di questioni legali. Entrambi sono essenziali, ma servono padroni diversi.

Riepilogo Tecnico: Lo Stato degli Ecosistemi di Strumenti SBOM

Definizione del Problema

Le moderne catene di approvvigionamento del software si affidano pesantemente a dipendenze di terze parti, creando significativi rischi di sicurezza e affidabilità quando esistono vulnerabilità in componenti meno sicuri (ad esempio, Log4Shell, SolarWinds). Sebbene le Software Bill of Materials (SBOM) siano emerse come un meccanismo critico per la trasparenza e la responsabilità — imposto dall'Executive Order degli Stati Uniti nel 2021 e adottato globalmente — la loro utilità dipende fortemente dagli strumenti che le generano, le analizzano e le gestiscono.

Nonostante l'esistenza di due formati dominanti, SPDX (stabilito nel 2010) e CycloneDX (introdotto nel 2017), vi è una mancanza di comprensione empirica riguardante la salute, la maturità e le capacità funzionali degli ecosistemi di strumenti che circondano questi formati. I professionisti affrontano sfide nella selezione degli strumenti corretti a causa della limitata standardizzazione, della variazione della maturità degli strumenti e della mancanza di dati su quali formati supportino meglio specifici casi d'uso (ad esempio, automazione della build rispetto alla conformità delle licenze). Studi precedenti si sono concentrati sulle specifiche stesse o su sondaggi limitati tra i professionisti, lasciando un vuoto nell'analisi quantitativa degli effettivi ecosistemi di strumenti.

Metodologia

Gli autori hanno condotto uno studio empirico completo confrontando gli ecosistemi SPDX e CycloneDX attraverso quattro Domande di Ricerca (RQ), utilizzando un approccio di raccolta e analisi dei dati in più fasi:

Raccolta e Classificazione degli Strumenti (RQ1):
- Fonte dei Dati: Centri ufficiali degli strumenti per CycloneDX (219 strumenti) e SPDX (47 strumenti) al 27 gennaio 2024.
- Filtraggio: La verifica manuale ha identificato 108 strumenti open-source (OSS) e 62 proprietari. 78 strumenti sono risultati supportare entrambi i formati (Dual-Format).
- Analisi: Due autori hanno categorizzato manualmente 187 strumenti (140 CycloneDX, 47 SPDX) utilizzando la Tassonomia di Classificazione degli Strumenti NTIA (categorie Produce, Consume, Transform) tramite sorting a carte chiuse. È stata stabilita l'affidabilità inter-valutatore (Krippendorff's $\alpha$ = 0,872).
Analisi della Salute dell'Ecosistema (RQ2):
- Dataset: Il dataset OSS è stato ampliato includendo i fork contribuenti da GitHub, risultando in 171 repository CycloneDX e 470 SPDX.
- Metriche: Valutate utilizzando le metriche di salute della comunità CHAOSS (Stars, Watchers, Forks, Contributori, Pull Requests, Release, Commit).
- Normalizzazione: Tutte le metriche sono state normalizzate per età del repository (giorni) per tenere conto delle differenze di maturità. La significatività statistica è stata testata con il test Mann-Whitney U con correzione di Bonferroni.
Analisi dei Rapporti sui Problemi (RQ3):
- Dataset: Estratti 36.990 rapporti di problemi (post-2018) da 90 repository di strumenti CycloneDX e 191 SPDX.
- Costruzione della Tassonomia: Derivate 14 categorie distinte di problemi dai tag degli issue.
- Classificazione: Validato un approccio di annotazione basato su LLM (utilizzando mistralai/devstral-small-2-2) rispetto all'annotazione umana su un campione casuale stratificato (379 issue, $\alpha$ = 0,768). Il modello ha classificato tutti i 33.840 problemi.
- Metriche: Analizzata la prevalenza dei problemi e i tempi di risoluzione tra le categorie.
Analisi dell'Adozione dei Progetti (RQ4):
- Dataset: Identificati 2.426 progetti GitHub che utilizzano strumenti SBOM nelle loro pipeline CI (focalizzandosi sui casi d'uso "Build").
- Selezione: Confrontati i primi 250 progetti con più stelle che utilizzano solo strumenti CycloneDX rispetto ai primi 250 che utilizzano solo strumenti SPDX.
- Analisi: Confrontate le metriche di salute del progetto e le distribuzioni dei linguaggi di programmazione (GPL vs. DSL).

Contributi Chiave e Risultati

1. Copertura dei Casi d'Uso (RQ1)

Proprietario vs. OSS: Gli strumenti proprietari supportano una gamma più ampia di casi d'uso (1,14x di più) rispetto agli strumenti OSS. Nello specifico, gli strumenti proprietari sono più forti in Analyze e View (visualizzazione), mentre gli strumenti OSS eccellono in Support (integrazione/API).
Differenze di Formato:
- Gli strumenti solo CycloneDX mostrano una forte associazione positiva con i casi d'uso Build e Support, ma mancano di supporto per Diff (confronto).
- Gli strumenti solo SPDX sono fortemente associati a Translate (conversione di formato) e Diff, ma mostrano un supporto limitato per gli strumenti di Build nel dataset (sebbene il paper noti che Microsoft fornisce la generazione nativa per GitHub in formato SPDX).
- Gli strumenti a doppio formato sono prevalenti nei casi d'uso di Import, ma mancano di capacità di Support.

2. Salute della Comunità degli Strumenti (RQ2)

Engagement: Nonostante abbiano meno repository totali (171 vs. 470), gli strumenti CycloneDX esibiscono un coinvolgimento della comunità significativamente più alto. Hanno valori mediani più elevati per Stars, Watchers, Forks, Contributori e Pull Requests.
Attività: Gli strumenti CycloneDX mostrano un'attività di commit e una frequenza di rilascio superiori.
Contributori Ricorrenti: Mentre ci sono differenze trascurabili nel tasso di contributori ricorrenti nella maggior parte dei gruppi di conteggio commit, gli strumenti SPDX attirano un volume maggiore di contributi da parte di collaboratori con oltre 1.000 commit, suggerendo un impegno a lungo termine più profondo in specifici contributori ad alto volume.

3. Prevalenza dei Problemi e Risoluzione (RQ3)

Volume dei Problemi: Gli strumenti CycloneDX hanno un numero medio di rapporti sui problemi normalizzati (sia aperti che chiusi) superiore rispetto a SPDX.
Velocità di Risoluzione: Gli strumenti CycloneDX risolvono i problemi significativamente più velocemente (tempo di risoluzione mediamente inferiore del 67,69%).
- CycloneDX: Dominato da Bug Fixes e Difetti (41,90%). Risolve questi problemi il 174% più velocemente di SPDX.
- SPDX: Dominato da Sviluppo di Funzionalità e Miglioramenti (36,25%). Risolve i problemi di Licenza il 51,85% più velocemente di CycloneDX, in linea con le origini di SPDX come formato focalizzato sulla conformità delle licenze.
Implicazione: L'ecosistema CycloneDX sembra essere in una fase di rapida risoluzione dei bug e stabilizzazione, mentre l'ecosistema SPDX è focalizzato sull'espansione delle funzionalità e sulla conformità complessa delle licenze.

4. Modelli di Adozione dei Progetti (RQ4)

Salute del Progetto: I progetti che utilizzano strumenti CycloneDX dimostrano metriche di salute della comunità più elevate (più stelle, fork, contributori e commit) rispetto a quelli che utilizzano strumenti SPDX.
Preferenze Linguistiche:
- CycloneDX è prevalente nei progetti Go e Python (spesso associati a DevOps orientati alla sicurezza e microservizi).
- SPDX è prevalente nei progetti Java e C# (allineandosi alla conformità enterprise e alle esigenze formali di licenza).
Correlazione di Attività: I progetti con un numero di commit più elevato tendono a utilizzare strumenti che supportano View, Diff e Import (categoria Consume), mentre i progetti con minore attività preferiscono Edit, Merge e Analyze (categorie Produce/Transform).

Significato e Rivendicazioni

Il paper sostiene che la scelta di un formato SBOM non debba essere fatta isolatamente, ma debba considerare la maturità e la salute dell'ecosistema di strumenti circostante.

Per il DevOps focalizzato sulla Sicurezza: Lo studio suggerisce che CycloneDX potrebbe essere preferibile per i progetti Go/Python che richiedono un'automazione rapida della build, risoluzione dei bug e un alto coinvolgimento della comunità.
Per la Conformità Enterprise: SPDX rimane la scelta più forte per i progetti Java/C# che danno priorità alla conformità delle licenze, alla traduzione dei formati e al diffing, supportata da un ecosistema più maturo (sebbene meno attivo).
Per gli Sviluppatori di Strumenti: Lo studio identifica lacune specifiche: gli strumenti OSS devono migliorare le capacità di Analyze e View (attualmente dominate dagli strumenti proprietari), mentre gli sviluppatori di strumenti SPDX dovrebbero concentrarsi sulla riduzione dei backlog delle funzionalità, e gli sviluppatori di CycloneDX dovrebbero mantenere il loro alto throughput di risoluzione dei bug.
Impatto Regolatorio: L'analisi nota un'inflessione visibile nell'attività dei problemi a seguito del mandato del governo degli Stati Uniti del 2021, illustrando come gli eventi normativi rimodellino le dinamiche dello sviluppo open-source su scala di ecosistema.

Gli autori concludono che, sebbene entrambi i formati siano essenziali, i loro ecosistemi di strumenti esibiscono fasi evolutive e priorità distinte. Comprendere queste differenze consente ai professionisti di prendere decisioni informate che si allineino alle loro specifiche esigenze di progetto, stack linguistici e requisiti di conformità.