Erreurs SBOM sous le CRA : 7 corrections pratiques pour les fabricants

Le générateur SBOM tourne, le fichier est valide, et la prochaine revue produit peut encore révéler des lacunes. Les échecs récurrents de préparation CRA ne sont généralement pas des cas limites juridiques obscurs. Ce sont des arbres de dépendances peu profonds, des inventaires source uniquement, des dossiers obsolètes et des composants que les scanners ne peuvent pas relier à une vulnérabilité. Le Règlement sur la cyberrésilience demande un SBOM lisible par machine, dans un format couramment utilisé, couvrant au moins les dépendances de niveau supérieur et conservé avec la documentation technique. Cet article couvre les sept écarts entre un SBOM qui existe techniquement et un SBOM capable de soutenir la gestion des vulnérabilités. C'est le SBOM qu'une autorité de surveillance du marché s'attend à examiner.

Les erreurs en un coup d'œil

• Arbre source, pas l'artefact livré : générez depuis l'artefact ou l'image buildés afin que le code compilé, les paquets OS et le firmware soient visibles.
• Champs d'identité insuffisants : utilisez des versions exactes, des hachages, des PURL là où ils sont disponibles, et des noms de fournisseur afin que les scanners puissent corréler les CVE.
• Dépendances directes uniquement : ajoutez l'analyse des fichiers de verrouillage et des artefacts buildés afin que les dépendances indirectes et embarquées entrent dans le SBOM.
• Fichier ponctuel : régénérez et archivez le SBOM à chaque version, puis maintenez la corrélation des vulnérabilités à jour.
• Code produit omis : les composants internes, propriétaires, commerciaux et firmware nécessitent des identifiants et des preuves.
• Copier-coller fournisseur : les SBOM fournisseurs sont des données d'entrée. Réconciliez-les avec le code de première partie et l'artefact de version finale.
• Éparpillement du SBOM : conservez un SBOM produit de référence par version afin que la version 1.4.2 dispose d'un enregistrement défendable unique.

Ce qui compte pour les preuves SBOM

Ce plancher légal n'est pas équivalent à un plancher utile pour la gestion des vulnérabilités. Un SBOM limité aux dépendances directes peut satisfaire la formule minimale sur les dépendances, tout en restant trop peu profond pour identifier rapidement les produits concernés. La BSI TR-03183, les orientations de l'ENISA, les recommandations CISA sur les SBOM et les pratiques actuelles des outils sont mieux lus comme des références de qualité qui aident les fabricants à rendre l'obligation CRA opérationnelle.

Erreur 1 : votre SBOM décrit l'arbre source, pas le produit que vous avez livré

Les manifestes source sont pratiques, mais ils ne constituent pas le produit. Une analyse source peut sur-reporter les dépendances de développement et manquer ce qui n'apparaît qu'après la compilation, le packaging, la mise en couche de conteneurs, l'édition de liens statiques ou l'intégration du firmware. Pour un fabricant, le SBOM doit répondre à la question : qu'est-ce qui figurait dans la version livrée, pas seulement ce qui était déclaré dans un fichier de paquets.

Cette distinction est particulièrement importante pour les produits embarqués et conteneurisés. Une analyse au niveau du langage peut manquer les paquets OS dans une couche de base de conteneur. Un export Yocto ou Buildroot peut manquer le firmware d'un fournisseur de silicium, les chargeurs d'amorçage, les modules noyau ou les blobs binaires entrés en dehors du système de build. Si ces composants font partie de l'artefact livré, ils appartiennent aux preuves de version, même lorsqu'un scanner de paquets automatisé ne peut pas les inférer.

Le correctif consiste à générer depuis l'artefact ou l'image de version finale, puis à comparer avec les sorties source et fichier de verrouillage. Pour les conteneurs, analysez l'image finale par digest. Pour le firmware, combinez la sortie SBOM du système de build avec une analyse binaire et des enregistrements manuels pour les composants que les outils ne peuvent pas identifier automatiquement.

Erreur 2 : l'absence de hachages et de PURL rend les composants impossibles à corréler

Un SBOM sans version précise, hachage, fournisseur et identifiants de paquets est difficile à utiliser pour la corrélation des vulnérabilités. Le fichier peut être lisible par machine, mais un scanner a toujours besoin d'une identité stable des composants pour décider si un CVE, un avis OSV, un GitHub Security Advisory ou une entrée CISA KEV s'applique.

Chaque composant doit comporter suffisamment d'identité pour résister à la corrélation automatisée :

Ce n'est pas uniquement une question d'hygiène. Le NIST a annoncé le 15 avril 2026 que l'enrichissement NVD est désormais priorisé pour certains CVE sélectionnés, car le volume de vulnérabilités a dépassé la capacité d'enrichissement complet. La corrélation par CPE seul devient ainsi une approche moins fiable pour les opérations de vulnérabilité futures. Utilisez le PURL là où il est disponible, conservez des hachages pour les artefacts livrés et ne traitez pas le seul nom d'un composant comme suffisant.

Une erreur de format courante est d'utiliser CycloneDX 1.3 ou antérieur. La prise en charge principale de VEX est arrivée dans CycloneDX 1.4, et la structure enrichie evidence des composants est arrivée dans CycloneDX 1.5. Pour la préparation CRA actuelle, ciblez CycloneDX 1.6 ou ultérieur, ou un profil SPDX actuel que vos outils peuvent consommer de manière fiable. Vérifiez la sortie de votre générateur avant de supposer que le format prend en charge les champs dont votre processus a besoin.

