La FDA veut savoir : votre logiciel est-il toujours pris en charge ?
14 févr. 2026
Interlynk
Pourquoi le statut de support des composants est la partie la plus difficile des SBOMs des dispositifs médicaux
Si vous êtes un fabricant de dispositifs médicaux préparant une soumission de cybersécurité avant mise sur le marché, vous avez probablement entendu que la FDA exige désormais un Bill of Materials (SBOM). Ce que vous ne réalisez peut-être pas, c'est que le SBOM lui-même n'est que le début. Depuis octobre 2023, la FDA applique activement des exigences qui vont bien au-delà de la simple liste des composants logiciels de votre dispositif. Ils veulent savoir si ces composants sont toujours pris en charge.
Cet article explique ce que la FDA exige réellement en matière de statut de support des composants, pourquoi il est étonnamment difficile de bien le faire, et quelles approches pratiques existent aujourd'hui.
Que veut exactement la FDA ?
Pour chaque composant de votre SBOM — qu'il s'agisse d'une bibliothèque commerciale, d'un package open-source ou d'un logiciel standard — la FDA s'attend à recevoir deux informations spécifiques :
1. Niveau de support
Ce composant est-il activement maintenu ? Le mainteneur a-t-il cessé de travailler dessus ? A-t-il été complètement abandonné ? La FDA s'en soucie car un composant non pris en charge est une horloge qui tourne. Lorsqu'une vulnérabilité est découverte dans une bibliothèque que personne ne corrige, votre appareil hérite de ce risque sans chemin clair pour la remédiation.
La FDA reconnaît généralement ces catégories :
Activement maintenu — Quelqu'un surveille le code, émet des mises à jour et corrige les problèmes de sécurité.
Plus maintenu — Le composant existait dans un état maintenu à un moment donné, mais le mainteneur est passé à autre chose. Aucune nouvelle mise à jour de sécurité n'est prévue.
Abandonné — Le projet a été explicitement déprécié, archivé ou laissé sans aucune activité de mainteneur pendant une période prolongée.
2. Date de fin de support / de fin de vie (EOS/EOL)
C'est la date à laquelle le support pour le composant prendra fin — ou a déjà pris fin. Pour les composants propriétaires, cela peut provenir d'un contrat de support avec un vendeur. Pour les composants open-source, cela devient compliqué (plus d'infos à ce sujet sous peu).
Si vous ne pouvez pas fournir d'informations de support pour un composant particulier, la FDA s'attend à une justification écrite expliquant pourquoi. "Nous ne savions pas" n'est pas une réponse acceptable.
Ces informations sont soumises avec les évaluations de vulnérabilité et les plans de remédiation dans le cadre du rapport global sur les risques liés à la cybersécurité. Les soumissions qui manquent de données adéquates sur le SBOM et le support des composants peuvent être refusées — la FDA l'a clairement indiqué.
Pourquoi est-ce si difficile ?
Sur le papier, cela semble simple : recherchez chaque composant, vérifiez s'il est pris en charge, notez la date. En pratique, cela s'avère beaucoup plus difficile que cela n'en a l'air. Voici pourquoi.
Le fossé du format SBOM
Les deux standards SBOM dominants — SPDX et CycloneDX — n'ont pas été conçus en tenant compte des exigences de statut de soutien de la FDA.
SPDX (maintenu par la Linux Foundation) n'a pas de champs natifs pour le niveau de soutien des composants ou les dates de fin de soutien. Il n'y a tout simplement aucun endroit dans le schéma standard SPDX pour exprimer "ce composant n'est plus maintenu" ou "le soutien se termine le 30-06-2025." Vous pouvez utiliser le mécanisme d'annotation de SPDX ou des références de documents externes, mais ce sont des solutions de contournement — pas des champs structurés et lisibles par machine que les outils peuvent consommer de manière cohérente.
CycloneDX est légèrement mieux positionné. Il prend en charge un mécanisme d'extension properties flexible où vous pouvez attacher des paires clé-valeur arbitraires aux composants. C'est ainsi que des plateformes comme Interlynk gèrent le statut de soutien aujourd'hui — en écrivant des propriétés personnalisées comme :
Mais voici le hic : ce sont des extensions spécifiques aux fournisseurs, pas partie de la spécification CycloneDXcore. Un autre outil lisant ce SBOM n'aurait aucune idée de ce que signifie interlynk:component:support_level à moins qu'il ne soit spécifiquement conçu pour le comprendre. Il n'existe pas de méthode universelle et normalisée pour exprimer le statut de soutien dans les deux formats.
Cela signifie que les organisations ont souvent recours à l'exportation des données de soutien sous forme de fichier CSV séparé aux côtés du SBOM, créant une image fragmentée qui nécessite une réconciliation manuelle. C'est fonctionnel, mais c'est fragile.
Le problème de l'inférence open-source
Pour les logiciels commerciaux, déterminer le statut de soutien est relativement simple. Vous avez un fournisseur. Vous avez un contrat de soutien. Le contrat a une date d'expiration. Fait.
Le logiciel open-source est un monde complètement différent.
La plupart des projets open-source ne publient pas de chronologies de soutien formelles. Il n'y a pas de page "Fin de soutien" pour les milliers de dépendances transitives dans un projet logiciel typique. La FDA reconnaît ce défi, mais s'attend toujours à ce que les fabricants fournissent l'information — ou justifient pourquoi ils ne peuvent pas.
Alors, comment déterminez-vous le statut de soutien d'un composant open-source ? Vous en déduisez le statut. Et la déduction nécessite des données provenant de plusieurs sources :
Activité du registre de paquets — Quand la dernière version a-t-elle été publiée sur npm, PyPI, Maven Central, RubyGems ou quel que soit le registre où se trouve le package ? Si la dernière version a été publiée dans l'année écoulée, c'est un signal fort d'une maintenance active. Si rien n'a été publié depuis trois ans, c'est un signal d'alerte.
Activité du dépôt source — Quand le dernier commit a-t-il été effectué dans le dépôt GitHub, GitLab ou Bitbucket du projet ? Le dépôt est-il archivé ? A-t-il été explicitement marqué comme obsolète ?
Bases de données EOL connues — Des projets comme endoflife.date (xeol.io) maintiennent des données structurées sur les dates de fin de vie pour des produits logiciels bien connus. Ceux-ci couvrent les principaux frameworks, langages et systèmes d'exploitation — mais ils ne représentent qu'une fraction de l'écosystème total.
Drapeaux de dépréciation des packages — Certains registres prennent en charge des marqueurs de dépréciation explicites. npm permet aux mainteneurs de déprécier des packages. Les packages PyPI peuvent être retirés. Mais l'adoption de ces mécanismes varie d'un écosystème à l'autre.
Le problème est qu'aucune source unique ne vous donne l'image complète. Un package peut ne montrer aucune nouvelle publication dans le registre depuis deux ans — mais le mainteneur s'engage activement, il n'a tout simplement pas publié de version. Ou un dépôt peut montrer une activité récente, mais ce sont tous des mises à jour de dépendances automatisées — pas une maintenance significative.
Déterminer le statut de soutien nécessite de corréler des signaux provenant de plusieurs sources et d'appliquer un jugement. C'est un travail de détective, pas une recherche dans une base de données.
L'échelle des écosystèmes
Un dispositif médical moderne n'utilise pas juste quelques bibliothèques. Une pile classique de firmware ou d'application pourrait utiliser des centaines, voire des milliers de dépendances à travers JavaScript, Python, Java, .NET, Rust, Go, C/C++, et plus — chacune avec des millions de packages disponibles et chacune avec des conventions différentes sur la manière dont l'information sur le cycle de vie est communiquée.
Certaines écosystèmes permettent aux mainteneurs de déprécier explicitement un package. D'autres n'ont aucun mécanisme de dépréciation du tout. Les bibliothèques C et C++ n'ont souvent aucune présence dans un gestionnaire de paquets — elles sont téléchargées sous forme d'archives source ou compilées directement dans la construction. Il n'existe pas d'API universelle que vous pouvez appeler pour demander "ce composant est-il toujours pris en charge ?" à travers tous.
Cela signifie que fournir un statut de soutien cohérent à travers votre SBOM nécessite des connaissances spécifiques à l'écosystème et des pipelines de données — un défi d'infrastructure significatif.
Le problème de l'embedded et des constructions personnalisées
Les dispositifs médicaux fonctionnent fréquemment sur des constructions Linux personnalisées créées avec des systèmes de construction comme Buildroot ou Yocto/OpenEmbedded. Contrairement aux logiciels classiques qui installent des packages préconstruits, ces systèmes compilent un système d'exploitation entier — noyau, bibliothèques système, utilitaires — à partir du code source.
Cela ajoute des couches de complexité au statut de soutien :
La question de la branche amont par rapport à celle du fournisseur — Dans les systèmes embarqués, le statut de soutien dépend souvent non seulement du projet amont, mais aussi des forks modifiés par le fournisseur et des contrats à long terme. Un dispositif pourrait utiliser le noyau Linux 5.15, qui a une date de fin de vie amont connue — mais la version réellement en cours d'exécution sur l'appareil est un fork corrigé par le fournisseur. Que ce fork soit maintenu dépend du fournisseur, pas du projet open-source.
Des centaines de composants en dehors des registres traditionnels — Les systèmes de construction embarqués tirent le code source de centaines de packages (OpenSSL, busybox, systemd, etc.) et les compilent pour le matériel cible. Beaucoup de ceux-ci n'existent pas dans des registres de packages comme npm ou PyPI, donc les vérifications automatisées habituelles ne s'appliquent tout simplement pas. Chacun doit être retracé manuellement jusqu'à son projet amont.
Composants de matériel propriétaire — Les packages de support de carte de fournisseurs de puces (NXP, TI, Qualcomm, etc.) incluent des pilotes et du firmware propriétaires avec des cycles de vie de soutien liés à la feuille de route produit du fournisseur. La seule façon de connaître la date de fin de vie est de vérifier votre accord avec le fournisseur.
Pour ces scénarios embarqués, déterminer le statut de soutien est souvent un exercice de recherche manuelle — et l'une des parties les plus chronophages d'une soumission à la FDA.
Un cadre pratique pour bien y parvenir
Étant donné toute cette complexité, que devrait réellement faire un fabricant de dispositifs médicaux ? Voici une approche par couches qui part des bases automatisées jusqu'au contrôle humain.
Couche 1 : Tirer parti des bases de données EOL connues
Commencez par ce qui est déjà documenté. Des bases de données comme endoflife.date fournissent des données EOL/EOS structurées pour des centaines de produits bien connus — langages de programmation, frameworks, systèmes d'exploitation, bases de données, et plus encore. Cela ne couvrira pas l'ensemble de votre SBOM, mais cela gérera les "grosses pierres" — les composants majeurs qui représentent le plus de risques.
Pour les composants avec des dates EOL connues, la cartographie est simple : si EOL est passé, le composant n'est plus maintenu. Si EOS est passé, le support a pris fin. Si le produit est obsolète, considérez-le comme abandonné.
Couche 2 : Automatiser l'inférence des métadonnées de paquets et de dépôts
Pour la longue traîne des composants open-source sans données EOL formelles, mettez en place des vérifications automatisées :
Fraîcheur des paquets : Interrogez le registre de paquets pertinent. Si la dernière version a été publiée dans un délai configurable (généralement 365 jours), classifiez-la comme activement maintenue.
Activité du dépôt : Vérifiez la date du dernier engagement du dépôt source. Si les engagements sont récents, c'est un signal positif.
Drapeaux de dépréciation : Vérifiez si le paquet ou le dépôt a été explicitement déprécié ou archivé.
Combinez ces signaux avec des défauts sensés : si le registre et le dépôt ne montrent aucune activité au-delà de votre seuil, classez comme n'étant plus maintenu. Si le dépôt est archivé ou si le paquet est déprécié, classez comme abandonné.
Cette approche automatisée ne sera pas parfaite — certains projets actifs publient simplement peu fréquemment — mais elle fournit une base défendable qui couvre l'essentiel de votre SBOM.
Couche 3 : Surcharges manuelles avec trails d'audit
L'automatisation vous amènera à 70-80 % du chemin. Le reste nécessite un jugement humain. Votre équipe doit avoir la capacité de :
Surcharger les classifications automatisées — Un ingénieur en sécurité pourrait savoir qu'un projet apparemment inactif est en réalité maintenu par une équipe interne ou un fournisseur commercial sous contrat.
Définir des dates EOL explicites — Pour les composants propriétaires ou les bibliothèques soutenues par des fournisseurs, entrez manuellement la date d'expiration du contrat.
Documenter les justifications — Lorsque l'état de support ne peut vraiment pas être déterminé, enregistrez pourquoi. "Le composant XYZ est une bibliothèque C fournie par un fournisseur sans présence de dépôt ou de registre public. L'auteur original ne répond pas. Nous l'avons classifié comme non spécifié et inclus dans notre évaluation des risques" est une justification légitime.
Ces surcharges devraient être suivies avec des trails d'audit complets — qui a changé quoi, quand et pourquoi — car la FDA peut le demander.
Un exemple du monde réel : le problème OpenSSL
Considérez un dispositif médical qui utilise OpenSSL 1.1.1 — l'une des bibliothèques cryptographiques les plus largement déployées au monde. En amont, OpenSSL 1.1.1 a atteint sa fin de vie officielle le 11 septembre 2023. Un système automatisé signalerait correctement cela et classifierait le composant comme "Plus Maintenu". Cas clos ?
Pas nécessairement. Si le dispositif fonctionne sous Ubuntu 20.04 LTS, Canonical rétroporte les corrections de sécurité pour OpenSSL 1.1.1 dans le cadre de son engagement de soutien à long terme. Le projet en amont est en fin de vie, mais le build spécifique utilisé par votre dispositif est toujours en train de recevoir des correctifs de la part de votre fournisseur de distribution.
C'est une distinction que l'automatisation ne peut pas faire à elle seule. La couche automatisée signale le risque. La surcharge manuelle saisit la nuance :
> "OpenSSL 1.1.1 en amont est EOL, mais notre dispositif utilise le build maintenu par Ubuntu 20.04 LTS. Canonical fournit des correctifs de sécurité dans le cadre de notre contrat de soutien jusqu'en avril 2025. Date EOL définie sur l'expiration du contrat."
Cette surcharge — documentée avec une justification et liée à un contrat de soutien spécifique — est exactement le genre de preuve que la FDA attend.
Maintenant, multipliez cela à travers chaque composant d'un dispositif complexe, et le besoin d'un système de surcharge structuré avec des trails d'audit devient évident.
Couche 4 : Politiques organisationnelles
Différentes organisations peuvent avoir besoin de seuils et de règles différents. Un composant qui a été inactif pendant six mois pourrait être acceptable dans un contexte mais préoccupant dans un autre. Les organisations devraient être capables de :
Configurer les seuils d'activité utilisés pour la classification automatique
Définir des surcharges organisationnelles pour les composants qu'elles ont vérifiés indépendamment
Définir des politiques qui signalent les composants avec certains statuts de support pour révision
Couche 5 : Surveillance continue
L'état de soutien n'est pas une évaluation ponctuelle. Un composant qui était activement maintenu lorsque vous avez soumis votre demande de mise sur le marché pourrait devenir abandonné six mois plus tard. La surveillance continue — le recalcul de l'état de soutien à un rythme régulier et l'alerte lorsque les composants passent à des états préoccupants — est essentielle pour maintenir votre posture de risque en cybersécurité tout au long du cycle de vie du dispositif.
Couche 6 : Personnes et processus
La technologie et les données ne sont qu'une partie de l'équation. L'un des défis les plus sous-estimés est celui organisationnel : qui est réellement responsable de ce travail ?
Dans la plupart des entreprises de dispositifs médicaux, la réponse n'est pas claire — et c'est le problème.
Développement construit le logiciel et choisit les composants — mais passe à la prochaine version. Suivre l'état de cycle de vie à travers des centaines de dépendances ne fait pas partie de leur flux de travail quotidien.
Sécurité comprend le risque des composants non pris en charge — mais manque souvent le contexte de pourquoi une version spécifique a été choisie ou si un fork interne est maintenu.
Réglementaire possède la soumission à la FDA — mais dépend entièrement de l'ingénierie pour fournir les données. Ils ne peuvent pas déterminer si busybox 1.35.0 dans une build Yocto reçoit toujours des correctifs.
Produit/Achats gère les contrats des fournisseurs qui déterminent les dates EOL — mais peut ne pas relier le renouvellement d'un contrat au profil de risque en cybersécurité d'un dispositif déjà sur le marché.
Personne n'a une vision complète. L'ingénieur firmware sait que le fork du noyau est maintenu. Les achats savent que le contrat de support BSP expire l'année prochaine. Le bureau du programme open-source suit la santé de la communauté pour les dépendances clés.
Les organisations qui gèrent cela efficacement établissent une responsabilité claire et transversale — définissant qui examine les classifications des états de soutien, qui surveille les changements, et qui met à jour les dossiers lors du renouvellement d'un contrat fournisseur ou du remplacement d'un composant. Sans cette clarté de processus, même les meilleurs outils produisent des résultats incomplets. Les données les plus difficiles à capturer sont les connaissances institutionnelles qui vivent dans la tête des gens, pas dans les registres de paquets.
Ce qui doit changer
L'état actuel des affaires est viable, mais loin d'être idéal. Plusieurs choses pourraient aider :
Les normes SBOM ont besoin de champs d'état de support natifs. Tanto SPDX que CycloneDX devraient inclure des champs standardisés et lisibles par machine pour le niveau de support et les dates EOL/EOS. Les propriétés spécifiques aux fournisseurs et les canaux latéraux CSV ne sont pas durables. Les exigences de la FDA sont claires : les normes devraient les refléter.
Les registres de packages ont besoin de meilleures métadonnées sur le cycle de vie. Si npm, PyPI et Maven Central exposaient des informations structurées sur les dates EOL et le statut de support aux côtés des données de version, tout l'écosystème en bénéficierait. Certains registres avancent dans cette direction, mais l'adoption est inégale.
L'écosystème intégré a besoin de meilleurs outils. Buildroot et Yocto génèrent des manifestes détaillés de ce qu'ils construisent, mais le mapping de ces manifestes au statut de support en amont est largement un processus manuel. Une meilleure intégration entre les systèmes de construction embarqués et les outils SBOM/statut de support réduirait considérablement le fardeau des fabricants d'appareils.
Collaboration de l'industrie sur les données EOL — et OpenEoX ouvre la voie. Des projets communautaires comme endoflife.date ont commencé à cataloguer les dates EOL pour des produits populaires, mais ce qui manque, c'est une norme soutenue par l'industrie pour la structuration et l'échange des données de cycle de vie. C'est exactement ce que OpenEoX vise à fournir.
Lancé en décembre 2023 en tant que Comité technique OASIS, OpenEoX est soutenu par Cisco, Dell, Microsoft, Red Hat, Qualys, et d'autres — avec la contribution de CISA également. La norme définit des phases de cycle de vie claires qui correspondent directement à ce que demande la FDA :
Fin des ventes — le fournisseur cesse d'accepter de nouvelles commandes
Fin du support de sécurité — les mises à jour de sécurité cessent d'être publiées (la critique pour les dispositifs médicaux)
Fin de vie — retrait complet, aucun soutien supplémentaire de quelque type que ce soit
L'idée clé derrière OpenEoX est qu'elle ne remplace pas les normes existantes — elle comble le fossé entre elles. Votre SBOM vous dit ce qu'il y a dans votre appareil. VEX et CSAF vous disent quelles vulnérabilités s'appliquent. OpenEoX ajoute le morceau manquant : combien de temps chaque composant sera supporté.
La spécification est encore en développement actif (la v1.0 est en cours), mais la direction est claire et le soutien de l'industrie est substantiel. Pour les fabricants de dispositifs médicaux, OpenEoX mérite d'être surveillé de près. Cela ne résoudra pas l'échéance de soumission d'aujourd'hui, mais cela représente la direction que prend l'industrie — vers un format universel et lisible par machine pour les données de cycle de vie que tout outil peut produire et consommer.
Le résultat final
Les exigences de statut de soutien de la FDA existent pour une bonne raison : les logiciels non pris en charge dans les dispositifs médicaux posent un problème de sécurité pour les patients. Mais satisfaire à ces exigences est vraiment difficile — non pas parce que les fabricants ne sont pas prêts, mais parce que l'infrastructure de données n'existe pas encore complètement.
Le chemin à suivre implique une combinaison d'inférence automatisée, de bases de données soigneusement sélectionnées, de surveillance manuelle et — de manière critique — de meilleurs outils.
Chez Interlynk, nous avons construit une infrastructure spécifiquement pour combler cette lacune — en combinant l'inférence de niveau de soutien automatisé à travers les registres de packages et les dépôts de code source, des bases de données EOL soigneusement sélectionnées, des flux de travail de contournement manuel avec des contrôles d'expiration, et des pistes de vérification complètes conçues pour l'examen de la FDA. Chaque couche du cadre décrit dans cet article reflète des défis réels que nous avons résolus pour les fabricants de dispositifs médicaux naviguant dans les soumissions pré-commercialisation.
Si vous avez des difficultés avec les données de statut de soutien, vous n'êtes pas seul. Le défi est réel — mais il est solvable, et les outils se développent rapidement.
Interlynk fournit des outils de gestion SBOM et de sécurité de la chaîne d'approvisionnement logicielle conçus spécifiquement pour les industries régulées. Pour en savoir plus sur la façon dont nous traitons les exigences de statut de soutien de la FDA, visitez interlynk.io.