💻 computer science

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

Dit artikel vergelijkt de SPDX- en CycloneDX-SBOM-toolecosystemen door honderden tools en duizenden issue-rapporten te analyseren, waarbij wordt onthuld dat hoewel SPDX beschikt over een grotere, meer volwassen toolset en bredere adoptie, CycloneDX een sterkere betrokkenheid van ontwikkelaars en specifieke projectgezondheidsindicatoren vertoont, wat de complementaire sterktes van beide formaten benadrukt.

Oorspronkelijke auteurs: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Gepubliceerd 2026-06-12

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een chef bent die een enorm restaurant runt. Om je klanten veilig en tevreden te houden, moet je precies weten welke ingrediënten er in elk gerecht zitten. Je moet de merknaam van de bloem weten, de vervaldatum van de melk, en of bepaalde kruiden afkomstig zijn van een boerderij waar onlangs een besmettingsprobleem was.

In de wereld van software wordt deze "ingrediëntenlijst" een Software Bill of Materials (SBOM) genoemd. Het is een document dat elke stuk code en bibliotheek vermeldt die een softwareprogramma gebruikt.

Het hebben van alleen een lijst is echter niet genoeg; je hebt de juiste tools nodig om de lijst te schrijven, te controleren en bij te werken. Er zijn momenteel twee belangrijke "talen" of formaten om deze lijsten te schrijven: SPDX en CycloneDX. Denk aan ze als twee verschillende merken receptenboeken. De één (SPDX) bestaat sinds 2010 en is zeer traditioneel, terwijl de ander (CycloneDX) in 2017 begon en nieuwer en moderner is.

