CycloneDX ou SPDX ? Choisir un format de SBOM
Sur cette page
Deux normes ouvertes se partagent presque toutes les nomenclatures des logiciels (SBOM, selon le terme du CRA) : CycloneDX et SPDX. Toutes deux sont reconnues au niveau international, lues par tous les outils sérieux, et acceptées pour le Cyber Resilience Act, qui demande seulement « un format couramment utilisé et lisible par machine ». Le choix compte moins que de produire un SBOM complet pour chaque version. Mais elles ne viennent pas du même endroit, et leurs différences comptent pour certains usages.
Si les SBOM sont nouveaux pour vous, commencez par Qu’est-ce qu’un SBOM ?.
En un coup d’œil
| CycloneDX | SPDX | |
|---|---|---|
| Organisme responsable | OWASP et Ecma International (TC54) | Linux Foundation |
| Création | 2017, pour la sécurité applicative | 2010, pour la conformité des licences open source |
| Norme formelle | ECMA-424 (1re édition : version 1.6, 2e édition : version 1.7) | ISO/IEC 5962:2021 (version 2.2.1) |
| Version actuelle | 1.7 (octobre 2025) | 3.0.1 (décembre 2024) |
| Formats de fichier | JSON, XML, Protocol Buffers | 3.x : JSON-LD ; 2.x : JSON, YAML, XML, tag-value, RDF/XML, tableur |
| Au-delà du logiciel | Services (SaaS), matériel, micrologiciel, modèles d’IA, cryptographie, fabrication | Profils sécurité, IA, jeux de données, build, licences |
| Vulnérabilités et VEX | Intégrés | Profil sécurité (3.x) ; le plus souvent un document VEX séparé |
| Licences | Identifiants et expressions de licence SPDX | Natif, la référence pour les licences |
CycloneDX : pensé pour la sécurité
CycloneDX a été conçu par la communauté OWASP pour répondre vite à une question : quelles vulnérabilités connues touchent ce que je livre ? Son modèle est une liste de composants avec leurs identifiants (URL de paquet, CPE, empreintes), un graphe de dépendances, et des sections facultatives pour les vulnérabilités, leur analyse et les services qu’un produit appelle.
C’est pratique quand le SBOM alimente un processus de gestion des vulnérabilités. Un document CycloneDX peut porter directement les informations VEX : pour chaque vulnérabilité, si le produit est touché et pourquoi. Il décrit aussi plus que des bibliothèques : nomenclatures matérielles, services SaaS, modèles d’apprentissage automatique et éléments cryptographiques d’un produit.
SPDX : pensé pour les licences, désormais plus large
SPDX (Software Package Data Exchange) est né pour échanger les informations de licence des paquets open source, et il reste la référence en la matière : les identifiants de licence SPDX (MIT, Apache-2.0, GPL-3.0-only) sont utilisés partout, y compris dans CycloneDX. Ses versions 2.x décrivent paquets, fichiers et extraits avec leurs licences, droits d’auteur et relations.
SPDX 3.0, publié en 2024, a refondu le modèle autour d’éléments et de relations, avec des profils : sécurité (vulnérabilités et relations VEX), IA et jeux de données, build, et un profil « lite » pour le minimum. Les outils n’ont pas encore rattrapé la 3.x ; beaucoup de générateurs produisent la 2.3 par défaut.
Ce qu’acceptent le CRA et les autorités
Le CRA n’impose aucun format. Le BSI allemand, dont la directive technique TR-03183-2 (version 2.1, août 2025) est la lecture la plus détaillée à ce jour, accepte CycloneDX 1.6 ou plus récent et SPDX 3.0.1 ou plus récent, en JSON ou en XML. Les éléments minimaux américains (NTIA, puis CISA) citent aussi les deux. Quel que soit votre choix, une autorité regardera le contenu : chaque composant avec une version, un fournisseur et un identifiant unique, les dépendances, et un SBOM par version.
Lequel choisir
- Vous visez surtout la gestion des vulnérabilités et le CRA : CycloneDX. Le VEX tient dans le même fichier, les outils de sécurité sont les plus mûrs, et la 1.6 atteint dès aujourd’hui le niveau du BSI.
- Vos juristes travaillent déjà avec SPDX pour les licences, ou un client l’exige : SPDX, idéalement 3.0.1 dès que vos outils la gèrent (la 2.3, encore la plus courante, ne répond pas à la directive du BSI).
- Vous vendez à de nombreux clients : produisez l’un, exportez l’autre. La conversion est possible, avec quelques pertes de détail, car les deux modèles ne se correspondent pas champ pour champ.
Ce qui compte plus que le format :
- Produire le SBOM dans la chaîne de compilation, à chaque version, jamais à la main.
- Donner à chaque composant une URL de paquet, pour le rapprocher des bases de vulnérabilités.
- Lister les dépendances indirectes, pas seulement les directes.
- Valider le fichier contre le schéma officiel avant de le publier ou de l’archiver.
Vous pouvez ouvrir un fichier CycloneDX ou SPDX dans notre visionneuse et vérificateur de SBOM gratuit pour voir ses composants et ce qui manque.
Les outils qui produisent et convertissent
La plupart des générateurs écrivent les deux : Syft, Trivy et cdxgen produisent CycloneDX et SPDX (cdxgen écrit du SPDX 3.0.1) ; sbom-tool de Microsoft vise SPDX ; les extensions CycloneDX pour Maven, Gradle, npm, .NET et Python écrivent du CycloneDX. GitHub peut exporter le graphe de dépendances d’un dépôt en SPDX. Pour convertir et valider, la CLI CycloneDX et les outils SPDX sont les références, et le projet protobom de l’OpenSSF convertit de l’un à l’autre par un modèle neutre.
Ce que fait Provetry
Provetry écrit le SBOM de chaque version en CycloneDX 1.6 avec toutes les offres, et en SPDX 2.3 et SPDX 3.0.1 avec les offres payantes, depuis votre CI ou à partir des fichiers de verrouillage envoyés, et garde chacun avec sa version.