SBOM : ce que le CRA exige concrètement et comment s'y préparer

Ce que le CRA exige réellement

Le SBOM (Software Bill of Materials) est cité dans le Règlement (UE) 2024/2847 en deux endroits distincts, qui correspondent à deux logiques différentes.

La première occurrence est à l'Annexe VII, qui décrit le contenu du dossier technique. Le point 3f exige que le dossier technique contienne, pour chaque produit, « une liste des dépendances logicielles, notamment les composants logiciels tiers » : soit la définition fonctionnelle d'un SBOM. Cette exigence est opposable à compter du 11 décembre 2027 pour les nouveaux produits mis sur le marché.

La deuxième occurrence est dans le contexte de la surveillance du marché. L'Article 13(14) précise que le fabricant doit être en mesure de mettre à disposition le SBOM à la demande des autorités de surveillance du marché. Le SBOM n'est pas un document public obligatoire. Il est communiqué aux autorités sur requête, pas mis en ligne. Cette distinction a des implications en matière de protection des informations commerciales sensibles sur les composants utilisés.

Le règlement ne prescrit pas de format particulier pour le SBOM : cette précision est renvoyée à des actes délégués ou d'exécution qui n'étaient pas encore publiés au moment de la rédaction de cet article. En pratique, deux formats s'imposent comme standards de fait reconnus par la base EUVD (European Vulnerability Database) et par les principales autorités de cybersécurité : CycloneDX et SPDX.

Le CRA introduit par ailleurs une évolution notable par rapport aux autres directives CE sur la question des composants. La règle générale sous les directives classiques est que seul le produit fini est évalué. La conformité d'un composant n'a pas d'effet direct sur la conformité du produit qui l'intègre. Sous le CRA, la conformité d'un module certifié (par exemple un modem ou un module radio ayant fait l'objet de sa propre évaluation CRA) peut contribuer positivement à la conformité du produit intégrateur, dès lors que ce module est utilisé conformément à sa documentation. Le SBOM est l'instrument qui rend cette chaîne de traçabilité visible et auditable : il établit quels composants sont intégrés dans le produit, dans quelle version, et lesquels disposent d'une évaluation de conformité propre. Sans SBOM structuré, cette traçabilité ne peut pas être démontrée lors d'un contrôle.

Pourquoi le SBOM est le prérequis de l'Article 14

La valeur réglementaire du SBOM ne se limite pas à la case documentaire du dossier technique. Sans SBOM à jour, le délai de 24 heures de l'Article 14 est, dans la plupart des organisations industrielles, intenable.

Le raisonnement est le suivant. Quand une vulnérabilité est publiée dans la NVD, l'EUVD ou un bulletin CERT (disons, une faille dans OpenSSL, dans un composant RTOS comme FreeRTOS, ou dans une bibliothèque de gestion des communications Modbus), la première question que le fabricant doit résoudre est : est-ce que cette bibliothèque est dans mes produits ? Et si oui, dans quelle version ?

Sans SBOM, cette réponse passe par une analyse manuelle des builds de firmware, produit par produit, version par version. Pour un fabricant gérant plusieurs familles de produits avec des générations successives de firmware, cet exercice peut prendre plusieurs jours. Ce délai est structurellement incompatible avec l'obligation de notification en 24 heures.

Avec un SBOM maintenu à jour et structuré dans un format lisible par machine, la corrélation est automatisable. Un script de quelques lignes (ou un outil dédié comme Dependency-Track (OWASP)) peut comparer la liste des composants du SBOM avec les flux de vulnérabilités de l'EUVD et identifier en quelques minutes les produits potentiellement affectés. Ce n'est pas une commodité ; c'est l'infrastructure de base qui permet de tenir le délai réglementaire.

CycloneDX ou SPDX : lequel choisir ?

Les deux formats ont des origines et des cas d'usage légèrement différents, mais leur couverture fonctionnelle pour les exigences CRA est équivalente.

