Le SBOM, la liste des composants de votre produit

Un SBOM (software bill of materials) est la liste des composants logiciels d’un produit, avec leurs versions, dans un fichier qu’une machine sait lire. Le Cyber Resilience Act (CRA), ou règlement sur la cyberrésilience, l’appelle « nomenclature des logiciels » et l’exige pour tout produit connecté : au minimum les dépendances de premier niveau, dans un format courant (annexe I, partie II, point 1). Vous la gardez dans votre dossier ; vous n’êtes pas obligé de la publier.

Ce que dit le texte, mot pour mot ou presque

Le règlement définit la nomenclature des logiciels comme un registre formel qui détaille les composants utilisés pour fabriquer le produit et leurs liens avec la chaîne d’approvisionnement (article 3).

L’obligation elle-même tient en une phrase de l’annexe I, partie II, point 1 : le fabricant recense et documente les composants et les vulnérabilités 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 niveau supérieur.

« Niveau supérieur » veut dire les composants que vous avez intégrés directement. Si votre firmware embarque une bibliothèque MQTT qui dépend elle-même d’une bibliothèque TLS, la loi exige au minimum la première. Lister aussi la seconde n’est pas obligatoire, mais c’est souvent là que se cachent les failles.

Qui voit votre SBOM

Qui	Quand	Source
Vous	Toujours. Il fait partie du processus de gestion des failles décrit dans le dossier technique	Annexe VII, point 2(b)
L’autorité de surveillance du marché	Sur demande motivée, si elle en a besoin pour vérifier l’annexe I	Annexe VII, point 8
Vos utilisateurs	Seulement si vous choisissez de le partager. Vous indiquez alors où le trouver dans la notice	Annexe II, point 9

L’autorité peut aussi demander des SBOM pour étudier la dépendance de l’Union à certains composants, en particulier open source (article 13, paragraphe 25).

En France, la surveillance du marché pour le CRA revient à l’ANFR, avec l’appui de l’ANSSI. Voyez notre page sur l’ANSSI.

Quel format choisir

Le règlement ne fixe pas de format. Il permet à la Commission de préciser le format et le contenu par acte d’exécution (article 13, paragraphe 24) ; à ce jour, cet acte n’existe pas.

En attendant, deux formats dominent et sont tous deux « couramment utilisés » :

• CycloneDX, porté par la fondation OWASP, très répandu dans les outils de sécurité ;
• SPDX, une norme ISO née dans le monde des licences open source.

L’ENISA, l’agence européenne de cybersécurité, a publié en octobre 2026 un avis technique sur les SBOM (version 1.10). Il ne remplace pas l’acte d’exécution, mais c’est la lecture la plus officielle disponible aujourd’hui.

En pratique : produisez les deux formats si votre outil le permet. Un client ou un auditeur vous demandera l’un ou l’autre, rarement les deux.

Ce qu’un bon SBOM contient

Un fichier qui liste « linux, openssl, busybox » sans versions ne sert à rien face à une faille. Pour chaque composant, visez au moins :

• le nom exact et le fournisseur ;
• la version précise, pas « 1.x » ;
• un identifiant standard quand il existe, comme un PURL ou un CPE (des codes qui nomment un paquet de façon unique, pour que les bases de failles le reconnaissent) ;
• la licence, utile pour vos clients même si le CRA ne la demande pas.

Et un SBOM par version livrée. Le firmware 2.3 et le firmware 2.4 n’ont pas la même liste, et c’est sur la version réellement installée chez le client que porte une alerte.

Le problème des fabricants d’objets connectés

Les outils SBOM classiques lisent le code source et le fichier de dépendances d’un projet. Or beaucoup d’appareils contiennent des morceaux dont vous n’avez pas la source : le SDK du fabricant de la puce, un module Wi-Fi livré en binaire, une image Linux préparée par un sous-traitant. L’article 13, paragraphe 5, vous demande pourtant de faire preuve de diligence sur ces composants tiers.

La seule façon de voir ce qui part vraiment chez le client est de regarder le fichier final : l’image que vous flashez ou que vous mettez en téléchargement.

Le SBOM ne prouve pas l’absence de faille

Le SBOM couvre le point 1 de la partie II. Il sert aussi de point de départ pour le point (2)(a) de la partie I, « aucune vulnérabilité exploitable connue », mais il ne suffit pas à le prouver. Un composant sans version visible, un correctif rétroporté par la distribution Linux, une faille pas encore publiée : autant de cas où la liste ne dit pas tout. Un rapport honnête le dit.

Ce que fait Proofsheet

Proofsheet est une application web. Vous envoyez le fichier que vous livrez : image de firmware (gzip, tar, zip, cpio, partitions MBR), application Android, programme Windows, Linux ou Apple, JavaScript, WebAssembly. L’application en tire la liste des composants et des versions quand le fichier les montre, et la génère en CycloneDX 1.5 et en SPDX 2.3.

Chaque version exacte est comparée à la base NVD des failles connues. Quand seule la famille de versions correspond, le rapport l’écrit en toutes lettres, sans la faire passer pour une correspondance confirmée. Les failles présentes sur la liste des failles exploitées de la CISA sont repérées. Un firmware chiffré ne peut pas être ouvert : le rapport le dit et vous ne payez pas.

L’aperçu gratuit montre les trois principaux risques. Le SBOM complet et le rapport de risque coûtent 99 € pour une version. Le fichier envoyé est supprimé sous 24 heures. C’est une preuve technique, pas un certificat juridique.

Générer un rapport, ou lisez la documentation technique et le signalement.