Réponse courte : oui. Le règlement sur la cyberrésilience, règlement (UE) 2024/2847, exige de tout fabricant d'un produit comportant des éléments numériques dans son champ qu'il établisse une nomenclature logicielle. C'est l'une des huit exigences de gestion des vulnérabilités de l'annexe I, partie II, qui s'appliquent à tout produit dans le champ sans « le cas échéant » et sans seuil de taille, à partir du 11 décembre 2027.

La réponse longue tient en trois phrases du règlement, et chacune tranche une question que l'on pose sans cesse.

L'exigence : annexe I, partie II, point 1

Les fabricants « recensent et documentent les vulnérabilités et les composants contenus dans les produits comportant des éléments numériques, y compris en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau des produits ».

Quatre choses sont fixées par cette phrase.

C'est obligatoire. La SBOM est le moyen nommé pour recenser et documenter les composants. Il n'y a pas de chemin vers le point 1 sans elle.

Le format est « couramment utilisé et lisible par machine ». Le règlement ne nomme ni CycloneDX ni SPDX, et il n'en a pas besoin : les deux sont couramment utilisés et lisibles par machine, et l'un comme l'autre satisfont au texte. Un tableur est lisible par machine au sens faible et n'est pas couramment utilisé à cette fin ; ne vous y fiez pas.

La profondeur est « au minimum les dépendances de premier niveau ». C'est le plancher, pas la recommandation. Premier niveau signifie les paquets que votre produit déclare directement. Les dépendances transitives sont là où se trouvent la plupart des vulnérabilités connues, donc une SBOM limitée au premier niveau respecte la lettre et laisse faible la moitié « recensement des vulnérabilités » du point 1. La plupart des outils produisent de toute façon le graphe complet.

Elle couvre « les produits », au pluriel, produit par produit. Une SBOM par produit comportant des éléments numériques, par version qui influe sur la conformité (l'annexe VII, point 1 b), demande les versions). Une SBOM unique pour toute l'organisation n'y satisfait pas.

Où elle va : annexe VII, points 2 b) et 8

La SBOM fait partie de la documentation technique. L'annexe VII, point 2 b), cite « la nomenclature logicielle » parmi les spécifications de gestion des vulnérabilités que le dossier doit contenir. C'est un document que vous conservez, daté, avec le dossier, pendant dix ans ou la période d'assistance, la plus longue des deux.

Le point 8 de la même annexe répond à la question que tout le monde pose ensuite : devons-nous la publier ? Non. La SBOM est fournie « à la suite d'une demande motivée d'une autorité de surveillance du marché, pour autant qu'elle soit nécessaire pour permettre à cette autorité de vérifier la conformité avec les exigences essentielles de cybersécurité énoncées à l'annexe I ». Elle est communiquée à une autorité, sur demande, avec un motif. Rien dans le règlement n'exige de la publier aux clients ou au public, mais rien ne l'interdit non plus : l'annexe II, point 9, dit que si le fabricant décide de mettre la SBOM à la disposition des utilisateurs, les informations utilisateur doivent indiquer où elle est accessible. Le questionnaire de sécurité d'un client peut de toute façon la demander.

Ce que cela ne tranche pas

Les détails de format. La Commission peut préciser le format et les éléments de la SBOM par acte d'exécution (article 13, paragraphe 24). Jusque-là, « couramment utilisé et lisible par machine » est la norme, et les deux formats ouverts y répondent.

La profondeur au-delà du premier niveau. Le règlement fixe un plancher. Qu'une autorité, un organisme notifié ou un client accepte le seul premier niveau est une question pratique à la réponse prévisible : plus la SBOM est profonde, moins il y a de questions.

Les composants matériels. Le point 1 dit « vulnérabilités et composants », et la SBOM est une nomenclature logicielle. Pour un produit matériel, le dossier doit encore recenser les composants (l'annexe VII, point 1 c), veut l'agencement interne), mais l'exigence de lisibilité par machine est formulée pour le logiciel.

Quoi faire

Générez la SBOM à partir de la construction, pas à la main, en CycloneDX ou SPDX, pour chaque produit et chaque version pertinente pour la conformité, et stockez-la avec le dossier technique. Gardez la génération dans le pipeline de livraison pour que la SBOM du dossier soit celle du produit livré et non celle du trimestre dernier. Rédigez une procédure SBOM d'une page qui dit quel outil, quel format, quelle profondeur, où elle est stockée et qui répond à une demande motivée ; cette procédure est l'un des quatre documents opérationnels que la partie II présuppose, et c'est ce qu'un auditeur demande à voir avant la SBOM elle-même.

Et gardez le volet vulnérabilités en vue : le point 1, c'est « recenser et documenter les vulnérabilités et les composants ». La SBOM est la moitié composants. La moitié vulnérabilités est l'analyse qui la lit, et au moment où cette analyse montre une vulnérabilité exploitée, l'horloge de 24 heures de l'article 14 est la chose suivante à laquelle penser.

Ce que le règlement vous demande ensuite pour chaque composant de cette liste, la diligence raisonnable de l'article 13(5), le signalement en amont de l'article 13(6) et le test des « vulnérabilités exploitables connues » à la sortie, fait l'objet de l'article compagnon, d'après les orientations de la Commission.

Sources

  • Règlement (UE) 2024/2847, annexe I, partie II, point 1 (cité) ; annexe II, point 9 ; annexe VII, points 1 b), 1 c), 2 b) et 8 ; article 13, paragraphe 24, sur l'acte d'exécution relatif au format de la SBOM ; article 71, paragraphe 2, pour les dates. Lu dans le texte du Journal officiel sur EUR-Lex le 11 septembre 2026.

Ceci n'est pas un avis juridique. Les trois phrases ci-dessus sont assez courtes pour être lues dans le règlement lui-même, et c'est là qu'une décision sur votre produit doit reposer.