Le SBOM est longtemps resté une bonne pratique d’ingénierie que peu d’équipes formalisaient. Ce temps est révolu. Aux États-Unis, c’est une obligation légale : la FDA l’exige depuis 2023 dans toute soumission de « cyber device ». En Europe, la guidance MDCG 2019-16 sur la cybersécurité des dispositifs médicaux le cite parmi les informations à fournir aux utilisateurs. Le Cyber Resilience Act, lui, impose le SBOM aux produits numériques, mais exclut explicitement ceux qui relèvent du MDR. Pour une équipe qui développe du logiciel médical, la question n’est plus « faut-il un SBOM ? » mais « le mien tiendra-t-il devant un régulateur ? ».
Qu’est-ce qu’un SBOM, au juste ?
Définition : un SBOM (Software Bill of Materials) est un inventaire formel et lisible par machine de tous les composants logiciels — commerciaux, open source, sur étagère — qui composent un produit, avec leurs relations de dépendance. C’est la nomenclature de votre logiciel, l’équivalent d’une liste de pièces détachées pour la chaîne d’approvisionnement logicielle.
La NTIA structure le sujet en trois volets indissociables : les champs de données (ce que chaque composant doit documenter), le support de l’automatisation (génération et lecture par machine, pour passer à l’échelle) et les pratiques et processus (comment le SBOM est demandé, produit et utilisé). Un fichier PDF listant des dépendances n’est pas un SBOM : l’exigence est un format structuré, exploitable par des outils.
Que doit contenir un SBOM conforme ?
La NTIA définit sept champs de données minimaux pour chaque composant :
- le nom du fournisseur (Supplier Name) ;
- le nom du composant (Component Name) ;
- sa version ;
- d’autres identifiants uniques (Other Unique Identifiers) ;
- la relation de dépendance (Dependency Relationship) ;
- l’auteur du SBOM (SBOM Author) ;
- l’horodatage (Timestamp).
Pour un dispositif médical, la guidance premarket de la FDA attend en plus, pour chaque composant : l’actif où réside le composant, le niveau de support assuré par son fabricant, sa date de fin de support, et ses vulnérabilités connues. Ces trois derniers points sont décisifs : ils transforment le SBOM d’un simple inventaire en outil de gestion du risque sur tout le cycle de vie.
Que disent les textes ?
Trois textes de natures différentes, et un seul s’applique directement au logiciel de votre dispositif côté européen :
| États-Unis | UE, dispositif médical | UE, produit hors MDR | |
|---|---|---|---|
| Texte | FD&C Act, section 524B | MDR, annexe I (17.2, 23.4 ab) et guidance MDCG 2019-16 rev. 1 | Cyber Resilience Act, règlement (UE) 2024/2847 |
| Statut du SBOM | Exigence légale de recevabilité premarket | Pas nommé par le MDR ; cité par la MDCG 2019-16 parmi les informations à fournir aux utilisateurs | Élément obligatoire de la documentation technique |
| Depuis / échéance | En vigueur depuis le 29 mars 2023 | MDR applicable depuis le 26 mai 2021 | Entré en vigueur le 10 déc. 2024 ; obligations principales au 11 déc. 2027 |
| Portée | Composants commerciaux, open source et sur étagère | Non précisée | Au minimum les dépendances de premier niveau |
| Diffusion | Dans la soumission à la FDA | Information destinée aux utilisateurs du dispositif | Dans la doc technique, fournie aux autorités de surveillance sur demande |
Le point qui piège souvent : le CRA ne s’applique pas au logiciel d’un dispositif médical. Son article 2, paragraphe 2, exclut les produits relevant du règlement (UE) 2017/745 (MDR) et du 2017/746 (IVDR), qui traitent déjà leur cybersécurité. Il vous concerne en revanche pour vos autres produits numériques mis sur le marché européen, s’ils ne sont pas des dispositifs. Pour le dispositif lui-même, le SBOM se justifie par l’état de l’art en sécurité de l’information exigé par l’annexe I du MDR (17.2), dont l’IEC 81001-5-1:2021 est la référence.
Un SBOM n’est pas un livrable de conformité de plus : c’est le même artefact technique qui alimente à la fois votre dossier FDA, votre documentation MDR et votre gestion des SOUP au sens 62304. Construisez-le une fois, déclinez-le partout.
Quel format : CycloneDX ou SPDX ?
Deux standards se partagent le terrain :
- CycloneDX — porté par l’OWASP, standardisé ECMA-424, conçu avec une orientation sécurité (vulnérabilités, VEX).
- SPDX — porté par la Linux Foundation, publié comme ISO/IEC 5962:2021, né de la conformité des licences open source.
Aucun texte n’impose l’un plutôt que l’autre : la FDA demande un format lisible par machine, et le CRA, pour les produits qu’il couvre, un format couramment utilisé et lisible par machine. CycloneDX et SPDX répondent tous deux à ce critère. En pratique, beaucoup d’équipes génèrent les deux, car outils, clients et autorités penchent différemment.
Comment le générer et le maintenir ?
Le SBOM ne se rédige pas à la main : il se génère depuis vos sources de vérité.
- Générer depuis les lockfiles (
package-lock.json,poetry.lock,go.sum…) avec des outils comme Syft, Trivy ou le plugin CycloneDX de votre écosystème — incluez les dépendances transitives, les images de base et les runtimes. - Régénérer à chaque release, automatiquement, dans la CI. Un SBOM figé le jour de l’audit est faux dès la version suivante.
- Le brancher au reste de la conformité : chaque composant tiers est un SOUP au sens IEC 62304 — le SBOM en est l’inventaire ; et c’est le pivot de la gestion des vulnérabilités post-market, puisqu’il permet d’identifier en minutes les dispositifs affectés quand une CVE est publiée.
C’est ce dernier point qui donne sa vraie valeur au SBOM : non pas cocher une case réglementaire, mais savoir instantanément ce que contient votre produit le jour où une vulnérabilité critique sort. La suite — scan continu, triage et décisions tracées — est couverte dans Du SBOM au VEX : gérer les vulnérabilités sans noyer l’équipe.
FAQ
01Faut-il rendre le SBOM public ?
Non. Côté FDA, il est joint à la soumission premarket. Côté MDR, la guidance MDCG 2019-16 le range parmi les informations destinées aux utilisateurs du dispositif, ce qui n’impose pas de le publier. Pour un produit hors MDR soumis au CRA, il fait partie de la documentation technique, fournie aux autorités de surveillance du marché sur demande. La transparence exigée est réglementaire, pas publique.
02Doit-il inclure les dépendances transitives ?
Pour les produits qu’il couvre, le minimum légal du CRA porte sur les dépendances de premier niveau, mais la pratique attendue — et ce que produisent les outils — couvre le graphe complet, dépendances transitives incluses. Pour la gestion des vulnérabilités, une profondeur partielle est un angle mort : une CVE se cache souvent dans une dépendance de dépendance.
03Un SBOM suffit-il à prouver ma conformité cybersécurité ?
Non. C’est une pièce nécessaire mais non suffisante. Il s’intègre à un dossier cyber plus large — plan de gestion des vulnérabilités, threat model, tests de sécurité. Un SBOM sans processus de veille et de triage derrière lui n’est qu’une liste.
Références & normes citées
- [01] FD&C Act, section 524B — Ensuring Cybersecurity of Devices (FDA Digital Health Center of Excellence)
- [02] FDA Guidance — Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (2023)
- [03] NTIA — The Minimum Elements For a Software Bill of Materials (SBOM) (12 juillet 2021)
- [04] Règlement (UE) 2024/2847 — Cyber Resilience Act (produits comportant des éléments numériques)
- [05] IEC 81001-5-1:2021 — Health software — Security — Activities in the product life cycle
- [06] ISO/IEC 5962:2021 — SPDX (Software Bill of Materials format)
- [07] IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes
