Cyber Resilience Act SBOM

SBOM : définition, génération et exigences du Cyber Resilience Act

Un SBOM (software bill of materials, « nomenclature des logiciels » dans le règlement) est la liste des composants d'un logiciel et de leurs relations. À partir du 11 décembre 2027, le Cyber Resilience Act impose au fabricant d'en établir un, dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur de son produit. Il rejoint la documentation technique : le règlement n'oblige pas à le publier. Un outil comme syft ou cdxgen le produit en une commande.

Mis à jour le 25 septembre 2026. Information générale, pas un conseil juridique.

Définition

Le règlement définit la nomenclature des logiciels comme « un document officiel contenant les détails et les relations avec la chaîne d'approvisionnement des différents composants utilisés dans la fabrication d'un produit comportant des éléments numériques » (art. 3, point 39).

Concrètement, c'est un fichier qui décrit chaque bibliothèque, module ou paquet embarqué : son nom, sa version, son fournisseur, un identifiant qui permet de le retrouver dans les bases de vulnérabilités (un purl ou un CPE), sa licence, et ce qui dépend de quoi. Son intérêt est pratique : le jour où une faille est publiée dans une bibliothèque, vous savez en quelques secondes quels produits et quelles versions l'embarquent. C'est la raison qu'en donne le considérant 77 : suivre les vulnérabilités et s'assurer que le produit ne contient pas de composants vulnérables développés par des tiers.

Règlement (UE) 2024/2847, art. 3 point 39, considérant 77 · texte vérifié le 25/09/2026

Exigence (annexe I, partie II, point 1)

Le fabricant « recense et documente les vulnérabilités et les composants des produits, notamment par l'établissement d'une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits ». Ce que cela implique :

• Quand. Pour les produits mis sur le marché à partir du 11 décembre 2027 (art. 71 §2). Un produit mis sur le marché avant n'y est soumis que s'il subit ensuite une modification substantielle (art. 69 §2).
• Où. Dans la documentation technique, avec la politique de divulgation coordonnée et l'adresse de signalement (annexe VII, point 2 b). Voir la checklist du dossier technique.
• Jusqu'où. Le texte exige au moins les dépendances de niveau supérieur : dans la lecture courante, celles que votre produit appelle directement. Il n'exige pas les dépendances transitives, mais la plupart des outils les incluent.
• Sous quelle forme. Le règlement ne nomme aucun format. La Commission peut en préciser le format et les éléments par actes d'exécution (art. 13 §24).
• Pour quoi faire. Le SBOM n'est pas une fin : les vulnérabilités des composants doivent être traitées sans retard (annexe I, partie II, point 2), et signalées à qui maintient le composant (art. 13 §6).

Règlement (UE) 2024/2847, annexe I partie II points 1 et 2, annexe VII point 2 b, art. 13 §6 et §24, art. 69 §2, art. 71 §2

Les formats

Deux formats dominent, tous deux ouverts et lisibles par machine (JSON ou XML) :

• CycloneDX, projet de l'OWASP, normalisé par Ecma International en 2024 sous le nom ECMA-424 (à partir de sa version 1.6). Il décrit aussi les services et les vulnérabilités (VEX), et il est très répandu dans les outils de sécurité applicative.
• SPDX, projet de la Linux Foundation, reconnu comme norme internationale ISO/IEC 5962:2021. Né pour la conformité des licences, il couvre aussi la sécurité.

Le règlement n'en impose aucun. Choisissez celui que lisent vos outils et ceux de vos clients ; si vous partez de zéro, CycloneDX JSON est un choix simple à produire et à exploiter.

Générer : syft, cdxgen

Deux outils libres couvrent la plupart des cas. Lancez-les dans votre chaîne de construction, à chaque version publiée, et conservez le fichier avec la version.

syft (Anchore)

Il analyse un répertoire, une archive ou une image de conteneur :

• un dépôt : syft dir:. -o cyclonedx-json=sbom.cdx.json
• une image, en SPDX : syft mon-image:1.4.2 -o spdx-json=sbom.spdx.json

cdxgen (projet CycloneDX)

Il reconnaît la plupart des écosystèmes (npm, Maven, Gradle, pip, Go, .NET…) :

• l'installer : npm install -g @cdxgen/cdxgen --ignore-scripts
• générer : cdxgen -o bom.json .
• forcer un type de projet : cdxgen -t java -o bom.json

Préférez l'analyse de ce que vous livrez (l'image, l'installateur, le binaire) à celle du seul code source : c'est ce que vos utilisateurs exécutent.

Valider

Un SBOM inexploitable ne sert à rien : composants sans version, sans identifiant, fichier tronqué. Collez le vôtre dans notre validateur de SBOM : il vérifie la structure CycloneDX ou SPDX, les versions, les licences et les identifiants, sans rien envoyer à un serveur. Puis cherchez les vulnérabilités connues de vos composants, par exemple avec grype : grype sbom:./sbom.cdx.json.

Faut-il le publier ?

Non, le règlement ne l'impose pas. Trois textes le montrent :

• le considérant 77 : les fabricants « ne devraient pas être tenus de rendre publique la nomenclature des logiciels » ;
• l'annexe II, point 9 : les informations destinées à l'utilisateur indiquent où consulter le SBOM seulement lorsque le fabricant décide de le mettre à disposition ;
• l'annexe VII, point 8 : il est fourni à une autorité de surveillance du marché sur demande motivée.

Vos clients, eux, peuvent le demander. Ceux qui sont soumis à NIS2 doivent tenir compte de la qualité des produits de leurs fournisseurs (art. 21 §3 de la directive) : voir NIS2 et les éditeurs. Le partager sous contrat avec eux est un choix commercial, pas une obligation du CRA.

Règlement (UE) 2024/2847, considérant 77, annexe II point 9, annexe VII point 8 · directive (UE) 2022/2555, art. 21 §3

En résumé

• Le SBOM liste les composants d'un produit et leurs relations (art. 3, point 39).
• Le CRA l'exige à partir du 11 décembre 2027 : format courant, lisible par machine, au moins les dépendances de niveau supérieur (annexe I, partie II, point 1).
• CycloneDX et SPDX conviennent tous deux ; aucun format n'est imposé.
• syft ou cdxgen le produisent en une commande, à relancer à chaque version.
• Il va dans la documentation technique ; le publier n'est pas obligatoire.

Sources

• Règlement (UE) 2024/2847 (Cyber Resilience Act), EUR-Lex : art. 3, 13, 69 et 71, annexes I, II et VII, considérant 77.
• Directive (UE) 2022/2555 (NIS2), EUR-Lex : art. 21.
• Ecma International, ECMA-424 (CycloneDX) et cyclonedx.org.
• SPDX, présentation (ISO/IEC 5962:2021).
• Documentation de syft, cdxgen et grype, consultée le 25 septembre 2026.