SBOM et CRA : ce que le règlement demande et pourquoi cela ne suffit pas

Le 5 mars 2025, nous avions publié l’article « Produire et maintenir une Software Bills of Materials (SBOM) : enjeux et pistes futures ». Le billet posait le décor et laissait ouverte la question de la génération de la SBOM. Les orientations d’application du CRA approuvées par la Commission ne disent pas un mot de la SBOM alors qu’un nouveau socle international a été publié fin juillet 2026 avec la signature de l’ANSSI et de l’autorité allemande BSI. Cette dernière a déjà écrit la spécification que le règlement n’écrit pas. À trois semaines de l’entrée en application des obligations de notification, le 11 septembre 2026, reprenons le sujet là où nous l’avions laissé : que demande exactement le CRA, comment le mettre en œuvre et pourquoi tant de nomenclatures produites (inventaires de composants logiciels ou SBOM) aujourd’hui ne suffiront-elles pas ?

Ce que le règlement demande, littéralement

Même si l’exigence de ces nomenclatures chamboulent les pratiques industrielles, le Cyber Resilience Act ne consacre pas de chapitre à la SBOM. L’obligation tient dans une phrase, à l’Annexe I partie II point 1 relative à la documentation qui est à la charge du fabricant :

identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products

La version française officielle parle d’établir « une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits ».

La SBOM est le moyen et non la fin, ainsi établir une nomenclature reste exigé, mais le règlement en fait un moyen (« including by », « notamment par ») d’une obligation qui est d’identifier et de documenter les vulnérabilités et les composants. Le critère de réussite n’est donc pas la conformité formelle du document, c’est sa capacité à servir la gestion des vulnérabilités.

Il en découle quelques limites :

• Le seuil de profondeur n’est défini nulle part. L’expression « dépendances de niveau supérieur » apparaît une seule fois dans tout le règlement, à ce point 1, et aucune disposition ne dit ce qu’elle recouvre. La définition de l’article 3 point 39 mentionne les relations avec la chaîne d’approvisionnement sans dire un mot du périmètre. C’est par ailleurs un plancher, pas un plafond : le texte dit « au moins ». Il faut comprendre que seul le premier niveau, c’est-à-dire les dépendances déclarées (et connues) est compris.
• La publication de la SBOM n’est pas « obligatoire ». L’Annexe II point 9 est explicite : « If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed ». Ce qui devient obligatoire n’est pas la nomenclature elle-même, mais l’indication du lieu où la trouver, et seulement si le fabricant a décidé de la mettre à disposition. Cela invalide au passage une lecture répandue/attendue, selon laquelle la SBOM serait due aux clientes et clients sur simple demande. Elle figure en revanche dans la documentation technique, à l’Annexe VII point 2 b. C’est l’article 13 paragraphe 22 qui fonde l’obligation de fournir cette documentation aux autorités de surveillance du marché sur demande motivée. La fourniture des SBOMs va donc certainement être une obligation contractuelle de plus en plus fréquente, d’autant plus lorsque le client est lui-même soumis au CRA et à l’obligation de concevoir et maintenir ses SBOMs.

Pour le reste, le règlement autorise la Commission à préciser « le format et les éléments » de la SBOM. Il s’agit d’actes d’exécution, soumis à la procédure d’examen de l’article 62 paragraphe 2, et non d’actes délégués : le texte dit « peut », et non « doit », et aucun acte pris sur ce fondement n’a été adopté à ce jour. Les obligations de l’Annexe I ne devenant exigibles que le 11 décembre 2027, la fenêtre reste ouverte, sans garantie qu’elle soit utilisée.

Nous avons déjà souligné dans un précédent article consacré à la guidance du CRA de la commission, le manque de précision au sujet de la SBOM:

• il n’est ni question de la granularité ni des formats, comme l’avaient déjà souligné les échanges d’OW2con’26.
• sur les deux documents approuvés le 27 juillet 2026, le terme « SBOM » n’apparaît pas une seule fois, ni l’expression « bill of materials ». A priori, la normalisation en cours ne comblera pas ce vide à court terme.
• Le mandat M/606, accepté par le CEN, le CENELEC et l’ETSI le 3 avril 2025, porte sur quarante-et-une normes, et son programme de travail ne mentionne pas une fois la SBOM. La matière est rattachée à la future norme horizontale de gestion des vulnérabilités, sur laquelle nous manquons de visibilité et qui reste concentré sur un pan seulement (cyber) des SBOM.

Il faut donc regarder ailleurs.

Les travaux parallèles (ANSSI, BSI, NSA, FBI & cie)

