SBOM d'un dispositif médical : l'obligation légale (FDA §524B, CRA) et comment la tenir

Le SBOM est longtemps resté une bonne pratique d’ingénierie que peu d’équipes formalisaient. Ce temps est révolu : des deux côtés de l’Atlantique, il est devenu une obligation légale. La FDA l’exige depuis 2023 dans toute soumission de « cyber device », l’Union européenne l’impose via le Cyber Resilience Act, et l’IEC 81001-5-1 en fait un attendu du marquage CE. 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 :

1. le nom du fournisseur (Supplier Name) ;
2. le nom du composant (Component Name) ;
3. sa version ;
4. d’autres identifiants uniques (Other Unique Identifiers) ;
5. la relation de dépendance (Dependency Relationship) ;
6. l’auteur du SBOM (SBOM Author) ;
7. 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.

Pourquoi est-il devenu une obligation légale ?

Trois textes convergent, avec des natures et des échéances différentes :

À cela s’ajoute la voie MDR : l’IEC 81001-5-1:2021 — la norme d’état de l’art pour la cybersécurité sous le MDR — attend déjà un SBOM dans la gestion des releases sécurisées, et la guidance MDCG 2019-16 la cite comme moyen de conformité. Autrement dit, même avant l’application pleine du CRA, un organisme notifié vous demandera votre SBOM.

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 doc technique CRA 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 régulateur n’impose l’un plutôt que l’autre : la FDA, le CRA et l’IEC 81001-5-1 exigent 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.

FAQ

Faut-il rendre le SBOM public ?

Non. Sous le CRA, il fait partie de la documentation technique et n’est fourni qu’aux autorités de surveillance du marché, sur demande — il n’a pas à être publié. Côté FDA, il est joint à la soumission premarket. La transparence exigée est réglementaire, pas publique.

Doit-il inclure les dépendances transitives ?

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.

Un 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.