Votre client veut une SBOM : guide pour les fournisseurs de composants et de logiciels

Ce guide s'adresse aux fournisseurs d'une chaîne d'approvisionnement industrielle : ECU, écrans, contrôleurs, passerelles, variateurs, piles Linux embarqué et modules firmware. Si vous vendez du logiciel et qu'un client vous a envoyé une demande ponctuelle, commencez par comment répondre à une demande de SBOM d'un client, qui traite ce cas.

Pourquoi les OEM posent la question maintenant

La demande de SBOM d'un OEM, c'est généralement sa propre réglementation qui arrive à votre porte par le biais d'un contrat. La réglementation en jeu détermine ce que l'OEM doit détenir, et la part qui vous est répercutée.

Le règlement sur la cyberrésilience

Selon le règlement (UE) 2024/2847 sur la cyberrésilience (Cyber Resilience Act), un produit comportant des éléments numériques inclut « les composants logiciels ou matériels mis sur le marché séparément » (article 3, point 1). Un composant que vous vendez seul dans l'UE est un produit à part entière, dont vous êtes le fabricant, avec votre propre obligation de SBOM : l'annexe I, partie II, point 1, demande 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 ». Si le composant est destiné à être intégré dans d'autres produits, vos instructions doivent aussi fournir « les informations nécessaires à l'intégrateur pour se conformer » aux exigences essentielles (annexe II, point 8, f)).

L'OEM a lui aussi des obligations qui vous atteignent. Les fabricants « font preuve de diligence raisonnable lorsqu'ils intègrent dans des produits comportant des éléments numériques des composants obtenus auprès de tiers » (article 13, paragraphe 5), et lorsque l'OEM trouve une vulnérabilité dans un composant qu'il a intégré, il doit la signaler à la personne ou à l'entité qui fabrique le composant ou en assure la maintenance (article 13, paragraphe 6). Les lignes directrices de la Commission sur le CRA de juillet 2026 indiquent que les preuves de diligence raisonnable peuvent consister en une documentation obtenue auprès du fabricant du composant, et ne mentionnent pas les SBOM ; en pratique, une SBOM est souvent la documentation que demandent les OEM. Les obligations de signalement s'appliquent à partir du 11 septembre 2026, et le règlement s'applique intégralement à partir du 11 décembre 2027. Les pièces de rechange fabriquées selon les mêmes spécifications que les composants qu'elles remplacent sont exclues (article 2, paragraphe 6). Pour le reste du règlement, voir ce qu'est le CRA et le guide du CRA.

Véhicules

Le CRA ne s'applique pas aux produits relevant du règlement (UE) 2019/2144, le règlement sur la réception par type des véhicules (article 2, paragraphe 2, point c)). Les composants des véhicules réceptionnés par type arrivent sur le marché selon les règles applicables aux véhicules, et ces règles ne mentionnent jamais de SBOM.

• Le règlement ONU nº 155 (cybersécurité) impose au constructeur de recueillir et de vérifier des informations tout au long de la chaîne d'approvisionnement, afin de démontrer que les risques liés aux fournisseurs sont identifiés et gérés (5.1.1(a)), de montrer comment son système de gestion de la cybersécurité gérera les dépendances pouvant exister avec des fournisseurs sous contrat, des prestataires de services ou des sous-organisations du constructeur (7.2.2.5), et d'identifier et de gérer, pour le type de véhicule à réceptionner, les risques liés aux fournisseurs (7.3.2).
• Le règlement ONU nº 156 (mises à jour logicielles) impose que toutes les versions logicielles initiales et mises à jour soient identifiables de manière unique (7.1.1.2) et, pour chaque numéro d'identification logicielle RX (RXSWIN), un registre vérifiable décrivant l'ensemble des logiciels pertinents pour le RXSWIN (7.1.2.3).
• ISO/SAE 21434 organise le travail de cybersécurité entre OEM et fournisseur sous forme d'activités distribuées, dont le partage est convenu dans un cybersecurity interface agreement (accord d'interface de cybersécurité).
• Le SBOM Informational Report de l'Auto-ISAC (février 2025) donne les recommandations propres au secteur.

Dans l'automobile, la SBOM arrive comme une exigence contractuelle, pas légale.

Automatisation industrielle