Le 29 juillet 2026, la CISA a publié, avec la NSA, le FBI et quinze agences internationales couvrant treize pays, les 2026 Minimum Elements for a Software Bill of Materials. Si le document est non contraignant, figurent parmi les signataires sept autorités d’États membres de l’Union, dont l’ANSSI et le BSI, aux côtés de leurs homologues tchèque, italienne, néerlandaise, polonaise et slovaque. La DG CONNECT a contribué au document sans le signer. Ce texte remplace le socle NTIA de 2021, référence de fait de toute l’industrie depuis cinq ans. Les sept champs de données de 2021 y deviennent dix-sept.

Deux évolutions comptent pour qui produit une SBOM aujourd’hui :

• L’élément « profondeur » devient « couverture » : « An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth. » La justification vise directement l’ancienne définition, qui reflétait « les capacités de l’outillage de l’époque plutôt que la profondeur d’information nécessaire pour prendre des décisions de sécurité éclairées » (notre traduction). Le raisonnement est celui de l’inférence négative, et il est décisif : l‘intérêt opérationnel d’une nomenclature est de pouvoir conclure « ce composant n’est pas chez nous » et cette inférence ne vaut que si l’inventaire est complet.
• Les identifiants de composants entrent dans le socle minimal. Là où le texte de 2021 se contentait de recommander de les utiliser s’ils existaient, la version 2026 attend au moins un identifiant logiciel par composant, et recommande explicitement le CPE, qui désigne un produit dans le référentiel du NIST, et le package URL (purl), normalisé depuis décembre 2025 sous la référence ECMA-427. Le format du SoftWare Hash IDentifier (SWHID) poussé par Software Heritage est aussi référencé.

Tiré par l’industrie automobile, les allemands ont bien souvent un temps d’avance sur l’Open Source industriel européen. La directive technique BSI TR-03183 partie 2, dans sa version 2.1.0 du 20 août 2025, est la spécification du contenu d’une SBOM la plus détaillée publiée à ce jour en Europe. Le BSI prend soin de préciser qu’elle n’est ni contraignante ni obligatoire, qu’elle ne vaut pas présomption de conformité, et qu’elle a vocation à être remplacée par les normes harmonisées européennes. Elle n’en est pas moins rédigée en MUST, et elle circule déjà dans les cahiers des charges de grands donneurs d’ordre. Elle demande notamment :

• Les formats CycloneDX 1.6 ou supérieur, ou SPDX 3.0.1 ou supérieur, à l’exclusion des versions antérieures. Une nomenclature en SPDX 2.3, format très largement majoritaire dans la production réelle, ne satisfait pas cette exigence, et la période transitoire de six mois est close depuis février 2026.
• Une résolution récursive des dépendances couvrant l’ensemble du périmètre de livraison afin de permettre le chaînage entre nomenclatures.
• Un point de contact actionnable par composant, adresse électronique ou, à défaut, URL, et non un simple nom d’organisation.
• Une empreinte du composant déployable en SHA-512.

Les pratiques (et comment construire une SBOM qui serve)

La communication forte autour des enjeux cyber et la fourniture à la volée de SBOM promise par les outils quotidiens nous le fait oublier : au-delà du respect de la réglementation, la production de SBOM doit permettre d’outiller utilement l’ensemble des organisations dans une approche de supply chain efficace.

La standardisation des SBOMs poursuit cette objectif, cachant néanmoins parfois le pourquoi derrière le quoi : si l’obligation est d’identifier et de documenter les vulnérabilités, la question pratique indispensable est de s’assurer qu’il est possible à partir de cette nomenclature d’interroger une base de vulnérabilités et d’obtenir une réponse. Quiconque a vécu décembre 2021 et la question « est-ce que Log4Shell est chez nous ? » sait ce que coûtent, en jours-personnes, des inventaires qu’aucune machine ne sait rapprocher d’un avis de sécurité.

Un nom de composant n’est pas comparable par une machine. libtiff et tiff désignent le même projet, nss et nss-3.127-with-nspr-4.39 la même bibliothèque, et une inversion de lettres suffit à rendre une entrée introuvable. Le package URL, que nous mentionnions déjà en 2025, résout ce problème en désignant sans ambiguïté un écosystème, un projet et une version. Le SWHID va encore plus loin en rattachant ces identifiants à l’archive mondiale maintenue par Software Heritage.

Un point bloque beaucoup d’équipes : un purl ne s’obtient auprès d’aucun registre, il se calcule. Il n’y a pas d’annuaire à interroger ni de clé à demander, et seuls les types de purl font l’objet d’un catalogue partagé. La chaîne s’assemble à partir d’informations que le processus de compilation possède déjà, un nom, une version, une adresse de téléchargement, une empreinte :

pkg:generic/openssl@3.5.7?checksum=sha256:<empreinte>&download_url=https://<miroir>/openssl-3.5.7.tar.gz

