Aller au contenu
FRENDécrivez votre besoin

SBOM : ce que le Cyber Resilience Act demande, et comment le produire

Un SBOM est l’inventaire des composants d’un logiciel. Ce qu’il contient, les formats CycloneDX et SPDX, ce que le Cyber Resilience Act exige et à partir de quand, et comment le produire à chaque livraison.

Par Publié le 4 octobre 2026

Un SBOM (software bill of materials, ou nomenclature logicielle) est la liste des composants qui entrent dans un logiciel, avec leurs versions, leur origine et les liens entre eux, dans un format qu’une machine sait lire. Quand une faille est publiée sur une bibliothèque, il permet de savoir en quelques minutes quels produits l’embarquent, et dans quelle version.

Le Cyber Resilience Act européen en fait une obligation : à partir du 11 décembre 2027, les fabricants de produits comportant des éléments numériques, logiciels compris, devront en établir un pour ce qu’ils mettent sur le marché de l’Union européenne.

À quoi sert un SBOM ?

Le 9 décembre 2021, une faille critique est rendue publique dans Log4j, une bibliothèque de journalisation très répandue dans les logiciels écrits en Java (Log4Shell, CVE-2021-44228). Dans son rapport de juillet 2022, le Cyber Safety Review Board, comité américain d’examen des incidents de cybersécurité, constatait que bien des organisations ne savaient pas où se trouvait le logiciel vulnérable ; un ministère fédéral y avait consacré 33 000 heures de travail. Il recommandait de développer les outils de SBOM.

Un SBOM répond sans fouiller le code : quels composants, dans quelles versions, dans quels produits. Il sert aussi à vérifier les licences des composants open source, et à évaluer un logiciel acheté avant de l’installer. Il révèle enfin une dépendance inattendue, comme les paquets inventés par les assistants de code, dont parle notre article sur le vibe coding.

Ce que contient un SBOM

En juillet 2021, la NTIA, l’agence américaine chargée des télécommunications, a fixé sept informations de base pour chaque composant :

  • le nom du fournisseur ;
  • le nom du composant ;
  • sa version ;
  • d’autres identifiants uniques ;
  • ses relations de dépendance ;
  • l’auteur des données du SBOM ;
  • la date de création.

Les exigences ont monté depuis. En juillet 2026, la CISA, l’agence américaine de cybersécurité, a publié des éléments minimaux révisés, cosignés par des agences de plusieurs pays dont l’ANSSI et le BSI, son homologue allemand : ils ajoutent notamment l’empreinte (hash) de chaque composant, sa licence, l’outil qui a produit le SBOM et l’étape où il a été produit (à partir du code source, à la construction du logiciel).

Le BSI va plus loin dans sa norme technique TR-03183-2 (version 2.1.0, août 2025) : il demande de suivre les dépendances de proche en proche, jusqu’au premier composant qui n’est pas livré avec le produit, avec une empreinte SHA-512 de chaque composant livré.

CycloneDX ou SPDX : quel format ?

Deux formats ouverts se partagent l’essentiel des usages :

  • CycloneDX, projet de l’OWASP normalisé par Ecma International sous le nom ECMA-424, en version 1.7 depuis octobre 2025. Il est pensé pour la sécurité : composants, services, failles connues.
  • SPDX, projet de la Linux Foundation, devenu la norme internationale ISO/IEC 5962:2021 dans sa version 2.2.1 ; la version 3.0 date d’avril 2024. Il vient du suivi des licences open source.

Le Cyber Resilience Act n’impose pas de format : il demande un format couramment utilisé et lisible par machine. La Commission européenne peut le préciser par un acte d’exécution, qu’elle n’avait pas adopté au 4 octobre 2026. Le BSI accepte CycloneDX à partir de la version 1.6 et SPDX à partir de la version 3.0.1. Dans l’enquête publiée par l’ENISA, l’agence européenne de cybersécurité, en juin 2026 auprès de 334 organisations, 44 % utilisaient CycloneDX et 29 % SPDX.

Ce que le Cyber Resilience Act demande, et à partir de quand

Le Cyber Resilience Act (règlement (UE) 2024/2847) fixe des exigences de cybersécurité pour les produits comportant des éléments numériques, matériels et logiciels, vendus dans l’Union. Sur le SBOM, son annexe I (partie II, point 1) demande aux fabricants d’identifier et de documenter les composants et les failles de leurs produits, notamment en établissant un SBOM couvrant au minimum les dépendances de premier niveau.

  • 10 décembre 2024 : entrée en vigueur du règlement.
  • 11 septembre 2026 : obligation de signaler les failles activement exploitées et les incidents graves, produits déjà sur le marché compris : une alerte précoce sous 24 heures, une notification sous 72 heures, par la plateforme unique de signalement ouverte ce jour-là.
  • 11 décembre 2027 : application des autres obligations, dont le SBOM.