Erreur 3 : s'arrêter aux dépendances directes

Les dépendances directes constituent le plancher minimal du CRA. Elles ne suffisent pas pour une gestion utile des vulnérabilités. Une dépendance transitive est un composant tiré par un autre composant, et elle peut porter la vulnérabilité qui compte. Lorsqu'un CVE touche un paquet transitif que votre SBOM ne liste pas, le produit peut être concerné tandis que votre pipeline de corrélation reste silencieux.

Pour y remédier, utilisez des fichiers de verrouillage là où l'écosystème les prend en charge, analysez les artefacts buildés en plus de la source et inspectez les paquets qui regroupent ou embarquent des dépendances. Traitez la couverture transitive comme une pratique de qualité d'audit, pas comme un réglage approximatif laissé aux valeurs par défaut d'un scanner.

Erreur 4 : traiter le SBOM comme un document ponctuel

Un SBOM généré une seule fois et jamais mis à jour crée un faux sentiment de sécurité. De nouveaux CVE sont publiés contre des composants déjà présents dans le produit. De nouvelles versions de firmware, des correctifs et des mises à jour fournisseurs font évoluer le produit. Le CRA exige également que la documentation technique soit continuellement mise à jour le cas échéant pendant la période d'assistance.

Déclencheurs de mise à jour courants :

Le CI/CD est le contrôle pratique. Chaque version doit produire un artefact SBOM à jour stocké aux côtés du build et lié à la documentation technique. Les entrées manuelles ne doivent exister que pour les composants que les outils ne peuvent pas détecter, et ces entrées nécessitent toujours une revue lorsque le produit change.

Erreur 5 : exclure les composants internes, propriétaires et firmware

Un raccourci courant consiste à ne documenter que les dépendances open source et à omettre les bibliothèques internes, les modules commerciaux, le firmware propriétaire ou les blobs fournisseurs. Ce n'est pas un SBOM produit. Si un composant est livré dans le produit, il appartient au périmètre, même lorsqu'il n'a pas de page dans un registre public.

Les composants internes n'ont souvent pas de PURL dans un écosystème ni d'entrée dans un registre public. Utilisez un identifiant interne, votre propre organisation comme fournisseur le cas échéant, la version exacte ou l'identifiant de build, et le hachage de l'artefact binaire. Pour les composants commerciaux, conservez le nom du fournisseur, la version, les preuves de licence et les références contractuelles dans la documentation technique.

Pour les produits matériel-logiciel, c'est au niveau du firmware que cette problématique devient visible. Les modules Wi-Fi, les modems, les éléments sécurisés, les chargeurs d'amorçage, les binaires d'environnement d'exécution de confiance et les modules noyau hors arbre peuvent porter des vulnérabilités tout en restant invisibles pour les scanners de paquets au niveau du langage. Utilisez les SBOM fournisseurs là où ils sont disponibles, ajoutez des enregistrements manuels là où ils ne le sont pas, et utilisez l'analyse binaire comme vérification. Pour la partie matérielle du dossier de preuves, consultez le HBOM sous le CRA.

Erreur 6 : utiliser les SBOM fournisseurs comme artefact finalisé

Les SBOM fournisseurs sont des données d'entrée valides. Ils ne constituent pas votre SBOM produit finalisé. Le fabricant met le produit intégré sur le marché de l'UE. Le SBOM produit doit combiner les composants fournisseurs, le code de première partie, les sorties de build, le firmware, le code de liaison et les relations de dépendances propres au produit.

Le mode d'échec est facile à manquer : un fournisseur vous donne un fichier CycloneDX, un autre vous donne du SPDX, un troisième fournit un inventaire PDF, et le dossier produit final contient des liens vers les trois. Ce sont des preuves fournisseurs, pas un enregistrement produit unique. Un vérificateur doit toujours savoir quels composants figuraient dans la version produit 1.4.2.

Réconciliez plutôt que de copier. Fusionnez les SBOM fournisseurs dans le SBOM produit, normalisez les champs d'identité, documentez les inconnues identifiées et conservez les SBOM amont comme preuves complémentaires. Si un SBOM fournisseur manque de PURL, de hachage, de licence ou de version exacte, documentez la lacune et comblez ce que vous pouvez avant la livraison. Une URL vers un fichier amont n'équivaut pas à un SBOM produit intégré.

Erreur 7 : de nombreux SBOM, pas d'enregistrement produit unique

L'éparpillement du SBOM est l'étape suivante après l'adoption des outils. Il y a un SBOM applicatif, un SBOM conteneur, un SBOM firmware, plusieurs SBOM fournisseurs et une feuille de calcul gérée par un chef de produit. Aucun d'eux n'est la réponse de référence pour la version produit mise sur le marché.

Cela crée un risque d'audit et opérationnel. Lorsqu'une nouvelle vulnérabilité activement exploitée apparaît, l'équipe doit rechercher dans les fragments avant de pouvoir dire si le produit est concerné. Lorsqu'une autorité formule une demande motivée, le dossier de preuves ne doit pas dépendre de quelqu'un se rappelant quel dossier contient la dernière fusion.

Utilisez un SBOM produit de référence unique par version, avec les SBOM de composants complémentaires conservés en dessous. Conservez-le pendant au moins 10 ans après la mise sur le marché du produit, ou pendant la période d'assistance, selon la durée la plus longue. Stockez-le là où la version, la surveillance des vulnérabilités, les décisions VEX et la documentation technique peuvent toutes référencer la même version.