💻 computer science

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

Cet article compare les écosystèmes d'outils SBOM de SPDX et de CycloneDX en analysant des centaines d'outils et des milliers de rapports d'incidents, révélant que si SPDX bénéficie d'un ensemble d'outils plus vaste et plus mature ainsi que d'une adoption plus large, CycloneDX démontre un engagement plus fort des développeurs et des indicateurs de santé de projet spécifiques, mettant en évidence les forces complémentaires des deux formats.

Auteurs originaux : Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Publié 2026-06-12

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un chef dirigeant un restaurant immense. Pour garantir la sécurité et le bonheur de vos clients, vous devez savoir exactement quels ingrédients composent chaque plat que vous servez. Vous devez connaître la marque de la farine, la date d'expiration du lait et savoir si certaines épices proviennent d'une ferme ayant subi une récente contamination.

Dans le monde du logiciel, cette « liste d'ingrédients » est appelée un Software Bill of Materials (SBOM) (un bordereau de composants logiciels). Il s'agit d'un document qui répertorie chaque morceau de code et chaque bibliothèque qu'un programme informatique utilise.

Cependant, posséder simplement une liste ne suffit pas ; il vous faut les outils adéquats pour rédiger la liste, la vérifier et la mettre à jour. Il existe actuellement deux « langages » ou formats principaux pour rédiger ces listes : SPDX et CycloneDX. Considérez-les comme deux marques différentes de livres de recettes. L'une (SPDX) existe depuis 2010 et est très traditionnelle, tandis que l'autre (CycloneDX) a débuté en 2017 et est plus récente et moderne.

Ce document est une étude approfondie qui compare les écosystèmes d'outils entourant ces deux livres de recettes. Les chercheurs n'ont pas seulement examiné les recettes ; ils ont examiné les outils de cuisine (programmes logiciels) qui aident les chefs à rédiger et à gérer ces listes.

Voici ce qu'ils ont découvert, décomposé simplement :

1. La cuisine des outils : Qui possède quoi ?

Les chercheurs ont examiné des centaines d'outils (tant gratuits/open-source que payants/propriétaires) pour voir quelles tâches ils pouvaient accomplir.

L'« Touche-à-tout » contre le « Spécialiste » : Ils ont constaté que les outils payants (propriétaires) sont comme des chefs étoilés capables de presque tout faire : rédiger la liste, l'analyser, la visualiser et la corriger. Les outils gratuits (open-source), bien qu'extrêmement utiles, sont un peu plus limités. Ils sont excellents pour rédiger la liste (la construction), mais peinent souvent avec la visualisation sophistiquée ou l'analyse approfondie.
La division des formats :
- Les outils CycloneDX sont comme les « constructeurs ». Ils sont excellents pour générer automatiquement la liste au fur et à mesure que le logiciel est construit.
- Les outils SPDX sont comme les « bibliothécaires ». Ils sont très performants pour comparer les listes, les traduire d'un format à un autre et gérer les détails juridiques de licence.

2. L'ambiance de la communauté : Qui est le plus actif ?

Les chercheurs ont vérifié la « santé » des communautés derrière ces outils (combien de personnes contribuent, combien d'étoiles elles ont sur GitHub, à quelle vitesse elles corrigent les bugs).

CycloneDX est le nouveau venu énergique : Même s'il y a moins d'outils CycloneDX au total, la communauté qui les entoure est beau$ beaucoup plus active. Elle possède plus de contributeurs, plus d'« étoiles » (mentions j'aime) et elle corrige les bugs beaucoup plus vite (environ 67 % plus vite) que la communauté SPDX. On a l'impression d'être dans une startup dynamique et rapide.
SPDX est le vétéran établi : Il possède un plus grand nombre d'outils et un écosystème très mature et stable. Cependant, il évolue plus lentement. Il faut plus de temps pour corriger les bugs, mais il possède un accent très fort sur les questions juridiques et de licence, ce qui est logique puisqu'il a commencé comme un outil de suivi des licences logicielles.