SPDX (Software Package Data Exchange) est une norme ISO (ISO/IEC 5962:2021), initialement développée par la Linux Foundation avec une orientation forte sur la traçabilité des licences open source. Sa structure est plus rigide, ce qui favorise l'interopérabilité, mais peut le rendre moins naturel pour des composants propriétaires ou des systèmes embarqués sans package manager standard.

CycloneDX est une norme OWASP, maintenue par la communauté de sécurité applicative. Elle a une orientation plus marquée sur l'analyse de vulnérabilités et la corrélation avec des bases comme la NVD. Son schéma supporte nativement les informations de pedigree et de provenance (pour la chaîne d'approvisionnement), les hashes de composants (pour vérifier l'intégrité), et les référentiels d'identifiants standardisés (CPE, PURL). Ces caractéristiques en font le format de référence pour la corrélation automatique avec l'EUVD.

Pour un fabricant dont la priorité immédiate est la conformité Article 14 (c'est-à-dire la capacité de corrélation rapide avec les flux CVE), CycloneDX est le choix pragmatique. Son écosystème d'outils de génération pour firmware embarqué est plus développé (integrations Yocto, Buildroot, sbom-tool de Microsoft). SPDX est préférable si la conformité des licences open source est une contrainte additionnelle significative, notamment pour les fabricants dont les produits incorporent des composants GPL ou LGPL.

Les deux formats sont convertibles l'un en l'autre via des outils comme cdx2spdx ou CycloneDX CLI. Le choix initial n'est donc pas irréversible, mais la cohérence et la maintenabilité à long terme plaident pour un format unique.

Le défi du firmware embarqué

La génération de SBOM pour les applications web ou les logiciels natifs basés sur des package managers (npm, pip, Maven, NuGet) est un problème largement résolu. La chaîne d'outils est mature : syft, cdxgen, CycloneDX CLI, Trivy : ces outils analysent un lock file ou un manifeste de dépendances et produisent un SBOM en quelques secondes.

La situation pour le firmware embarqué est structurellement différente, pour plusieurs raisons :

• Absence de package manager standard : la plupart des projets firmware embarqué gèrent leurs dépendances manuellement : bibliothèques copiées dans l'arborescence des sources, archives intégrées, composants fournis par le fabricant du SoC ou du RTOS. Il n'existe pas de fichier package-lock.json ou requirements.txt que l'outil peut lire directement ;
• Composants BSP et HAL : les Board Support Packages et Hardware Abstraction Layers fournis par les fabricants de SoC (STMicroelectronics, NXP, Microchip, etc.) contiennent souvent des bibliothèques propriétaires et des composants open source mélangés, dont le SBOM n'est pas toujours fourni par le fournisseur ;
• Composants avec identifiants non standardisés : les bibliothèques spécifiques aux systèmes embarqués (piles de protocoles radio, bibliothèques de chiffrement légères pour microcontrôleurs) n'ont pas toujours d'identifiant CPE (Common Platform Enumeration) ou PURL (Package URL) défini, ce qui complique la corrélation automatique avec les CVE ;
• Legacy non documenté : pour les firmwares développés avant que la pratique du SBOM ne soit répandue, la liste des composants doit être reconstituée à partir des fichiers sources, des historiques de commit, et des archives de build, exercice laborieux mais incontournable.

Pour les projets Yocto ou Buildroot (les environnements de build Linux embarqué les plus répandus), des extensions de génération SBOM existent (Yocto meta-cve-check, CycloneDX Buildroot plugin). Elles produisent un SBOM à partir du graphe de dépendances du build, y compris les recettes des composants BSP. C'est la solution la moins coûteuse pour les projets Linux embarqué bien structurés.

Pour les projets firmware bare-metal ou RTOS sans framework de build structuré, la démarche est nécessairement plus manuelle dans un premier temps : inventaire des bibliothèques incluses (par analyse du Makefile ou des scripts de build), identification des versions à partir des headers ou des notes de release fournisseur, et saisie manuelle dans un outil de gestion SBOM. L'objectif n'est pas la perfection norme dès le premier jour, mais d'avoir un SBOM initial suffisamment complet pour couvrir les composants les plus susceptibles d'être affectés par des CVE : les bibliothèques de réseau, de chiffrement, et les parseurs de protocoles.

Contenu minimum et SBOM viable pour une PME

L'Annexe VII §3f du CRA n'impose pas de niveau de détail précis pour le SBOM : elle exige « une liste des dépendances logicielles, notamment les composants logiciels tiers ». La norme prEN 40000-1-3 (§5.3.6, traitement des vulnérabilités) ajoute des exigences de complétude dépendant du niveau de risque du produit.

Un SBOM viable pour une PME industrielle devrait couvrir, à minima :

• Les dépendances directes significatives : les bibliothèques tierces incluses dans le firmware ou le logiciel, avec leur nom complet, leur version exacte, leur fournisseur (ou projet upstream), et si possible leur licence ;
• Les composants d'infrastructure critique : les bibliothèques cryptographiques, les piles réseau (TCP/IP, TLS, protocoles radio), les parseurs de protocoles applicatifs, ceux dont une vulnérabilité aurait le plus d'impact sur la sécurité du produit ;
• Un identifiant de produit clair : référence produit interne, version du firmware, et si possible un PURL ou CPE au niveau du produit pour permettre la corrélation EUVD directe ;
• Les hashes des composants (recommandé dans la prEN 40000-1-3 §5.3.6 [PRE-7-RQ-07-RE] pour les produits à risque élevé) : permettent de vérifier l'intégrité du composant inclus dans le build par rapport au composant source référencé.

Ce qui n'est pas strictement requis au sens du règlement, mais apporte une valeur significative : les dépendances transitives (dépendances des dépendances), les informations sur les fournisseurs de la chaîne d'approvisionnement hardware, et la présence de l'outil de génération utilisé (pour la reproductibilité de l'analyse).

La taille de l'organisation ne détermine pas la complexité réelle du SBOM. Un système embarqué industriel avec un firmware de 200 Ko peut avoir moins de composants identifiables qu'une application web légère. La complexité réelle est déterminée par le nombre de bibliothèques tierces intégrées et par la pratique documentaire de l'équipe de développement.

Intégration avec l'EUVD

L'EUVD (European Vulnerability Database), gérée par l'ENISA, est la base de données de vulnérabilités de référence pour le marché européen. Elle agrège les données de vulnérabilités de sources reconnues (NVD, bases nationales) et les enrichit d'informations sur les mesures appliquées par les États membres et les CSIRT. Sa mise en service complète est progressive.

La valeur de l'EUVD pour les fabricants tient à son rôle dans le processus de surveillance des vulnérabilités requis par l'Article 14. Un fabricant doit disposer d'un processus de veille sur les vulnérabilités affectant ses composants : la corrélation SBOM/EUVD est le mécanisme qui automatise cette surveillance pour les CVE documentées dans la base.

En pratique, la corrélation fonctionne comme suit :

1. Le SBOM liste les composants avec leurs identifiants (CPE ou PURL) ;
2. L'outil de surveillance (Dependency-Track, Grype, ou un script sur l'API EUVD) compare ces identifiants avec les nouvelles entrées de la base de vulnérabilités ;
3. Toute correspondance déclenche une alerte interne avec le niveau de sévérité CVSS et l'état d'exploitation (known exploited, etc.) ;
4. Si la vulnérabilité est flaggée « activement exploitée », le processus Article 14 est déclenché.