IEC 62443-4-1 s'applique aux fournisseurs de produits pour les systèmes d'automatisation et de commande industriels. Elle ne cite pas les SBOM, mais c'est dans la pratique 6, gestion des problèmes liés à la sécurité (DM-1 à DM-6), et la pratique 7, gestion des mises à jour de sécurité (SUM-1 à SUM-5, dont SUM-3, « Dependent component or operating system security update documentation »), qu'une SBOM sert de preuve.

Machines

Le règlement (UE) 2023/1230 sur les machines s'applique à partir du 20 janvier 2027 et ne mentionne pas les SBOM. Ses exigences essentielles de protection contre la corruption (annexe III, 1.1.9) demandent que les logiciels essentiels pour la conformité soient identifiés et protégés, que « la machine ou le produit connexe identifient les logiciels installés sur ceux-ci dont ils ont besoin pour fonctionner en toute sécurité », et que la preuve des interventions dans ces logiciels soit recueillie. Les machines comportant des éléments numériques relèvent aussi du CRA, contrairement aux véhicules réceptionnés par type : c'est pourquoi les constructeurs de machines demandent dès maintenant des SBOM à leurs fournisseurs. Voir CRACI pour les constructeurs de machines et l'IoT industriel.

NIS2 et clients certifiés

Si vous fournissez des entités essentielles ou importantes, par exemple dans les semi-conducteurs, l'article 21, paragraphe 2, point d), de NIS2 impose à votre client de traiter la sécurité de la chaîne d'approvisionnement. Il ne cite pas les SBOM. Les clients en font des questionnaires, et ce sont les mesures 5.21 et 8.8 de l'annexe A d'ISO/IEC 27001 pour lesquelles une SBOM sert de preuve. Voir les SBOM comme preuves ISO 27001, SOC 2 et NIS2.

Les régimes côte à côte

Régime	S'applique à	Cite une SBOM ?	Ce qui atteint le fournisseur
Règlement sur la cyberrésilience (CRA)	Les produits comportant des éléments numériques sur le marché de l'UE, y compris les composants vendus séparément	Oui, annexe I, partie II (1)	Directement si vous mettez le composant sur le marché ; via la diligence raisonnable de l'OEM (art. 13(5)) et les signalements de vulnérabilités (art. 13(6))
UN R155 et R156	Les constructeurs de véhicules qui demandent une réception par type	Non	La gestion des risques fournisseurs (R155 7.2.2.5, 7.3.2) et l'identification des logiciels (R156), par les contrats
ISO/SAE 21434	L'ingénierie de cybersécurité des véhicules routiers, OEM et fournisseurs	Pas dans sa description publique	Des activités distribuées et un accord d'interface de cybersécurité
IEC 62443-4-1	Les fournisseurs de produits pour les systèmes d'automatisation et de commande industriels	Non	Directement si vous êtes le fournisseur du produit ; les SBOM servent de preuve pour DM et SUM
Règlement (UE) 2023/1230 sur les machines	Les machines et produits connexes sur le marché de l'UE	Non	L'identification et la protection des logiciels (annexe III 1.1.9) ; le CRA s'applique en parallèle
NIS2	Les entités essentielles et importantes	Non	Des questionnaires sur la sécurité de la chaîne d'approvisionnement et des clauses contractuelles (art. 21(2)(d), 21(3))

Quelle que soit la voie, le client a besoin de la même chose : une SBOM exacte pour chaque version logicielle que vous livrez.

Ce que les OEM demandent en général

Les exigences diffèrent d'un OEM à l'autre, mais elles convergent vers la même liste. Vérifiez votre SBOM par rapport à celle-ci avant la première livraison.

Exigence	Attente habituelle
Format	CycloneDX ou SPDX, JSON ou XML, avec une version minimale de la spécification. BSI TR-03183-2 fixe CycloneDX 1.6 ou ultérieur, ou SPDX 3.0.1 ou ultérieur.
Champs	Alignés sur les CISA 2026 Minimum Elements ou BSI TR-03183-2 : auteur, horodatage et, pour chaque composant, un nom, une version, un producteur et des identifiants
Identifiants	Une package URL partout où l'écosystème en a une, un CPE sinon, pour que les composants puissent être rapprochés des bases de vulnérabilités
Licences	Des identifiants de licence SPDX. Le spécialiste des licences de l'OEM s'en sert pour évaluer le copyleft et les autres risques de licence.
Hashes	Un hash de chaque binaire livré, pour que l'OEM puisse confirmer que la SBOM décrit le fichier reçu. Le BSI demande du SHA-512.
Profondeur	Les dépendances transitives, pas seulement le premier niveau
Granularité	Une SBOM par version logicielle ou référence livrée
Livraison et réponse	Un canal de livraison, et des délais de réponse aux questions sur les vulnérabilités