3. Quels problèmes résolvent-ils ?

L'équipe a examiné des milliers de « rapports de bugs » (plaintes ou demandes d'aide) pour voir ce qui pose problème aux utilisateurs.

CycloneDX lutte contre les « Bugs » : Comme il est plus récent, les plaintes les plus courantes concernent des dysfonctionnements ou des problèmes de fonctionnement. La communauté est occupée à corriger ces problèmes fondamentaux.
SPDX lutte contre les « Nouvelles fonctionnalités » : Comme il est plus ancien et plus stable, les demandes les plus fréquentes concernent de nouvelles fonctionnalités ou des améliorations. Les gens ne demandent pas autant « pourquoi est-ce cassé ? » que « pouvez-vous ajouter cette nouvelle fonctionnalité géniale ? ».
La rapidité des licences : Si vous avez un problème avec les licences logicielles, SPDX le résout beaucoup plus vite. Si vous avez un bug logiciel général, CycloneDX le résout beaucoup plus vite.

4. Qui utilise quoi ?

Les chercheurs ont examiné les 250 projets logiciels les plus populaires pour voir quel « livre de recettes » ils utilisent.

Les projets « branchés » : Les projets écrits dans des langages modernes comme Go et Python (souvent utilisés pour la sécurité et le cloud computing) ont tendance à préférer CycloneDX. Ces projets sont généralement très actifs, comptent de nombreux contributeurs et progressent rapidement.
Les projets « Entreprise » : Les projets écrits en Java et C# (souvent utilisés dans les grandes entreprises) ont tendance à préférer SPDX. Ces projets sont souvent axés sur la conformité stricte et les règles juridiques.

Le mot de la fin

Le document conclut que choisir entre SPDX et CycloneDX ne revient pas seulement à choisir un format ; il s'agit de choisir le bon écosystème pour vos besoins.

Si vous construisez un projet rapide, axé sur la sécurité (comme une application cloud) et que vous avez besoin d'outils qui corrigent les bugs rapidement et s'intègrent bien au développement moderne, CycloneDX et sa communauté active pourraient être votre meilleur choix.
Si vous travaillez dans une grande entreprise où la conformité juridique est reine, et que vous avez besoin d'outils capables de traduire les formats et de gérer les licences, SPDX et son écosystème mature et stable est probablement le meilleur choix.

En résumé : CycloneDX est une machine rapide, agile et spécialisée dans la correction de bugs, tandis que SPDX est le vétéran fiable et expert en droit. Les deux sont essentiels, mais ils ne servent pas les mêmes maîtres.

Résumé technique : L'état des écosystèmes d'outils SBOM

Énoncé du problème

Les chaînes d'approvisionnement logicielles modernes dépendent fortement de dépendances tierces, ce qui crée des risques significatifs en matière de sécurité et de fiabilité lorsque des vulnérabilités existent dans des composants moins sécurisés (ex. : Log4Shell, SolarWinds). Bien que les SBOM (Software Bill of Materials) soient apparus comme un mécanisme critique de transparence et de responsabilité — imposés par l'ordre exécutif américain en 2021 et adoptés mondialement — leur utilité dépend fortement des outils qui les génèrent, les analysent et les gèrent.

Malgré l'existence de deux formats de SBOM dominants, SPDX (établi en 2010) et CycloneDX (introduit en 2017), il existe une compréhension empirique limitée concernant la santé, la maturité et les capacités fonctionnelles des écosystèmes d'outils entourant ces formats. Les praticiens sont confrontés à des difficultés pour choisir les bons outils en raison d'une standardisation limitée, d'une maturité variable des outils et d'un manque de données sur les formats qui supportent le mieux des cas d'utilisation spécifiques (ex. : automatisation de la construction vs conformité des licences). Les études précédentes se sont concentrées sur les spécifications elles-mêmes ou sur des enquêtes limitées auprès des praticiens, laissant un vide dans l'analyse quantitative des écosystèmes d'outils réels.