Dit artikel is een grote studie die de tool-ecosystemen rondom deze twee receptenboeken vergelijt. De onderzoekers keken niet alleen naar de recepten; ze keken naar de keukengereedschappen (softwareprogramma's) die chefs helpen bij het schrijven en beheren van deze lijsten.

Dit is wat ze vonden, eenvoudig uitgelegd:

1. De Keukentool: Wie heeft wat?

De onderzoekers bekeken honderden tools (zowel gratis/open-source als betaald/proprietary) om te zien welke taken ze kunnen uitvoeren.

De "All-rounder" versus de "Specialist": Ze ontdekten dat betaalde (proprietary) tools als meesterchefs zijn die bijna alles kunnen doen: de lijst schrijven, deze analyseren, visualiseren en herstellen. Gratis (open-source) tools zijn, hoewel zeer nuttig, wat beperkter. Ze zijn erg goed in het schrijven van de lijst (het bouwen), maar hebben vaak moeite met fancy visualisatie of diepgaande analyse.
De Formaat-splitsing:
- CycloneDX tools zijn als de "bouwers". Ze zijn uitstekend in het automatisch genereren van de lijst terwijl de software wordt gebouwd.
- SPDX tools zijn als de "bibliothecarissen". Ze zijn erg sterk in het vergelijken van lijsten, het vertalen van de ene naar de andere vorm, en het afhandelen van juridische licentiegegevens.

2. De Community-vibe: Wie is actiever?

De onderzoekers controleerden de "gezondheid" van de communities achter deze tools (hoeveel mensen dragen bij, hoeveel sterren hebben ze op GitHub, hoe snel lossen ze bugs op).

CycloneDX is de energieke nieuwkomer: Hoewel er minder CycloneDX-tools zijn, is de community eromheen veel actiever. Ze hebben meer bijdragers, meer "sterren" (likes) en ze lossen bugs veel sneller op (ongeveer 67% sneller) dan de SPDX-community. Het voelt als een bruisende, snel bewegende startup.
SPDX is de gevestigde veteraan: Het heeft een groter aantal tools en een zeer volwassen, stabiel ecosysteem. Het beweegt echter wat langzamer. Het duurt langer om bugs op te lossen, maar het heeft een zeer sterke focus op juridische en licentieproblemen, wat logisch is omdat het begon als een tool voor het bijhouden van softwarelicenties.

3. Welke problemen lossen ze op?

Het team bekijkte duizenden "bug reports" (klachten of verzoeken om hulp) om te zien waar mensen tegenaan lopen.

CycloneDX worstelt met "Bugs": Omdat het nieuwere is, zijn de meest voorkomende klachten dat er dingen kapot gaan of niet goed werken. De community is druk bezig met het oplossen van deze fundamentele problemen.
SPDX worstelt met "Nieuwe Functies": Omdat het ouder en stabieler is, zijn de meest voorkomende verzoeken gericht op nieuwe functies of verbeteringen. Mensen vragen niet zozeer "waarom is dit kapot?", maar eerder "kun je deze nieuwe coole functie toevoegen?".
De Licentiesnelheid: Als je een probleem hebt met softwarelicenties, lost SPDX dit veel sneller op. Als je een algemene softwarebug hebt, lost CycloneDX dit veel sneller op.

4. Wie gebruikt wat?

De onderzoekers bekeken de 250 meest populaire softwareprojecten om te zien welk "receptenboek" zij gebruiken.

De "Coole" Projecten: Projecten geschreven in moderne talen zoals Go en Python (vaak gebruikt voor security en cloud computing) hebben de voorkeur voor CycloneDX. Deze projecten zijn meestal zeer actief, hebben veel bijdragers en bewegen snel.
De "Enterprise" Projecten: Projecten geschreven in Java en C# (vaak gebruikt in grote bedrijven) hebben de voorkeur voor SPDX. Deze projecten zijn vaak gericht op strikte naleving (compliance) en juridische regels.

De Kernconclusie

Het artikel concludeert dat de keuze tussen SPDX en CycloneDX niet alleen gaat over het kiezen van een formaat; het gaat over het kiezen van het juiste ecosysteem voor je behoeften.

Als je een snel bewegend, security-gericht project bouwt (zoals een cloud-app) en tools nodig hebt die bugs snel oplossen en goed integreren met moderne ontwikkeling, dan is CycloneDX en de actieve community rondom dat formaat wellicht je beste optie.
Als je in een groot bedrijf werkt waar juridische compliance de boventoon voert, en je tools nodig hebt die uitstekend zijn in het vertalen van formaten en het afhandelen van licenties, dan is SPDX en het volwassen, stabiele ecosysteem waarschijnlijk de betere keuze.

Kortom: CycloneDX is de snelle, wendbare bug-fixende machine, terwijl SPDX de betrouwbare, juridisch deskundige veteraan is. Beiden zijn essentieel, maar ze dienen verschillende meesters.

Technische Samenvatting: De Staat van de SBOM-toolecosystemen

Probleemstelling

Moderne software supply chains vertrouwen zwaar op third-party afhankelijkheden, wat aanzienlijke beveiligings- en betrouwbaarheidsrisico's creëert wanneer kwetsbaarheden aanwezig zijn in minder veilige componenten (bijv. Log4Shell, SolarWinds). Hoewel Software Bill of Materials (SBOM's) een cruciaal mechanisme voor transparantie en verantwoording zijn geworden — gemandateerd door de Amerikaanse Executive Order in 2021 en wereldwijd overgenomen — hangt hun nut sterk af van de tools die ze genereren, analyseren en beheren.

Ondanks het bestaan van twee dominante SBOM-formaten, SPDX (gevestigd in 2010) en CycloneDX (geïntroduceerd in 2017), is er een gebrek aan empirisch begrip met betrekking tot de gezondheid, volwassenheid en functionele capaciteiten van de toolecosystemen rond deze formaten. Praktijkgebruikers worden geconfronteerd met uitdagingen bij het selecteren van de juiste tools vanwege beperkte standaardisatie, variërende tool-volwassenheid en een gebrek aan data over welke formaten het beste specifieke use cases ondersteunen (bijv. build-automatisering versus licentiecompliance). Eerdere studies hebben zich gericht op de specificaties zelf of op beperkte enquêtes onder praktijkgebruikers, waardoor er een gat is ontstaan in de kwantitatieve analyse van de daadwerkelijke toolecosystemen.

