Exigences SBOM du CRA : format, périmètre, mises à jour et conservation
Le CRA impose à tout produit comportant des éléments numériques d'être livré avec un SBOM (Software Bill of Materials) lisible par machine, qui recense ses composants logiciels et couvre au moins leurs dépendances de niveau supérieur. Le SBOM se trouve dans votre documentation technique et doit être prêt pour une autorité de surveillance du marché sur demande, sans dépôt préalable.
Synthèse
- Tout produit comportant des éléments numériques a besoin d'un SBOM lisible par machine au titre de ses preuves de gestion des vulnérabilités. C'est obligatoire, sans exemption liée à la taille.
- Le minimum légal couvre les dépendances de niveau supérieur. La couverture des dépendances transitives est une pratique plus solide et ce qu'attendent la plupart des cadres qualité SBOM.
- Un produit signifie un seul corpus de preuves SBOM, même quand le produit est assemblé à partir de nombreux dépôts ou composants.
- Maintenez le SBOM à jour pendant la période d'assistance, notamment après les versions, les changements de composants et les décisions relatives aux vulnérabilités.
- Conservez le SBOM avec la documentation technique pendant au moins 10 ans, ou pendant la période d'assistance si celle-ci est plus longue.
- Les obligations de signalement des vulnérabilités commencent le 11 septembre 2026 ; l'application intégrale du CRA intervient le 11 décembre 2027.
Qu'est-ce qu'un SBOM ?
Un SBOM (Software Bill of Materials), ou nomenclature des logiciels, est un inventaire structuré du logiciel présent dans un produit : bibliothèques, frameworks, paquets du système d'exploitation et les dépendances entre eux. Pour le CRA, c'est le document qu'une autorité de surveillance du marché utiliserait pour vérifier lesquels de vos composants sont touchés par une vulnérabilité signalée, il doit donc être lisible par machine plutôt qu'un document en prose.
Ce que le CRA exige dans un SBOM
L'obligation SBOM comporte deux couches pratiques : ce que l'inventaire doit couvrir et où la preuve doit se trouver dans le dossier technique.
Quels composants le SBOM doit-il couvrir ?
Les fabricants doivent recenser et documenter les composants et les vulnérabilités de leurs produits comportant des éléments numériques, et établir un SBOM dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur du produit.
Cela signifie :
- Le SBOM doit être lisible par machine et dans un format couramment utilisé. Un PDF ou un tableur peut aider à passer l'inventaire en revue, mais ne remplace pas le fichier SBOM.
- Il doit couvrir au moins les dépendances de niveau supérieur. La couverture des dépendances transitives va au-delà du strict plancher, et c'est la meilleure base pour la surveillance des vulnérabilités.
Tout produit comportant des éléments numériques mis sur le marché de l'UE doit disposer d'un SBOM lisible par machine. Il n'existe aucune dérogation ni seuil de taille en dessous duquel l'obligation disparaît. Le niveau de détail que vous documentez s'adapte au risque du produit, mais l'obligation d'établir un SBOM, elle, ne varie pas.
Pour l'instant, les règles demandent seulement un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur. Elles ne nomment ni un format précis ni une liste de champs fixe. Ce plancher peut être relevé : le CRA laisse à la Commission la possibilité de définir plus tard un format et un jeu de champs SBOM exacts. Choisir dès maintenant un format bien pris en charge, CycloneDX ou SPDX, et capturer plus que le strict minimum reste la meilleure protection face à un futur format imposé.
Où le SBOM se place dans le dossier technique
Le SBOM fait partie de votre documentation technique, classé aux côtés des autres preuves de gestion des vulnérabilités : la politique de divulgation coordonnée des vulnérabilités, une adresse de contact pour le signalement et la manière dont vous distribuez les mises à jour de façon sécurisée. Vous ne le soumettez pas à l'avance. Il doit exister lorsque le produit est mis sur le marché de l'UE et être prêt pour une autorité de surveillance du marché si elle formule une demande motivée.
En pratique, le SBOM devrait vous permettre le suivi des vulnérabilités au niveau des composants, les vérifications de fournisseur et d'origine, la revue des licences et la planification de fin de vie.
Combien de SBOM faut-il pour un produit ?
Un produit est souvent assemblé à partir de nombreux dépôts et composants, et chacun peut émettre son propre SBOM. Le CRA fixe l'unité de preuve au niveau du produit, pas du dépôt ni du build.
Le CRA définit un SBOM comme un document des composants présents dans le logiciel d'un produit et de la façon dont ils sont liés, et il attend de ce document qu'il couvre au moins les dépendances de niveau supérieur du produit. L'objet de preuve, c'est le produit que vous mettez sur le marché de l'UE, identifié par produit et version. Un produit assemblé à partir de dix dépôts n'est pas couvert par dix SBOM de composants épars que rien ne relie. Vous devez des preuves SBOM qui représentent le produit tel qu'il est livré.
Le CRA n'impose pas un fichier physique unique, et il n'interdit pas de conserver des SBOM de composants. Deux voies fonctionnent toutes les deux, tant que le résultat est lisible par machine, se situe au niveau du produit et couvre au moins les dépendances de niveau supérieur :
- Composer. Conservez les SBOM de composants comme documents distincts et reliez-les dans un SBOM produit, à l'aide des composants d'assemblage CycloneDX avec références BOM-Link, ou des relations SPDX avec références à des documents externes.
- Fusionner. Aplatissez chaque composant dans un seul document CycloneDX ou SPDX pour la version du produit.
Parce que le SBOM est censé capturer la façon dont les composants sont liés, une simple liste de noms de paquets ne suffit pas à elle seule. Quelle que soit la voie choisie, le SBOM devrait montrer comment les composants dépendent les uns des autres et se contiennent, ce que fournissent à la fois les graphes de dépendances CycloneDX et les relations SPDX. Pour les mécanismes de format, voyez CycloneDX vs SPDX.
Qui doit recevoir le SBOM ?
Le SBOM est un élément du dossier technique, pas un document public. Le CRA ne vous impose pas de le publier, et la seule partie qui peut l'exiger est une autorité de surveillance du marché, qui peut le demander sur demande motivée lorsqu'elle a besoin de vérifier votre conformité. Partager le SBOM avec les utilisateurs est facultatif. Si vous choisissez de le partager avec eux, vous devez alors leur indiquer où le consulter.
| Qui | Ce qu'attend le CRA |
|---|---|
| Autorité de surveillance du marché | Peut demander le SBOM sur demande motivée, lorsque c'est nécessaire pour vérifier la conformité |
| Utilisateurs et public | Aucune obligation de le publier ou de le remettre ; le partage relève de votre choix |
| Importateurs et distributeurs | Aucun droit au SBOM lui-même ; ils doivent pouvoir obtenir votre documentation technique pour la transmettre aux autorités sur demande |
| Intégrateurs qui construisent sur votre produit | Lorsque votre produit est destiné à être intégré au leur, vous leur donnez les informations dont ils ont besoin pour remplir leurs propres obligations, ce qui n'est pas automatiquement l'intégralité du SBOM |
Ne publiez pas le SBOM et ne le poussez pas vers les utilisateurs par défaut. Un SBOM est une cartographie précise de vos composants et de leurs versions, c'est-à-dire exactement ce que recherche un attaquant, et le CRA ne vous oblige pas à le diffuser largement. Remettez-le à une autorité de surveillance du marché lorsqu'elle formule une demande motivée, et aux clients professionnels qui construisent sur votre produit, sous accord de confidentialité ou contrat, parce qu'ils en ont besoin pour assembler leur propre SBOM au niveau produit et remplir leurs obligations. Gardez une trace de qui a reçu quelle version.
Ce que le SBOM doit contenir
Séparez le plancher légal du CRA des champs qui rendent le SBOM utile dans de vrais flux de gestion des vulnérabilités. Le règlement fixe le minimum. TR-03183, les outils CycloneDX/SPDX et les attentes clients poussent généralement le niveau opérationnel plus haut.
| Domaine | Plancher CRA | Mise en oeuvre solide |
|---|---|---|
| Format | Couramment utilisé et lisible par machine | CycloneDX JSON/XML ou SPDX JSON/tag-value, généré par les outils de build |
| Périmètre | Au moins les dépendances de niveau supérieur | Dépendances directes et transitives, bibliothèques internes, firmware et paquets OS le cas échéant |
| Composants | Composants contenus dans le produit | Nom, version, fournisseur, PURL ou CPE, hachage et relations |
| Vulnérabilités | Composants et vulnérabilités recensés et documentés | Statut actuel des vulnérabilités, décision VEX ou d'exploitabilité, référence de correction et date de revue |
| Preuve technique | SBOM inclus dans les preuves du processus de gestion des vulnérabilités | Référence stable du fichier par version produit, outil de génération, date de génération et résultat de validation |
| Accès des autorités | Disponible si nécessaire en cas de demande motivée d'une autorité de surveillance du marché | Archive sécurisée avec responsable de récupération, contrôles d'intégrité et couverture de la période d'assistance |
Le CRA vous impose de recenser et documenter les vulnérabilités, mais cela ne veut pas dire que les données de vulnérabilité ou VEX doivent figurer dans le fichier SBOM lui-même. Les y faire figurer est une bonne pratique, pas un plancher. Pour les exigences de champs qui vont au-delà de cette liste (identifiants PURL, valeurs de hachage, métadonnées du document), voyez comment la BSI TR-03183 étend le CRA. Pour une comparaison des outils CycloneDX et SPDX, voyez CycloneDX vs SPDX.
À quoi ressemble une synthèse SBOM de dossier technique
Un dossier technique solide associe le SBOM lisible par machine à un court enregistrement de synthèse. La synthèse est une page de garde pour la revue humaine. Le SBOM réel est le fichier CycloneDX ou SPDX joint vers lequel elle pointe.
SYNTHÈSE SBOM DU DOSSIER TECHNIQUE
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (génération), Trivy (analyse)
FICHIER SBOM :
sbom-ssp3000-v2.4.1.json (joint, lisible par machine)
SYNTHÈSE DES COMPOSANTS :
-------------------------------------------------------------
Total des composants : 127
Dépendances directes : 23
Dépendances transitives : 104
Par type :
Bibliothèques : 98
Frameworks : 12
Système d'exploitation : 1 (FreeRTOS)
Modules firmware : 16
STATUT DES VULNÉRABILITÉS À L'ÉVALUATION :
-------------------------------------------------------------
Date d'analyse : 2027-01-17
Scanner : Trivy v0.48.0
Critiques : 0
Élevées : 0
Moyennes : 2 (acceptées, voir ci-dessous)
VULNÉRABILITÉS ACCEPTÉES :
CVE-2026-15432 (Moyenne) : libexpat 2.5.0
Statut : non exploitable dans notre configuration
Justification : fonctionnalité désactivée, chemin de code non atteignable
Date de revue : 2027-04-15
-------------------------------------------------------------
Quand mettre à jour votre SBOM
Le SBOM n'est pas un document ponctuel. Votre documentation technique doit être établie avant la mise sur le marché du produit et tenue à jour, lorsque cela est approprié, au moins pendant la période d'assistance. La période d'assistance reflète la durée pendant laquelle le produit est censé être utilisé, et elle est d'au moins cinq ans, sauf si le produit est réellement censé être utilisé moins longtemps.
Revoyez ou régénérez le SBOM lorsque :
| Déclencheur | Ce qui change | Action pratique |
|---|---|---|
| Nouvelle version firmware ou logicielle | Nouvel artefact de build | Régénérer le SBOM pour cette version du produit |
| Correctif de sécurité | La version d'un composant change | Mettre à jour les composants concernés et archiver le nouveau SBOM |
| Vulnérabilité découverte et évaluée | Le statut VEX ou d'exploitabilité change | Mettre à jour le statut et la preuve de décision |
| Composant ajouté, supprimé ou remplacé | Le graphe de dépendances change | Régénérer et valider le SBOM |
| Changement de conception pertinent pour la sécurité | Composants ou architecture changent | Régénérer le SBOM et mettre à jour les références du dossier technique |
| Normes ou spécifications appliquées modifiées | Les métadonnées de conformité changent | Revoir les métadonnées et les preuves liées |
Révisions périodiques. Le CRA ne fixe pas d'intervalle de revue. Ces cadences sont une base pratique :
| Fréquence | Périmètre |
|---|---|
| Trimestrielle | SBOM et statut des vulnérabilités |
| Annuelle | Révision complète du dossier technique |
| Avant la fin de la période d'assistance | Gel final de la documentation |
Chaque build devrait produire un artefact SBOM à jour, pour que la preuve reste alignée sur ce que vous livrez. Consultez les erreurs SBOM courantes pour savoir ce qui se passe quand les équipes sautent l'automatisation.
Combien de temps conserver les preuves SBOM
Conservez le SBOM avec la documentation technique pendant au moins 10 ans après la mise sur le marché du produit comportant des éléments numériques, ou pendant la période d'assistance si celle-ci est plus longue. La même règle de conservation s'applique à la documentation technique et à la déclaration UE de conformité. Il s'agit de conserver la documentation. C'est distinct de l'obligation de garder disponibles les mises à jour de sécurité elles-mêmes, qui court pour ses propres dix ans à compter de la diffusion de chaque mise à jour.
Pour une gamme de produits vendue dans le temps, conservez les preuves relatives aux versions et exemplaires mis sur le marché. Ne considérez pas la première date de lancement comme la fin pratique de l'obligation de preuve tant que des unités ou versions ultérieures sont encore fournies.
| Étape | Date exemple |
|---|---|
| Première mise sur le marché | Mars 2027 |
| Dernier exemplaire mis sur le marché | Décembre 2030 |
| Couverture pratique des preuves | Jusqu'en décembre 2040 ou plus si la période d'assistance l'exige |
Le compte court à partir du dernier exemplaire mis sur le marché : décembre 2030 plus dix ans atteint donc au moins décembre 2040, plus longtemps si la période d'assistance dépasse cette date. Conservez le SBOM dans un stockage sécurisé et sauvegardé, avec protection de l'intégrité, afin de pouvoir récupérer et fournir la bonne version sur demande motivée.
Dates et application
L'application intégrale du CRA commence le 11 décembre 2027. L'obligation de signalement des vulnérabilités commence plus tôt, le 11 septembre 2026. Cette date antérieure n'est pas une échéance séparée de dépôt du SBOM, mais elle impose de savoir rapidement quelles versions de produit et quels composants sont concernés par une vulnérabilité ou un incident à signaler. Pour les produits mis sur le marché de l'UE après l'application intégrale, le SBOM fait partie de la base de preuve derrière l'évaluation de la conformité, la déclaration UE de conformité et le marquage CE. Pour le flux de signalement, voyez le signalement des vulnérabilités et incidents CRA. Pour le calendrier général du CRA, voyez ce qu'est le CRA ; pour le tableau des sanctions, voyez sanctions et application du CRA.
Questions fréquentes
Le CRA exige-t-il un SBOM lisible par machine ou un PDF est-il acceptable ?
Le SBOM doit être dans un format couramment utilisé et lisible par machine. Un PDF ou un tableur peut accompagner le fichier pour la revue humaine, mais ne le remplace pas. CycloneDX ou SPDX sérialisé en JSON ou XML est la voie pratique.
Le CRA exige-t-il un SBOM pour les composants open source ?
Oui. Les composants open source restent des composants contenus dans le produit, ils ont donc leur place dans le SBOM avec leur version et leurs identifiants. Le CRA attend aussi de vous une diligence raisonnable sur les composants tiers que vous intégrez, y compris les logiciels open source qui ne vous ont pas été fournis à titre commercial, et le signalement de toute vulnérabilité que vous trouvez dans un composant intégré, y compris open source, à celui qui en assure la maintenance.
Quand un SBOM doit-il être soumis : lors de la mise sur le marché ou sur demande ?
Le SBOM n'est normalement pas soumis de manière proactive. Il doit faire partie de la documentation technique, être prêt et disponible pour les autorités de surveillance du marché sur demande motivée, et exister lorsque le produit est mis sur le marché de l'UE.
Quels sont les éléments minimaux de la NTIA et satisfont-ils aux exigences du CRA ?
Les éléments minimaux de la NTIA (nom du fournisseur, nom du composant, version, identifiants uniques, relations de dépendance, auteur du SBOM et horodatage) sont un point de départ raisonnable. Ils ne répondent pas à eux seuls à toutes les questions de preuve du CRA ni à toutes les attentes qualité de TR-03183. Pour le CRA, validez le fichier généré contre le format choisi, enregistrez le statut des vulnérabilités et complétez les champs plus riches comme PURL/CPE, hachages et relations lorsque votre cadre qualité les exige.
Puis-je réutiliser les SBOM de mes fournisseurs pour satisfaire au CRA ?
Partiellement. Les SBOM fournisseurs sont des entrées valides pour les composants qu'ils livrent, mais vous devez toujours un SBOM pour le produit tel qu'il est mis sur le marché. Cela implique de consolider les SBOM fournisseurs avec vos composants internes et vos dépendances de build en une preuve au niveau produit, comme expliqué plus haut dans la partie sur le nombre de SBOM nécessaires pour un produit. Traitez les SBOM fournisseurs comme une matière première, pas comme l'artefact de conformité final.
Pour aller plus loin
- Choisissez un format : CycloneDX pour l'orientation sécurité et le support natif VEX, SPDX pour la conformité des licences et une adoption plus large. Voyez CycloneDX vs SPDX.
- Automatisez la génération dans votre CI/CD avec Syft, Trivy, cdxgen ou des outils d'analyse de composition logicielle (SCA). Un export ponctuel ne satisfait pas à l'obligation continue.
- Validez la qualité des champs par rapport à BSI TR-03183 ou à votre contrôle qualité SBOM interne : nom et version, fournisseur, PURL/CPE, dépendances, hachages et licences.
- Intégrez les SBOM dans votre surveillance des vulnérabilités (NVD, OSV, GitHub Advisory Database, CISA KEV) avant les obligations de signalement qui commencent le 11 septembre 2026.
- Placez le SBOM dans votre dossier technique. Le guide de la documentation technique explique où il s'insère. Si vous préférez ne pas construire l'intégration SBOM depuis zéro, CRA Evidence prend en charge l'intégration CycloneDX/SPDX et le scoring qualité TR-03183 sur vos versions produit.