Méthodologie

Les auteurs ont mené une étude empirique complète comparant les écosystèmes SPDX et CycloneDX à travers quatre questions de recherche (RQ), en utilisant une approche de collecte et d'analyse de données en plusieurs étapes :

Collecte et classification des outils (RQ1) :
- Source de données : Centres d'outils officiels pour CycloneDX (219 outils) et SPDX (47 outils) au 27 janvier 2024.
- Filtrage : Une vérification manuelle a identifié 108 outils open-source (OSS) et 62 outils propriétaires. 78 outils ont été identifiés comme supportant les deux formats (Dual-Format).
- Analyse : Deux auteurs ont catégorisé manuellement 187 outils (140 CycloneDX, 47 SPDX) en utilisant la taxonomie de classification d'outils de la NTIA (catégories Produce, Consume, Transform) via un tri par cartes fermées. La fiabilité inter-juges a été établie (Krippendorff's $\alpha$ = 0,872).
Analyse de la santé de l'écosystème (RQ2) :
- Jeu de données : Expansion du jeu de données OSS pour inclure les forks de contribution de GitHub, résultant en 171 dépôts CycloneDX et 470 dépôts SPDX.
- Métriques : Évaluation via les métriques de santé communautaire CHAOSS (Étoiles, Observateurs, Forks, Contributeurs, Pull Requests, Releases, Commits).
- Normalisation : Toutes les métriques ont été normalisées par l'âge du dépôt (jours) pour tenir compte des différences de maturité. La signification statistique a été testée avec le test U de Mann-Whitney avec correction de Bonferroni.
Analyse des rapports de problèmes (RQ3) :
- Jeu de données : Extraction de 36 990 rapports de problèmes (post-2018) à partir de 90 dépôts d'outils CycloneDX et 191 dépôts SPDX.
- Construction de la taxonomie : Dérivation de 14 catégories de problèmes distinctes à partir des problèmes tagués.
- Classification : Validation d'une approche d'annotation basée sur un LLM (utilisant mistralai/devstral-small-2-2) par rapport à une annotation humaine sur un échantillon aléatoire stratifié (379 problèmes, $\alpha$ = 0,768). Le modèle a classifié l'ensemble des 33 840 problèmes.
- Métriques : Analyse de la prévalence des problèmes et des temps de résolution par catégorie.
Analyse de l'adoption des projets (RQ4) :
- Jeu de données : Identification de 2 426 projets GitHub utilisant des outils SBOM dans leurs pipelines CI (focalisation sur les cas d'utilisation "Build").
- Sélection : Comparaison des 250 projets les plus étoilés n'utilisant que des outils CycloneDX par rapport aux 250 utilisant uniquement des outils SPDX.
- Analyse : Comparaison de la santé des projets et des distributions de langages de programmation (GPL vs DSL).

Contributions clés et résultats

1. Couverture des cas d'utilisation (RQ1)

Propriétaire vs OSS : Les outils propriétaires supportent une gamme plus large de cas d'utilisation (1,14x plus) que les outils OSS. Plus précisément, les outils propriétaires sont plus forts dans les cas Analyze et View (visualisation), tandis que les outils OSS excellent dans le Support (intégration/APIs).
Différences de format :
- Les outils uniquement CycloneDX montrent une forte association positive avec les cas d'utilisation Build et Support, mais manquent de support pour le Diff (comparaison).
- Les outils uniquement SPDX sont fortement associés à Translate (conversion de format) et Diff, mais présentent un support limité pour les outils de Build dans le jeu de données (bien que l'article note que Microsoft fournit une génération SPDX native pour GitHub).
- Les outils à double format sont prévalents dans les cas d'utilisation Import mais manquent de capacités de Support.

2. Santé communautaire des outils (RQ2)

Engagement : Malgré un nombre total de dépôts plus faible (171 contre 470), les outils CycloneDX présentent un engagement communautaire nettement plus élevé. Ils possèdent des valeurs médianes plus élevées pour les Étoiles, Observateurs, Forks, Contributeurs et Pull Requests.
Activité : Les outils CycloneDX affichent une activité de commit et une fréquence de release plus élevées.
Contributeurs récurrents : Bien qu'il y ait des différences négligeables dans le taux de contributeurs récurrents à travers la plupart des groupes de nombre de commits, les outils SPDX attirent un volume plus élevé de contributions de la part de contributeurs ayant plus de 1 000 commits, suggérant un engagement à long terme plus profond chez certains contributeurs à haut volume.

3. Prévalence et résolution des problèmes (RQ3)

Volume de problèmes : Les outils CycloneDX ont un nombre moyen de rapports de problèmes normalisés (ouverts et fermés) plus élevé que SPDX.
Vitesse de résolution : Les outils CycloneDX résolvent les problèmes nettement plus rapidement (temps de résolution moyen 67,69 % inférieur à celui de SPDX).
- CycloneDX : Dominé par les Corrections de bugs et défauts (41,90 %). Résout ces problèmes 174 % plus vite que SPDX.
- SPDX : Dominé par le Développement de fonctionnalités et améliorations (36,25 %). Résout les problèmes de Licence 51,85 % plus vite que CycloneDX, ce qui est cohérent avec les origines de SPDX en tant que format axé sur les licences.
Implication : L'écosystème CycloneDX semble être dans une phase de correction rapide des bugs et de stabilisation, tandis que l'écosystème SPDX est concentré sur l'expansion des fonctionnalités et la conformité complexe des licences.

4. Modèles d'adoption de projets (RQ4)

Santé des projets : Les projets utilisant des outils CycloneDX démontrent une meilleure santé communautaire (plus d'étoiles, de forks, de contributeurs et de commits) par rapport à ceux utilisant des outils SPDX.
Préférences de langage :
- CycloneDX est prévalent dans les projets Go et Python (souvent associés au DevOps axé sur la sécurité et aux microservices).
- SPDX est prévalent dans les projets Java et C# (s'alignant sur la conformité d'entreprise et les besoins formels de licence).
Corrélation d'activité : Les projets avec un nombre de commits plus élevé ont tendance à utiliser des outils supportant View, Diff et Import (catégorie Consume), tandis que les projets moins actifs préfèrent Edit, Merge et Analyze (catégories Produce/Transform).

Signification et affirmations

L'article affirme que le choix d'un format SBOM ne doit pas se faire de manière isolée mais doit prendre en compte la maturité et la santé de l'écosystème d'outils environnant.

Pour le DevOps axé sur la sécurité : L'étude suggère que CycloneDX peut être préférable pour les projets Go/Python nécessitant une automatisation rapide de la construction, une résolution de bugs rapide et un engagement communautaire élevé.
Pour la conformité d'entreprise : SPDX reste le choix le plus robuste pour les projets Java/C# privilégiant la conformité des licences, la traduction de format et le diffing, soutenu par un écosystème plus mature (bien que moins actif).
Pour les développeurs d'outils : L'étude identifie des lacunes spécifiques : les outils OSS doivent améliorer leurs capacités Analyze et View (actuellement dominées par les outils propriétaires), tandis que les développeurs d'outils SPDX devraient se concentrer sur la réduction des arriérés de fonctionnalités, et les développeurs de CycloneDX devraient maintenir leur haut débit de correction de bugs.
Impact réglementaire : L'analyse note une inflexion visible dans l'activité des problèmes suite au mandat du gouvernement américain de 2021, illustrant comment les événements réglementaires façonnent la dynamique du développement open-source à l'échelle de l'écosystème.

Les auteurs concluent que bien que les deux formats soient essentiels, leurs écosystèmes d'outils présentent des stades d'évolution et des priorités distincts. Comprendre ces différences permet aux praticiens de prendre des décisions éclairées qui s'alignent sur leurs besoins spécifiques, leurs piles de langages et leurs exigences de conformité.