SBOM : la nomenclature logicielle exigée par le CRA

Un SBOM (software bill of materials, ou nomenclature logicielle) est l'inventaire formel et lisible par machine de tous les composants qui constituent un logiciel, avec leurs versions, leurs fournisseurs et leurs dépendances. Le Cyber Resilience Act (CRA) en fait une obligation pour les fabricants de produits numériques vendus dans l'Union européenne. Pour leurs clients, c'est l'outil qui permet de répondre vite à la question que pose chaque nouvelle faille : « suis-je concerné ? ». Cet article fait partie de notre dossier sur le Cyber Resilience Act.

L'expression vient de l'industrie : la nomenclature (bill of materials) est la liste des pièces qui composent un produit manufacturé. Transposée au logiciel, elle recense les bibliothèques open source, modules commerciaux et autres briques qu'un éditeur a assemblés pour construire son application. Un logiciel moderne en contient souvent des centaines, dont une bonne partie n'a pas été choisie directement par l'éditeur : chaque bibliothèque utilisée apporte ses propres dépendances, qui en apportent d'autres.

On distingue donc les dépendances directes (dites de premier niveau), que l'éditeur a explicitement intégrées, et les dépendances transitives, embarquées par ricochet. C'est souvent dans ces dernières que se cachent les mauvaises surprises.

Un SBOM n'est utile que s'il est lisible par machine : un tableur rédigé à la main ne permet pas de croiser automatiquement des milliers de composants avec les bases de vulnérabilités publiques. D'où l'importance des formats normalisés, présentés plus bas.

Le déclic est venu en décembre 2021 avec Log4Shell (CVE-2021-44228), une faille critique dans Log4j, bibliothèque de journalisation Java présente dans d'innombrables produits. L'alerte du CERT-FR, publiée le 10 décembre 2021, conseillait de vérifier aussi les applications internes et de contacter le développeur ou l'éditeur de chaque produit pour savoir s'il était exposé. Faute de savoir ce que contenaient leurs logiciels, beaucoup d'organisations ont dû interroger leurs fournisseurs un par un. L'équipe sécurité de Google a compté, au 16 décembre 2021, 35 863 paquets Java du dépôt Maven Central dépendant de Log4j (plus de 17 000 pour le seul module vulnérable, log4j-core, au 19 décembre), et relevé que la plupart n'en dépendaient qu'indirectement.

Depuis, les attaques visant la chaîne d'approvisionnement logicielle se sont multipliées, et les autorités ont fait du SBOM un pilier de la transparence. Aux États-Unis, le décret présidentiel 14028 de mai 2021 en a fait un élément de la sécurité des logiciels achetés par l'administration fédérale. En Europe, le CRA l'impose. L'ENISA constatait en juin 2026, dans son état des lieux de l'adoption, que le règlement agissait comme un « accélérateur » : les organisations investissent dans la génération automatique de SBOM et son intégration au cycle de développement.

Les éléments minimaux de la NTIA (2021)

La première référence est le document publié le 12 juillet 2021 par la NTIA, agence du département américain du Commerce. Il fixe sept champs de données : le fournisseur, le nom du composant, sa version, d'autres identifiants uniques, les relations de dépendance, l'auteur du SBOM et sa date de création. Il exige aussi un format automatisable et des pratiques : fréquence de mise à jour, profondeur (au minimum les dépendances de premier niveau), signalement des inconnues, modalités de diffusion.

La mise à jour de 2026, cosignée par l'ANSSI

Fin juillet 2026, la CISA a publié avec la NSA, le FBI et quinze agences étrangères, dont l'ANSSI, le BSI allemand et l'ACN italienne, une version révisée : les 2026 Minimum Elements for a SBOM. Elle sépare les métadonnées du SBOM et les données des composants, et ajoute notamment l'empreinte cryptographique du composant et son algorithme, la licence, le nom et la version de l'outil de génération, le contexte de génération (le moment du cycle de vie où le SBOM a été produit) et la signature de l'auteur. Elle n'impose plus de profondeur minimale limitée au premier niveau : elle vise l'ensemble des composants, y compris transitifs.

La directive technique TR-03183-2 du BSI

En Europe, la référence la plus détaillée est la TR-03183-2 du BSI, conçue pour préparer les fabricants au CRA (version 2.1.0 de 2025, régulièrement mise à jour). Elle impose CycloneDX 1.6 ou SPDX 3.0.1 au minimum, en JSON ou XML, et liste pour chaque composant : créateur, nom, version, nom de fichier, dépendances, licences, empreinte SHA-512 et quelques propriétés techniques. Elle demande de résoudre les dépendances récursivement et interdit d'y mettre des informations de vulnérabilité, qui relèvent d'autres documents (CSAF ou VEX).

SPDX

SPDX (Software Package Data Exchange), porté par la Linux Foundation, est né pour la conformité des licences open source. Sa version 2.2.1 est normalisée sous la référence ISO/IEC 5962:2021, et la version 3 a élargi le format à la sécurité.

CycloneDX

CycloneDX, projet phare de l'OWASP, a été conçu d'emblée pour la sécurité et la gestion des risques de la chaîne d'approvisionnement. Il est normalisé par Ecma International sous la référence ECMA-424. Il sait aussi décrire des services, des matériels ou des modèles d'IA.