Le SBOM fait partie de la documentation technique du produit. Il n’a pas à être publié : le règlement précise que les fabricants n’y sont pas obligés, et ils le remettent à une autorité de surveillance du marché qui le demande de façon motivée. Les manquements aux exigences essentielles exposent à une amende pouvant atteindre 15 millions d’euros ou, si ce montant est supérieur, 2,5 % du chiffre d’affaires mondial annuel.

Le texte vise les logiciels fournis dans le cadre d’une activité commerciale, avec les traitements à distance sans lesquels ils ne fonctionnent pas. Les services en ligne purs (SaaS) relèvent plutôt de la directive NIS2, et un logiciel open source diffusé hors de toute activité commerciale reste hors du champ. Le projet de simplification européen présenté en novembre 2025, dit « Digital Omnibus », ne modifie pas ces dates ; il était encore en discussion au Parlement européen au 4 octobre 2026.

Les entreprises s’y préparent inégalement : dans l’enquête de l’ENISA, 78 % des organisations interrogées avaient commencé à adopter le SBOM, mais 9 % avaient un processus mûr et automatisé ; 43 % disaient que le Cyber Resilience Act avait nettement accéléré leurs investissements. Aux États-Unis, le décret présidentiel 14028 de mai 2021 avait lancé le mouvement pour les fournisseurs de l’administration fédérale ; depuis janvier 2026, une note de la Maison-Blanche (M-26-05) laisse chaque administration exiger un SBOM par contrat.

Produire un SBOM à chaque livraison

Un SBOM écrit à la main est faux dès la livraison suivante. Il se produit dans la chaîne de livraison (CI/CD, l’automatisation qui construit, teste et déploie le logiciel) :

  • Le générer à chaque construction, à partir des fichiers de versions figées et de l’analyse du logiciel construit, plutôt que de la liste des dépendances déclarées.
  • Le ranger avec la version livrée, signé, et le garder aussi longtemps que cette version est maintenue.
  • Le contrôler : un SBOM vide, incomplet ou au mauvais format fait échouer la livraison.
  • Le relier à une veille des failles, pour être alerté quand une faille connue touche un composant d’une version encore en service.

Après le SBOM : suivre les failles

Un SBOM dit ce que contient un produit ; il ne dit pas si la faille connue d’un composant est exploitable dans ce produit. C’est le rôle du VEX (Vulnerability Exploitability eXchange) : une déclaration qui indique, faille par faille, si le produit est touché, corrigé, pas concerné ou en cours d’analyse. Le BSI demande de garder ces informations hors du SBOM et recommande de les publier au format CSAF (Common Security Advisory Framework), une norme OASIS depuis novembre 2022, qui comprend un profil VEX.

Ce suivi prépare aussi aux signalements du Cyber Resilience Act : savoir vite qu’un produit est touché laisse le temps d’envoyer l’alerte précoce dans les 24 heures.

Par où commencer

  • Recenser les produits concernés : les logiciels et les appareils que vous vendez ou fournissez dans l’Union.
  • Produire un premier SBOM par produit, automatiquement, en CycloneDX ou en SPDX.
  • Le relier à une veille des failles, avec un responsable par produit.
  • Organiser les signalements de failles exploitées, déjà obligatoires depuis le 11 septembre 2026.

C’est ce que couvre notre offre La sécurité dans chaque livraison : l’inventaire des bibliothèques de vos applications, une alerte quand une faille connue les touche, et des règles de mise en production. Voir aussi DevOps et CI/CD. Pour en parler avec un ingénieur : la journée de cadrage offerte.

Questions fréquentes

Faut-il publier son SBOM ?

Non, pas au titre du Cyber Resilience Act : il fait partie de la documentation technique et se remet aux autorités sur demande motivée. Vous pouvez le partager avec vos clients ; la notice du produit indique alors où le trouver.

Le Cyber Resilience Act s’applique-t-il à un logiciel en SaaS ?

Un service en ligne pur relève en principe de la directive NIS2. Le Cyber Resilience Act vise en revanche le logiciel installé ou l’appareil que vous vendez, avec les traitements à distance sans lesquels il ne fonctionne pas.

Faut-il lister les dépendances indirectes ?

Le règlement demande au minimum les dépendances de premier niveau ; la norme du BSI va jusqu’aux dépendances indirectes. Les outils de génération les listent de toute façon, et les garder évite de rater une faille enfouie plusieurs niveaux plus bas.

Un SBOM suffit-il pour être en règle ?

Non. Le Cyber Resilience Act demande aussi la sécurité dès la conception, le traitement des failles pendant toute la durée de support, des mises à jour de sécurité et les signalements. Le SBOM est l’une de ces pièces.

Sources

Faits et chiffres vérifiés le 4 octobre 2026.