Methodologie

De auteurs voerden een uitgebreide empirische studie uit waarbij de SPDX- en CycloneDX-ecosystemen werden vergeleken via vier onderzoeksvragen (RQs), gebruikmakend van een meerfasige dataverzameling en -analyse benadering:

Toolverzameling en Classificatie (RQ1):
- Databron: Officiële toolcentra voor CycloneDX (219 tools) en SPDX (47 tools) per 27 januari 2024.
- Filtering: Handmatige verificatie identificeerde 108 open-source (OSS) en 62 propriëtaire tools. 78 tools bleken beide formaten te ondersteunen (Dual-Format).
- Analyse: Twee auteurs categoriseerden handmatig 187 tools (140 CycloneDX, 47 SPDX) met behulp van de NTIA Tool Classification Taxonomy (categorieën Produce, Consume, Transform) via closed-card sorting. Inter-rater betrouwbaarheid werd vastgesteld (Krippendorff's $\alpha$ = 0,872).
Analyse van de Gezondheid van het Ecosysteem (RQ2):
- Dataset: Breidde de OSS-dataset uit met bijdragende forks van GitHub, wat resulteerde in 171 CycloneDX en 470 SPDX repositories.
- Metrics: Geëvalueerd met CHAOSS community health metrics (Stars, Watchers, Forks, Contributors, Pull Requests, Releases, Commits).
- Normalisatie: Alle metrics werden genormaliseerd naar de leeftijd van de repository (dagen) om verschillen in volwassenheid te compenseren. Statistische significantie werd getest met de Mann-Whitney U-test met Bonferroni-correctie.
Analyse van Issue Reports (RQ3):
- Dataset: Extraheerde 36.990 issue reports (post-2018) uit 90 CycloneDX en 191 SPDX tool repositories.
- Taxonomie Constructie: Afgeleid van 14 verschillende issue-categorieën uit getagde issues.
- Classificatie: Valideerde een LLM-gebaseerde annotatie-aanpak (gebruikmakend van mistralai/devstral-small-2-2) tegen menselijke annotatie op een gestratificeerde steekproef (379 issues, $\alpha$ = 0,768). Het model classificeerde alle 33.840 issues.
- Metrics: Analyseerde de prevalentie van issues en de tijd tot oplossing binnen categorieën.
Analyse van Projectadoptie (RQ4):
- Dataset: Identificeerde 2.426 GitHub-projecten die SBOM-tools gebruiken in hun CI-pipelines (gericht op "Build" use cases).
- Selectie: Vergelijking van de top 250 meest 'starred' projecten die uitsluitend CycloneDX-tools gebruiken versus de top 250 die uitsluitend SPDX-tools gebruiken.
- Analyse: Vergelijking van projectgezondheidsmetrics en programmeertaaldistributies (GPL vs. DSL).

Belangrijkste Bijdragen en Resultaten

1. Dekking van Use Cases (RQ1)

Propriëtair versus OSS: Propriëtaire tools ondersteunen een breder scala aan use cases (1,14x meer) dan OSS-tools. Specifiek zijn propriëtaire tools sterker in Analyze en View (visualisatie), terwijl OSS-tools excelleren in Support (integratie/API's).
Verschillen in Formaat:
- CycloneDX-only tools vertonen een sterke positieve associatie met Build en Support use cases, maar missen Diff (vergelijking) ondersteuning.
- SPDX-only tools zijn sterk geassocieerd met Translate (formaatconversie) en Diff, maar tonen beperkte ondersteuning voor Build-tools in de dataset (hoewel de paper vermeldt dat Microsoft GitHub-native SPDX-generatie biedt).
- Dual-format tools zijn prominent aanwezig in Import use cases, maar missen Support capaciteiten.

2. Community Gezondheid van Tools (RQ2)

Engagement: Ondanks het hebben van minder totale repositories (171 vs. 470), vertonen CycloneDX-tools een significant hogere community engagement. Ze hebben hogere mediane waarden voor Stars, Watchers, Forks, Contributors en Pull Requests.
Activiteit: CycloneDX-tools vertonen een hogere commit-activiteit en releasefrequentie.
Terugkerende Contributors: Hoewel er verwaarloosbare verschillen zijn in de ratio van terugkerende contributors over de meeste groepen met een aantal commits, trekken SPDX-tools een hoger volume aan bijdragen van contributors met meer dan 1.000 commits, wat wijst op diepere langetermijnbetrokkenheid bij specifieke high-volume contributors.

3. Prevalentie en Resolutie van Issues (RQ3)

Issue Volume: CycloneDX-tools hebben een hoger gemiddeld aantal genormaliseerde issue reports (zowel open als gesloten) dan SPDX.
Resoltiesnelheid: CycloneDX-tools lossen issues significant sneller op (gemiddeld 67,69% lagere resolutietijd).
- CycloneDX: Wordt gedomineerd door Bug Fixes en Defects (41,90%). Deze worden 174% sneller opgelost dan bij SPDX.
- SPDX: Wordt gedomineerd door Feature Development en Enhancement (36,25%). Lost Licensing issues 51,85% sneller op dan CycloneDX, wat consistent is met de oorsprong van SPDX als een op licenties gericht formaat.
Implicatie: Het CycloneDX-ecosysteem lijkt zich in een fase van snelle bugfixing en stabilisatie te bevinden, terwijl het SPDX-ecosysteem gericht is op feature-expansie en complexe licentiecompliance.

4. Projectadoptiepatronen (RQ4)

Projectgezondheid: Projecten die CycloneDX-tools gebruiken, vertonen hogere community health metrics (meer stars, forks, contributors en commits) vergeleken met projecten die SPDX-tools gebruiken.
Taalvoorkeuren:
- CycloneDX is prevalent in Go en Python projecten (vaak geassocieerd met security-gerichte DevOps en microservices).
- SPDX is prevalent in Java en C# projecten (in lijn met enterprise compliance en formele licentiebehoeften).
Activiteit Correlatie: Projecten met hogere commit-aantallen hebben de neiging tools te gebruiken die View, Diff en Import ondersteunen (Consume categorie), terwijl projecten met lagere activiteit de voorkeur geven aan Edit, Merge en Analyze (Produce/Transform categorieën).

Betekenis en Claims

De paper claimt dat de keuze voor een SBOM-formaat niet in isolatie moet worden gemaakt, maar dat de volwassenheid en gezondheid van het omliggende toolecosysteem in overweging moet worden genomen.

Voor Security-gerichte DevOps: De studie suggereert dat CycloneDX de voorkeur kan hebben voor Go/Python projecten die snelle build-automatisering, bugresolutie en hoge community engagement vereisen.
Voor Enterprise Compliance: SPDX blijft de sterkere keuze voor Java/C# projecten die prioriteit geven aan licentiecompliance, formaattranslatie en diffing, ondersteund door een meer volwassen (doch minder actieve) ecosysteem.
Voor Toolontwikkelaars: De studie identificeert specifieke hiaten: OSS-tools moeten hun Analyze en View capaciteiten verbeteren (momenteel gedomineerd door propriëtaire tools), terwijl SPDX-toolontwikkelaars zich moeten richten op het verminderen van feature-backlogs, en CycloneDX-ontwikkelaars hun hoge bug-fix throughput moeten behouden.
Regulatorische Impact: De analyse merkt een zichtbare verschuiving op in de issue-activiteit na de Amerikaanse overheidsverplichting in 2021 op, wat illustreert hoe regulatoire gebeurtenissen de open-source ontwikkelingsdynamiek op ecosystemiveau hervormen.

De auteurs concluderen dat hoewel beide formaten essentieel zijn, hun toolecosystemen verschillende evolutionaire stadia en prioriteiten vertonen. Het begrijpen van deze verschillen stelt praktijkgebruikers in staat om weloverwogen beslissingen te nemen die aansluiten bij hun specifieke projectbehoeften, taalstacks en compliance-vereisten.