Comparer
Conformité au CRA : exigences SBOM et outils
Le Cyber Resilience Act rend la nomenclature logicielle (SBOM) obligatoire pour les produits comportant des éléments numériques. Voici ce que le règlement en attend, ce qu'ajoute la directive technique du BSI allemand, et comment se comparent les outils de conformité au CRA.
Mis à jour le
Chaque comparatif indique ce que l'autre produit fait bien, en quoi CRACI diffère et quand utiliser les deux. Pour toutes les catégories, consultez tous les comparatifs.
Ce que le CRA exige d'une SBOM
Le Cyber Resilience Act, règlement (UE) 2024/2847, place la SBOM dans ses exigences de gestion des vulnérabilités. Il en demande moins qu'on ne le croit souvent : un enregistrement lisible par machine couvrant au minimum les dépendances de niveau supérieur, conservé dans la documentation technique et présenté à une autorité sur demande. Voici ce que dit le règlement, question par question.
| Fonctionnalité | Ce que dit le CRA | Où |
|---|---|---|
| Une SBOM est-elle obligatoire ? | Oui. Les fabricants doivent recenser et documenter les composants contenus dans leurs produits, « notamment en établissant une nomenclature des logiciels » | Annexe I, partie II, point 1 |
| Qu'est-ce qu'une SBOM ? | « Un registre officiel contenant des informations détaillées et les relations de la chaîne d'approvisionnement des composants inclus dans les éléments logiciels d'un produit comportant des éléments numériques » | Article 3, point 39 |
| Quel format ? | « Un format couramment utilisé et lisible par machine ». La Commission peut préciser le format et les éléments par voie d'actes d'exécution | Annexe I, partie II, point 1 ; article 13, paragraphe 24 |
| Quelle profondeur ? | « Au minimum les dépendances de niveau supérieur des produits » | Annexe I, partie II, point 1 |
| Où doit-elle figurer ? | Dans la documentation technique, au sein des informations sur la gestion des vulnérabilités | Annexe VII, point 2, b) |
| Doit-elle être publique ? | Non. « Les fabricants ne devraient pas être tenus de rendre publique la nomenclature des logiciels. » Si vous la partagez avec les utilisateurs, les informations destinées à l'utilisateur indiquent où la trouver | Considérant 77 ; annexe II, point 9 |
| Qui peut la demander ? | Une autorité de surveillance du marché, sur demande motivée, pour vérifier la conformité. Les autorités peuvent aussi demander des SBOM pour une évaluation des dépendances à l'échelle de l'UE | Annexe VII, point 8 ; article 13, paragraphe 25 |
| Combien de temps la conserver ? | La documentation technique est conservée au moins 10 ans après la mise sur le marché du produit, ou pendant la période de support si celle-ci est plus longue | Article 13, paragraphe 13 |
Le règlement s'applique dans son intégralité à partir du 11 décembre 2027, et ses obligations de signalement s'appliquent à partir du 11 septembre 2026. Pour le reste du règlement, voir ce qu'exige le CRA.
Au-delà du minimum : BSI TR-03183-2
Tant que la Commission n'a pas précisé le format par acte d'exécution, les recommandations publiques les plus détaillées viennent de l'Office fédéral allemand de la sécurité des technologies de l'information (BSI). Sa directive technique TR-03183-2, version 2.1.0 d'août 2025, est une recommandation et ne fait pas partie du règlement, mais elle montre dans quelle direction vont les attentes :
- Format : JSON ou XML, valide au regard de CycloneDX 1.6 ou supérieur, ou de SPDX 3.0.1 ou supérieur.
- Profondeur : résolution récursive des dépendances pour chaque composant du périmètre de livraison, jusqu'au premier composant situé hors de ce périmètre, ce composant compris.
- Source de vérité : la SBOM doit contenir « les mêmes informations que celles disponibles pendant le processus de build », ou des informations équivalentes en l'absence de processus de build.
La directive nomme aussi les types de SBOM. Une Build SBOM « est créée dans le cadre du processus de build ». Une Analysed SBOM « est créée après le processus de build par l'analyse d'artefacts tels que des exécutables, des paquets, des conteneurs et des images de machines virtuelles ». Cette distinction est la principale différence entre les outils présentés sur cette page.
Dépendances de niveau supérieur ou transitives
Les dépendances de niveau supérieur sont le minimum, pas l'objectif. Une vulnérabilité dans un paquet transitif fait tout de même partie de votre produit, et le CRA demande aux fabricants de traiter et de corriger les vulnérabilités des composants qu'ils livrent. Une SBOM qui s'arrête au premier niveau laisse ces paquets hors de votre gestion des vulnérabilités. La question pratique n'est pas de savoir s'il faut enregistrer les dépendances transitives, mais comment s'assurer que l'enregistrement correspond à ce qui a été livré. Voir les dépendances transitives pour savoir comment les lister et corriger celles qui sont vulnérables.
SBOM de build ou SBOM analysée
La plupart des outils SBOM génèrent une SBOM analysée après le build, ou gèrent des SBOM produites par d'autres outils. CRACI enregistre une SBOM de build pendant l'exécution du build. Pour une comparaison des générateurs et des gestionnaires de SBOM, voir la gestion des SBOM et le comparatif des outils SBOM. Pour les outils conçus autour du CRA, voir le comparatif des outils de conformité au CRA.
La place de CRACI
CRACI enregistre la SBOM pendant l'exécution de votre build GitHub Actions. Un proxy qui comprend les paquets, installé sur le runner, enregistre chaque paquet récupéré par le job, paquets restaurés depuis les caches CI compris : la SBOM décrit donc le build qui a produit l'artefact plutôt qu'un scan exécuté quelque part à côté. La SBOM de chaque job porte un état de complétude, et les exports en CycloneDX et SPDX incluent les dépendances transitives et la licence déclarée de chaque composant.
Après la mise en production, CRACI continue de réévaluer les SBOM surveillées à mesure que de nouvelles vulnérabilités apparaissent, et il soumet en votre nom les notifications prévues par le CRA (alerte précoce, notification et rapport final). L'API renvoie les SBOM, les traces réseau et la provenance. CRACI conserve les données de build 180 jours par défaut, avec une durée de conservation personnalisée sur Enterprise : exportez donc ce qui doit figurer dans votre dossier technique conservé 10 ans. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves dont votre démarche CRA a besoin ; l'évaluation de la conformité et le dossier technique restent du ressort du fabricant. Pour toutes les exigences du CRA sous forme de feuille de route étape par étape, voir le guide du CRA. En savoir plus sur la génération de SBOM au build, ou réservez une démo pour voir une SBOM enregistrée à partir de l'un de vos builds.
CRACI comparé à chaque outil
- CRACI face à Cybeats Un système de référence pour les SBOM face à des SBOM enregistrées et surveillées.
- CRACI face à FOSSA Gestion des SBOM face au build, aux SBOM et à la surveillance réunis.
- CRACI face à Anchore Scanner des images face à enregistrer et surveiller des builds.
- CRACI face à Black Duck Analyse du code, des extraits et des binaires face aux preuves de build.
- CRACI face à Sonatype Contrôle d'accès au dépôt et SCA face aux preuves de build.
- CRACI face à ONEKEY Analyse binaire de firmware face aux preuves issues du build.
- CRACI face à Finite State Analyse des binaires et des SBOM fournisseurs face à un enregistrement du build.
- CRACI face à Exein Sécurité à l'exécution sur l'appareil face aux preuves issues du build.
Côte à côte
Plusieurs outils sur une même page, lorsque vous choisissez une catégorie plutôt qu'un produit.
SBOM et CRA : vos questions, nos réponses
Le CRA exige-t-il les dépendances transitives dans la SBOM ?
Le règlement fixe le minimum à « au minimum les dépendances de niveau supérieur des produits » (annexe I, partie II, point 1). Les dépendances transitives ne sont pas citées, mais un paquet transitif vulnérable fait tout de même partie de votre produit, et le CRA vous demande de gérer les vulnérabilités des composants que vous livrez. La directive technique allemande BSI TR-03183-2 va plus loin et demande une résolution récursive des dépendances.
La SBOM exigée par le CRA doit-elle être publique ?
Non. Le considérant 77 indique que les fabricants ne devraient pas être tenus de rendre publique la SBOM. Elle fait partie de la documentation technique, et une autorité de surveillance du marché peut la réclamer par une demande motivée. Si vous choisissez de la partager avec les utilisateurs, les informations qui accompagnent le produit doivent indiquer où la trouver (annexe II, point 9).
Une SBOM pour le CRA doit-elle être en CycloneDX ou en SPDX ?
Le CRA demande « un format couramment utilisé et lisible par machine » sans en nommer un ; la Commission peut préciser le format par acte d'exécution (article 13, paragraphe 24). CycloneDX et SPDX sont les deux choix courants. BSI TR-03183-2 v2.1.0 accepte CycloneDX 1.6 ou supérieur et SPDX 3.0.1 ou supérieur, en JSON ou en XML.
Combien de temps dois-je conserver la SBOM ?
La SBOM fait partie de la documentation technique, que les fabricants tiennent à la disposition des autorités de surveillance du marché pendant au moins 10 ans après la mise sur le marché du produit, ou pendant la période de support si elle est plus longue (article 13, paragraphe 13).
Quand les exigences du CRA relatives à la SBOM s'appliquent-elles ?
Les obligations de signalement du CRA s'appliquent à partir du 11 septembre 2026, et le règlement s'applique dans son intégralité, exigence de SBOM de l'annexe I comprise, à partir du 11 décembre 2027.
Autres catégories
Découvrez CRACI sur votre propre pipeline
Réservez une démo et nous passerons en revue vos builds, vos SBOM et vos preuves de conformité.
Réserver une démo