De nombreux OEM contrôlent ces points automatiquement à réception. Voir la checklist qualité SBOM pour ce que votre client vérifiera, et les outils qu'il utilise, et les exemples de SBOM pour voir à quoi ressemblent les champs dans un fichier.

Votre SBOM quand il y a peu ou pas d'open source

Un ECU ou un contrôleur bare-metal doté d'un firmware propriétaire issu de la génération de code à partir de modèles a une SBOM honnête qui peut être courte : l'application propriétaire, votre bootloader, les bibliothèques ou la calibration d'un fournisseur de silicium, et l'éventuel open source, comme une bibliothèque de cryptographie. C'est une réponse valable. Les règles :

• Listez les composants propriétaires avec vos propres identifiants : nom, version et vous-même comme producteur.
• Déclarez les inconnues connues, comme une bibliothèque fournisseur dont vous ne pouvez pas voir le contenu.
• Ne gonflez jamais la SBOM pour paraître exhaustif, et n'omettez jamais une bibliothèque open source parce qu'elle est petite.

Pour les écrans et passerelles sous Linux, c'est l'inverse : des centaines ou des milliers de composants, dont le noyau, le bootloader et les paquets du système de base (voir les appareils connectés). Une SBOM qui ne liste que votre application et quelques bibliothèques est la première chose que signale une équipe destinataire. Si vous buildez avec Yocto, voir pourquoi les scanners manquent ce que contiennent les builds Yocto.

Contrats : ce qu'il faut convenir avant la première livraison

Clause	Pourquoi c'est important
Produits et versions logicielles couverts	Pour que personne ne discute plus tard de la nécessité d'une SBOM pour une variante ou une release de maintenance
Format et version de la spécification	Leur pipeline de réception peut rejeter tout le reste
Champs et référentiel suivi	« BSI TR-03183-2 v2.1.0 » ou « CISA 2026 Minimum Elements » se teste ; « une SBOM complète », non
Déclencheur de livraison	Chaque release, chaque version logicielle livrée à l'OEM et chaque correction
Canal de livraison	Le portail fournisseurs de l'OEM, un échange de fichiers sécurisé ou un e-mail sous NDA
Confidentialité	Un NDA ou l'accord de fourniture existant, qui désigne la SBOM comme information confidentielle
Restrictions d'usage	Gestion des vulnérabilités et conformité uniquement, pas de transmission à des tiers sans accord
Notification des vulnérabilités, dans les deux sens	L'OEM signale les vulnérabilités qu'il trouve dans votre composant (CRA art. 13(6)) ; vous lui signalez les vôtres
Attentes en matière de VEX	Quel format, et en combien de temps vous évaluez une nouvelle CVE
Conservation	Combien de temps vous conservez la SBOM de chaque version, en cohérence avec la période de support du produit
Exactitude et inconnues connues	Une clause honnête sur ce que la SBOM peut et ne peut pas couvrir protège les deux parties

Le SBOM Sharing Primer de la CISA décrit le cas automobile de la même façon : les demandes de SBOM seraient intégrées aux accords d'échange d'informations habituels (par exemple accord de confidentialité, cybersecurity interface agreement, development interface agreement).

Partager sans divulguer votre PI

Une SBOM n'est pas votre code source. Elle liste des noms de composants, des versions, des producteurs, des licences, des hashes et des relations. Elle ne contient ni votre code, ni vos algorithmes, ni vos données de calibration, ni votre conception.