Une fois ce champ rempli, le reste devient automatisable. Des services publics et gratuits comme ecosyste.ms, deps.dev ou OSV prennent un purl en entrée et renvoient licence, dépôt d’origine, équipe de maintenance ou vulnérabilités connues. ClearlyDefined rend un service voisin mais impose de convertir le purl vers son propre système de coordonnées. L’objection habituelle, « remplir tout cela à la main serait interminable », ne tient que tant qu’il manque l’identifiant qui permet d’aller chercher le reste. C’est notamment sur la base de cette approche que des outils tel que Hermine-FOSS (logiciel Open Source coédité avec Enedis, RTE, Lectra, OVH et inno³) peuvent étendre très facilement les services apportées en matière de conformité Open Source à ceux de gestion de vulnérabilité, de contrôle export ou encore de vitalité des projets communautaires. Un article dédié viendra prochainement prolonger ce sujet.

Nous avons vérifié ce que valent les nomenclatures effectivement publiées, sur cinq projets majeurs, à partir des SBOM que GitHub génère automatiquement pour tout dépôt public : curl, OpenSSL, CPython, Node.js et Kubernetes. Sur la base d’un relevé du 21 août 2026 : 3 173 entrées, dont 3 168 composants une fois retirés les cinq paquets décrivant les dépôts eux-mêmes :

• Sur la forme, rien à redire : les cinq documents passent la validation SPDX sans une seule erreur, et tous les composants portent un purl, ce qui est précisément le point difficile. Ces documents sont émis en SPDX 2.3 (version que la directive technique allemande n’accepte plus).
• Sur le fond, aucune des 3 173 entrées ne porte de champ producteur, ni d’empreinte. Ce ne sont pas des champs renseignés à NOASSERTION, la valeur conventionnelle qui signale une information non déterminée ; ce sont des champs absents, alors que le même outil sait produire des NOASSERTION explicites ailleurs. Or le producteur du composant, la valeur d’empreinte et son algorithme figurent tous les trois parmi les dix-sept éléments du socle 2026.

Des nomenclatures structurellement irréprochables, produites automatiquement par un outillage de qualité, ne satisfont donc pas le socle sur le contenu. Et elles décrivent des dépendances déclarées, non le contenu réel d’un artefact distribué. Le profil symétrique existe aussi, plus fréquent qu’on ne le croit : des chaînes de génération maintenues à la main, qui produisent des empreintes exactes et des licences vérifiées, mais aucun identifiant exploitable. Il faut viser l’automatisation et les standards ne sont pas négociables.

Synthèse et conclusion

L’idée première de ce billet était de rappeler l’importance de traiter l’identifiant comme la priorité, pas comme un raffinement. C’est le champ qui décide si la nomenclature sert à quelque chose. Le reste peut être complété ensuite, souvent automatiquement. À défaut de tout couvrir, un énoncé explicite du périmètre est une position défendable, et le socle 2026 lui donne un nom, « Explicitly Identifying Unknown Information », en distinguant ce qui est inconnu de ce qui est volontairement retenu.

On peut aussi rappeler l’importance de vérifier ce qui est produit, y compris par les éditeurs de solutions numériques qui produisent de plus en plus des SBOM à la volée incomplets ou non standard (et même souvent difficilement importables dans une chaîne de CI/CD). La commande pyspdxtools contrôle la conformité SPDX, la bibliothèque packageurl-python valide les identifiants ; toutes deux sont libres et fonctionnent sans accès réseau. Dans une chaîne d’intégration continue, elles valent mieux que n’importe quelle correction ponctuelle, parce qu’elles empêchent la régression suivante.

Enfin, il faut voir plus loin que le CRA dès aujourd’hui. Le CRA n’exige qu’un minimum, mais montre une voie. Le socle cosigné par l’ANSSI et le BSI demande la couverture complète, et la spécification allemande la détaille déjà. Il n’y aurait aucun sens à se limiter à construire une chaîne qui ne sait produire que le premier niveau.

Ces quatre points seront intégrés à la version 3 du guide « Être prêt pour intégrer le Cyber Resilience Act dans sa pratique Open Source », coproduit avec le CNLL.

Un dernier mot sur ce qui dépasse la conformité produit. L’article 13 paragraphe 25, très peu commenté, prévoit que le groupe de coopération administrative puisse décider d’une évaluation de la dépendance de l’Union à certains composants, « en particulier des composants qui répondent aux critères de logiciels libres et ouverts », et que les autorités de surveillance du marché puissent réclamer à cette fin les nomenclatures des fabricants, avant de remonter des informations anonymisées et agrégées. La nomenclature devient alors un instrument de politique publique, qui rendra visible ce dont l’Europe dépend réellement : le sujet rejoint directement les chantiers ouverts par le rapport parlementaire sur les dépendances numériques, et prolonge la lecture du CRA comme levier stratégique que nous défendons depuis 2024. C’est un usage de plus pour un document que beaucoup produisent encore par obligation, et que d’autres exploitent déjà en conformité export control.

Crédit : « Objectif Sigma 28mm f1.8 II aspherical en monture Pentax » by Fiseha Hailemichael is licensed under CC BY 2.0.