Les deux formats sont reconnus par tous les guides cités ; l'analyse de l'ENISA de décembre 2025 recommande d'utiliser leur dernière version. Le choix dépend surtout des outils de votre chaîne de développement et de ceux de vos clients.

Le VEX : dire si la faille est exploitable

Un SBOM indique qu'un composant est présent, pas qu'il est exploitable. Une bibliothèque vulnérable peut être embarquée sans que la fonction fautive soit jamais appelée. Le VEX (Vulnerability Exploitability eXchange) comble ce manque : c'est une déclaration du fabricant qui, pour une vulnérabilité et un produit donnés, attribue l'un des quatre statuts définis par la CISA : non affecté, affecté, corrigé ou en cours d'analyse, avec une justification lorsque le produit n'est pas affecté. Le VEX s'exprime en CycloneDX ou dans le format d'avis de sécurité CSAF, que le BSI recommande.

La partie II de l'annexe I du règlement (UE) 2024/2847 énumère les exigences de gestion des vulnérabilités. Son premier point impose au fabricant d'identifier et de documenter les vulnérabilités et les composants du produit, « notamment en établissant une nomenclature des logiciels dans un format couramment utilisé et lisible par machine », couvrant au moins les dépendances de premier niveau du produit.

Plusieurs dispositions complètent cette exigence :

• Documentation technique : l'annexe VII mentionne le SBOM dans la description des processus de gestion des vulnérabilités (point 2 b) et prévoit sa remise à l'autorité de surveillance du marché sur demande motivée (point 8).
• Format harmonisé à venir : l'article 13, paragraphe 24, permet à la Commission de préciser par acte d'exécution le format et les éléments du SBOM. Au 28 septembre 2026, aucun acte de ce type n'avait été adopté à notre connaissance ; la future norme européenne sur la gestion des vulnérabilités, en préparation au CEN-CENELEC, pourrait également en préciser le contenu.
• Évaluation des dépendances : l'article 13, paragraphe 25, autorise les autorités à demander les SBOM de certaines catégories de produits pour mesurer la dépendance de l'Union à des composants, notamment open source.
• Calendrier : l'obligation s'applique aux produits mis sur le marché à partir du 11 décembre 2027. Le SBOM doit être tenu à jour pendant la période de support et conservé avec la documentation technique.

Le minimum légal, le premier niveau, est en retrait des guides techniques qui visent toutes les dépendances. Or l'animation ci-dessus le montre : dans le cas de Log4Shell, la bibliothèque vulnérable était le plus souvent une dépendance transitive. Un SBOM limité au strict minimum ne l'aurait pas fait apparaître. Le SBOM sert aussi à respecter les autres obligations du CRA, comme le signalement des vulnérabilités activement exploitées et l'évaluation de la conformité, plus exigeante pour les produits importants et critiques.

Le CRA ne fait pas du SBOM un document public. Le considérant 77 le dit explicitement : les fabricants « ne devraient pas être tenus de rendre publique » la nomenclature. Concrètement :

• les autorités de surveillance du marché (l'ANFR en France, selon l'ANSSI) peuvent l'exiger dans le cadre d'un contrôle ;
• les organismes notifiés y ont accès lorsqu'ils examinent la documentation technique ;
• les utilisateurs n'y ont accès que si le fabricant le décide : la notice doit alors indiquer où le consulter (annexe II, point 9).

Pour l'acheteur, l'accès au SBOM se négocie donc par contrat. Le SBOM révélant une partie de l'architecture du produit, l'ENISA recommande un accès par niveaux (public, client authentifié, accès privilégié), avec journalisation des consultations. Prévoyez-le dans vos contrats, au besoin sous accord de confidentialité.

Gérer ses vulnérabilités

Importés dans un outil d'analyse de composants ou de gestion des vulnérabilités, les SBOM de vos fournisseurs sont croisés en continu avec les bases publiques (NVD, avis du CERT-FR, catalogue des vulnérabilités exploitées de la CISA). Quand une faille est publiée, vous savez immédiatement quels produits la contiennent, puis le VEX du fournisseur vous dit si elle est exploitable. C'est le mécanisme que montre l'animation.

Évaluer ses fournisseurs

La capacité d'un éditeur à produire un SBOM complet, à jour, dans un format standard, en dit long sur la maturité de son développement. Elle a sa place dans votre questionnaire de sécurité fournisseur et dans votre démarche de gestion des risques tiers. Un SBOM révèle aussi des signaux faibles : composants abandonnés par leurs mainteneurs, versions très anciennes, licences incompatibles avec votre usage.

Contractualiser

Dans vos contrats ou votre plan d'assurance sécurité, prévoyez :

• la remise d'un SBOM à chaque version majeure, au format SPDX ou CycloneDX, couvrant les dépendances transitives ;
• la publication de déclarations VEX ou d'avis CSAF lorsqu'une vulnérabilité importante touche un composant ;
• un délai d'information lorsqu'une vulnérabilité exploitée concerne le produit ;
• les conditions de confidentialité du SBOM.

Pour les entités soumises à NIS 2 ou à DORA, qui doivent maîtriser la sécurité de leurs fournisseurs (voir notre article sur les exigences de NIS 2 et DORA pour les tiers), ces clauses donnent une preuve concrète de diligence.