• Le CRA n'oblige pas les fabricants à rendre la SBOM publique (considérant 77). Elle est transmise à une autorité de surveillance du marché sur demande motivée (annexe VII, point 8).
• Les recommandations de la CISA sur le partage décrivent les canaux habituels pour les logiciels propriétaires : e-mail sous NDA, portail fournisseurs du client ou échange de documents sécurisé, ou votre propre portail à accès contrôlé, les contrats régissant la confidentialité et l'accès.
• Options pratiques : une SBOM complète par OEM sous contrat ; des identifiants pour les parties propriétaires qui ne révèlent pas les noms de projets internes ; et un document VEX séparé, pour mettre à jour le statut d'une vulnérabilité sans renvoyer la SBOM.

À quelle fréquence, et ce qui se passe après la livraison

• Une nouvelle SBOM pour chaque version logicielle livrée, sous le même identifiant que celui que l'OEM flashe ou enregistre. Pour les véhicules, cela se rattache à l'identification des logiciels de R156.
• Une SBOM corrigée lorsque vous trouvez une erreur dans une SBOM déjà envoyée.
• Une déclaration VEX ou un avis de sécurité lorsque vous avez évalué une vulnérabilité.

La question suivante, « êtes-vous touché par la CVE-X ? », arrive avec la prochaine grande vulnérabilité. Soyez prêt à y répondre version livrée par version livrée, ce qui n'est possible que si vous avez conservé la SBOM de chacune.

VEX : ce que votre client attendra ensuite

Un document VEX indique si un produit est touché par une vulnérabilité. Les Minimum Requirements for VEX de la CISA (avril 2023) définissent quatre statuts : not_affected, affected, fixed et under_investigation. Une déclaration not_affected doit donner l'une des cinq justifications suivantes, ou à défaut une déclaration d'impact :

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Une déclaration affected nécessite une déclaration d'action : ce que le client doit faire. VEX existe en trois formats : le profil VEX de CSAF 2.0, CycloneDX VEX et OpenVEX. La sortie SPDX 3.0 de Yocto inclut des données VEX par défaut (la variable SPDX_INCLUDE_VEX).

Exemple concret. Un écran sous Linux embarque OpenSSL 3.0.8. La CVE-2023-0464 décrit une consommation excessive de ressources lors de la vérification de chaînes de certificats X.509 comportant des contraintes de politique. Le traitement des politiques est désactivé par défaut, et le logiciel de l'écran ne l'active jamais. Le fournisseur envoie une déclaration OpenVEX, à titre d'illustration :

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Produire des SBOM de façon reproductible

Votre façon de builder	Façon réaliste de produire la SBOM
Logiciel buildé en CI	Générer la SBOM dans le build qui produit le logiciel livré, et la conserver avec la release
Linux embarqué basé sur Yocto	La sortie SPDX propre à Yocto (create-spdx), vérifiée pour ce qu'elle omet, ou un enregistrement du build Yocto
Firmware bare-metal issu d'outils à base de modèles	Une bibliothèque ou un outil de génération, jamais un éditeur de texte, maintenu à chaque release et validé avant l'envoi
Binaires tiers que vous intégrez	Demander sa SBOM à votre propre fournisseur ; l'analyse binaire comme substitut en attendant

Quelle que soit la voie, validez le fichier avant de l'envoyer. La checklist qualité SBOM liste les validateurs que votre client utilisera probablement, CycloneDX vs SPDX aide à choisir le format, et standardiser la génération de SBOM explique comment l'harmoniser entre les équipes.

La place de CRACI

Pour les fournisseurs qui buildent sur GitHub Actions, CRACI remplace les runners hébergés par GitHub et enregistre une SBOM à chaque build : chaque version livrée en a donc déjà une.

• La SBOM liste ce que le build a réellement récupéré, dépendances transitives comprises, avec une package URL par paquet et la licence déclarée de chaque composant.
• La SBOM de chaque job porte un état de complétude : vous savez ce que vous envoyez avant de l'envoyer.
• Les SBOM s'exportent en CycloneDX ou SPDX, et CRACI prend en charge VEX.
• Les SBOM surveillées sont réévaluées à mesure que de nouvelles vulnérabilités sont publiées, et l'historique des builds montre quels builds contenaient une dépendance vulnérable, dans la limite de votre durée de conservation.
• Les builds Yocto tournent sur les runners CRACI et sont documentés.
• Des SBOM tierces peuvent être ajoutées : les composants que vous achetez sont ainsi surveillés aux côtés de vos propres builds.

Quand CRACI n'est pas la réponse