Cette chaîne n'est efficace que si le SBOM contient des identifiants standardisés. Un composant listé uniquement par son nom interne (« bibliothèque_crypto_v2.3 ») sans référence à son équivalent upstream ne peut pas être corrélé automatiquement avec les CVE.

Pour un petit fabricant qui n'a pas d'équipe sécurité dédiée, le paquet minimal viable de gestion des vulnérabilités au sens du CRA comprend quatre éléments : une veille active sur l'EUVD (corrélée avec le SBOM du produit), un SBOM correctement maintenu pour chaque produit en service, un point de contact formalisé pour recevoir les signalements de vulnérabilités (l'adresse security@ et la politique CVD sont les deux faces de cette exigence), et une procédure documentée pour notifier une vulnérabilité activement exploitée à l'ANSSI et à l'ENISA dans les délais de l'Article 14. Une procédure de remédiation très détaillée n'est pas nécessairement attendue à ce stade. L'essentiel est que l'entreprise soit capable de l'exécuter et qu'elle documente la diffusion effective des mises à jour de sécurité. C'est sur ce paquet, et non sur le seul dossier technique, que se concentreront les contrôles dès septembre 2026.

Calendrier et priorisation pour les fabricants qui démarrent aujourd'hui

La contrainte de calendrier est nette : l'Article 14 entre en application le 11 septembre 2026. Pour un fabricant qui démarrerait fin avril 2026, il reste environ cinq mois. Voici une séquence réaliste :

