CycloneDX ou SPDX : quel format de SBOM choisir ?
Par l'équipe Lysbor · publié le · 4 min de lecture
Vous avez décidé de produire un SBOM, et deux noms reviennent partout : CycloneDX et SPDX. La réponse courte : pour suivre les vulnérabilités de vos dépendances, prenez CycloneDX en JSON. Si un client ou un partenaire exige SPDX, fournissez-le aussi, les outils savent produire les deux. La réponse longue suit, pour comprendre pourquoi.
Les deux formats sont comme deux modèles de fiche d'inventaire. L'un a été dessiné par des responsables sécurité qui voulaient savoir quoi réparer, l'autre par des juristes qui voulaient savoir sous quelle licence chaque pièce avait été achetée. Aujourd'hui, les deux fiches ont chacune ajouté les colonnes de l'autre.
Deux origines, deux cultures
SPDX (Software Package Data Exchange) est né en 2010 au sein de la Linux Foundation pour résoudre un problème juridique : savoir sous quelle licence est distribué chaque fichier d'un logiciel open source. Il est devenu la norme internationale ISO/IEC 5962:2021. La version 3.0, publiée en 2024, a élargi son modèle à la sécurité, à l'intelligence artificielle et aux données.
CycloneDX est né en 2017 dans la communauté OWASP, celle de la sécurité applicative, pour décrire les composants d'une application afin d'en suivre les vulnérabilités. Il a été standardisé par Ecma International sous la référence ECMA-424. Il couvre nativement les vulnérabilités, le VEX, les services, les configurations matérielles et les modèles d'IA.
Comparatif point par point
| Critère | CycloneDX | SPDX |
|---|---|---|
| Organisation | OWASP, standard Ecma (ECMA-424) | Linux Foundation, norme ISO/IEC 5962 |
| Conçu d'abord pour | sécurité et risque | licences et conformité |
| Vulnérabilités et VEX | intégrés au format | via extensions et profils (SPDX 3.0) |
| Formats de fichier | JSON, XML, Protocol Buffers | JSON, YAML, tag-value, RDF |
| Identifiant de composant | purl, CPE, SWID | purl, CPE via références externes |
| Outils de génération | Syft, cdxgen, Trivy, plugins Maven et Gradle | Syft, Trivy, outils SPDX, GitHub (export) |
| Lecture par les outils de sécurité | quasi universelle | très large |
Deux points méritent d'être soulignés :
- Le purl (package URL) est l'élément qui compte vraiment pour la sécurité. Un composant identifié par
pkg:pypi/django@4.2.1se compare sans ambiguïté aux bases de vulnérabilités. Les deux formats le supportent. Vérifiez simplement que votre outil de génération le renseigne. - La richesse du format ne sert à rien si le contenu est pauvre. Un SBOM SPDX complet vaut mieux qu'un CycloneDX à moitié vide. La qualité dépend de l'outil qui génère, pas du format.
Quel format pour quel besoin
Vous voulez surveiller vos vulnérabilités en continu. CycloneDX JSON. C'est le format le plus directement consommé par les outils de suivi (OWASP Dependency-Track, Lysbor, Trivy, Grype…) et il transporte nativement le statut des vulnérabilités.
Un client, un donneur d'ordre ou un marché public exige un format. Donnez le format demandé. Syft, par exemple, produit les deux à partir de la même analyse :
syft dir:. -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.jsonVous préparez la conformité au Cyber Resilience Act. Le règlement demande un SBOM « dans un format couramment utilisé et lisible par machine » sans imposer l'un ou l'autre. Les deux conviennent. Voir notre guide Cyber Resilience Act et SBOM.
Votre juriste audite les licences open source. SPDX reste la référence historique, avec sa liste d'identifiants de licences (MIT, Apache-2.0, GPL-3.0-only…) que CycloneDX réutilise d'ailleurs lui aussi.
Les pièges à éviter
- Mélanger des versions de format sans le savoir. CycloneDX 1.4, 1.5, 1.6 et SPDX 2.3 ou 3.0 n'ont pas exactement les mêmes champs. Un outil ancien peut refuser un fichier récent. Notez la version produite par votre CI.
- Générer le SBOM depuis le code source au lieu de l'artefact livré. Le dossier du dépôt ne contient pas les paquets système de l'image Docker qui part en production. Pour un service conteneurisé, générez aussi le SBOM de l'image.
- Oublier les dépendances transitives. Un SBOM qui ne liste que le
package.json(dépendances directes) passe à côté de l'essentiel. Partez toujours du lockfile ou d'une analyse de l'artefact. - Considérer le format comme la fin du travail. Le fichier n'a de valeur que confronté régulièrement à une base de vulnérabilités à jour.
Ce qu'accepte Lysbor
Lysbor lit CycloneDX (JSON et XML) et SPDX (JSON), ainsi que directement les lockfiles des principaux écosystèmes, et produit en sortie un export CycloneDX et un document VEX à partir de vos décisions. Vous pouvez donc commencer avec le fichier que vous avez déjà, sans convertir quoi que ce soit, et tester un lockfile sans compte pour voir le résultat.
Questions fréquentes
Peut-on convertir un SBOM CycloneDX en SPDX ?
Oui, des outils de conversion existent, notamment dans l'écosystème CycloneDX (cyclonedx-cli) et SPDX. La conversion peut perdre des informations propres à un format, comme les données de vulnérabilités. Le plus propre reste de générer les deux formats depuis la même analyse.
Quel format demande le Cyber Resilience Act ?
Aucun en particulier. Le texte exige un SBOM dans un format couramment utilisé et lisible par machine. CycloneDX et SPDX remplissent tous deux cette condition.
JSON ou XML pour CycloneDX ?
JSON, sauf contrainte particulière. C'est le format le plus répandu dans les outils et les API, et le plus simple à inspecter à la main.