• Vous n'avez pas de CI, ou vous buildez sur GitLab, Jenkins ou un serveur de build. CRACI ne prend en charge que GitHub Actions aujourd'hui ; d'autres systèmes de CI sont sur la roadmap.
• Votre firmware est généré par des outils à base de modèles, sans récupération de paquets. Un enregistreur de build apporte peu dans ce cas.
• Vous devez héberger des SBOM pour de nombreux OEM dans un portail de partage, ou signer des SBOM. CRACI ne propose ni l'un ni l'autre.
• Vos builds doivent tourner sur votre propre infrastructure. Les runners hébergés par le client sont sur la roadmap.
• Votre client veut une preuve de la gestion de la sécurité de votre organisation, comme un certificat ISO 27001 ou des réponses à un questionnaire NIS2. Une SBOM est une preuve pour une partie de cela, pas une certification. Le certificat ISO 27001 de CRACI couvre le service de CRACI, pas le vôtre.

Les SBOM pour les fournisseurs : questions fréquentes

Mon client, un OEM, m'a demandé une SBOM. Suis-je obligé d'en fournir une ?

Souvent, c'est le contrat qui l'exige plutôt que la loi. Si vous mettez vous-même sur le marché de l'UE un composant comportant des éléments numériques, le règlement sur la cyberrésilience exige votre propre SBOM. Sinon, l'obligation est celle de l'OEM, qui vous la répercute par la diligence raisonnable et l'accord de fourniture.

Le CRA s'applique-t-il aux composants que je vends à un fabricant ?

Si vous mettez le composant sur le marché de l'UE séparément, oui : l'article 3, point 1, inclut les composants logiciels ou matériels mis sur le marché séparément. S'il n'arrive sur le marché qu'à l'intérieur du produit de l'OEM, c'est l'OEM qui est le fabricant et il doit faire preuve de diligence raisonnable sur votre composant (article 13, paragraphe 5). Les composants des véhicules réceptionnés par type sont hors du champ du CRA (article 2, paragraphe 2, point c)).

UN R155 ou ISO/SAE 21434 exigent-ils une SBOM ?

Non. R155 ne mentionne jamais de SBOM ; il impose au constructeur du véhicule de gérer les risques liés aux fournisseurs. ISO/SAE 21434 organise le travail de cybersécurité avec les fournisseurs au moyen d'accords d'interface. Dans l'automobile, les SBOM arrivent comme une exigence contractuelle.

Quel format et quels champs un OEM attendra-t-il ?

En général CycloneDX ou SPDX en JSON ou XML, aligné sur les CISA 2026 Minimum Elements ou BSI TR-03183-2 : auteur et horodatage et, pour chaque composant, un nom, une version, un producteur, une package URL ou un CPE, une licence et un hash, avec les dépendances transitives.

À quelle fréquence dois-je envoyer une SBOM mise à jour ?

Pour chaque version logicielle que vous livrez, chaque fois que vous corrigez une erreur, et avec une déclaration VEX ou un avis de sécurité lorsque vous avez évalué une vulnérabilité. Convenez du déclencheur dans le contrat.

Partager une SBOM expose-t-il notre propriété intellectuelle ?

Non. Une SBOM liste des noms de composants, des versions, des producteurs, des licences, des hashes et des relations, pas le code source, les algorithmes ni les données de calibration. Partagez-la sous NDA ou dans le cadre de l'accord de fourniture, avec un usage limité à la gestion des vulnérabilités et à la conformité. Le CRA n'exige pas qu'elle soit publique.

Qu'est-ce que VEX, et mon client va-t-il en demander ?

VEX indique si un produit est touché par une vulnérabilité : not_affected, affected, fixed ou under_investigation, avec une justification pour not_affected. Attendez-vous à ce qu'on vous en demande un après la prochaine vulnérabilité largement médiatisée dans un composant que vous livrez.

Le firmware de notre ECU ne contient pas d'open source. À quoi ressemble notre SBOM ?

Courte et honnête : l'application propriétaire, le bootloader, les éventuelles bibliothèques ou calibrations d'un fournisseur de silicium, et l'éventuel open source comme une bibliothèque de cryptographie, chacun avec vos propres identifiants, plus les inconnues connues. Ne la gonflez pas.