• Mois 1 (mai 2026) : Inventaire des produits dans le périmètre Article 14 (y compris les générations hors commercialisation active mais encore en service). État des lieux de la documentation existante. Existe-t-il une liste de composants, même partielle, pour chaque firmware ? Choix du format SBOM (CycloneDX recommandé) et des outils ;
• Mois 2-3 (juin-juillet 2026) : Génération des SBOM initiaux : priorité aux produits actuellement commercialisés et aux composants à risque élevé (réseau, crypto, parseurs). Pour les projets Yocto/Buildroot, intégration du plugin de génération dans le pipeline. Pour les projets bare-metal, inventaire manuel et saisie dans l'outil de gestion ;
• Mois 4 (août 2026) : Mise en place du processus de veille CVE/EUVD et test de corrélation. Vérification que les identifiants CPE/PURL dans les SBOM génèrent des correspondances dans les outils de corrélation. Résolution des composants sans identifiant standardisé ;
• Avant le 11 septembre 2026 : Le SBOM et le processus de veille sont opérationnels. CVD publiée. PSIRT désigné. Canal de signalement actif.

Ce calendrier est serré mais tenable pour un fabricant de taille moyenne avec des ressources dédiées. Pour une PME de moins de cinquante personnes sans compétence interne en cybersécurité produit, l'accompagnement externe sur la méthodologie SBOM et la mise en place du processus PSIRT est une hypothèse réaliste à intégrer dans le budget.

Ce que le SBOM ne fait pas

Le SBOM est un registre de composants, pas une évaluation de sécurité. Sa présence ne signifie pas que les composants listés sont sécurisés, ni que le produit est conforme aux exigences essentielles de l'Annexe I. Un SBOM complet peut lister des composants comportant des vulnérabilités connues. C'est précisément son intérêt : les rendre visibles.

De même, le SBOM ne remplace pas l'analyse de risque exigée par la prEN 40000-1-2 et l'Annexe I. L'analyse de risque évalue les menaces, les vecteurs d'attaque, et la probabilité et l'impact d'exploitation dans le contexte d'usage spécifique du produit. Un composant présentant une CVE critique dans la NVD peut avoir une sévérité réduite dans un contexte spécifique : par exemple, une vulnérabilité dans une interface réseau qui n'est pas exposée dans la configuration nominale du produit. C'est l'analyse de risque, et non le SBOM seul, qui permet cette évaluation contextuelle.

Le SBOM est le registre des ingrédients. L'analyse de risque est l'évaluation des risques d'empoisonnement. Les deux sont nécessaires et complémentaires.