Gestion des risques liés à la SBOM dans les dispositifs médicaux

Temps de lecture : 6 minutes

Les dispositifs médicaux modernes gagnent en complexité, et à mesure que la connectivité à Internet, au cloud et au monde extérieur augmente, le défi de sécurité augmente également. En outre, le nombre de dispositifs médicaux à usage domestique connaît une croissance exponentielle. Les appareils doivent donc résister à un environnement non clinique tout en communiquant sur des réseaux domestiques non sécurisés. Et avec les dispositifs médicaux, les risques de sécurité sont également des risques de sécurité, ce qui augmente les coûts de développement et la responsabilité.

Pour répondre aux problèmes de fonctionnalité, de coût et de délai de mise sur le marché, les dispositifs médicaux s'appuient sur des applications tierces et développées en interne. Bien que la FDA exige déjà une gestion des risques liés à la chaîne d'approvisionnement logicielle pour le développement de logiciels de dispositifs médicaux, la gestion des risques a souvent sous-estimé la vulnérabilité des composants tiers en raison du manque de technologie pour analyser et comprendre l'impact de ces logiciels. 

Pour surmonter ces obstacles, les développeurs de logiciels de dispositifs médicaux ont besoin de nouvelles approches, outils et techniques de développement !

Au sommaire de cet article :

• Que signifie SOUP ?
• Qu’en est-il des logiciels disponibles dans le commerce (OTS ou COTS) ?
• Gestion des risques dans SOUP
• Le rôle du SBOM
• Gestion des risques SOUP et OTS
• Une nouvelle approche de la gestion des risques de la chaîne d'approvisionnement logicielle

La norme IEC62304, qui définit un processus de développement de logiciels axé sur les risques et la qualité pour les logiciels de dispositifs médicaux, mentionne le terme « logiciel de pédigree/provenance inconnue ». SOUP fait référence à un logiciel largement inconnu en termes de processus de développement, de vérification et de validation, et peut ne pas être pris en charge par une entreprise ou une organisation.

Selon la norme IEC62304, « SOUP, logiciel de provenance inconnue, [est un] ÉLÉMENT LOGICIEL déjà développé et généralement disponible et qui n'a pas été développé dans le but d'être incorporé dans le DISPOSITIF MÉDICAL (également connu sous le nom de « hors-théâtre). "logiciel d'étagère") ou des logiciels précédemment développés pour lesquels des enregistrements adéquats des PROCESSUS de développement ne sont pas disponibles.

Il indique également, dans la section 7.1.2 (partie du processus de gestion des risques), « Le FABRICANT doit identifier les causes potentielles de l'ÉLÉMENT LOGICIEL identifié ci-dessus contribuant à une situation dangereuse… une panne ou des résultats inattendus de SOUP. »

De plus, dans la section B.1.2, Champ d'application, il est indiqué : « Il est supposé que grâce à une bonne exécution de la GESTION DES RISQUES DES DISPOSITIFS MÉDICAUX, le FABRICANT comprendrait le composant et reconnaîtrait qu'il inclut SOUP. » Un fabricant de dispositifs médicaux doit comprendre et gérer les risques liés à l’utilisation efficace de SOUP. Les tests unitaires rétroactifs sur des sources tierces sont difficiles, et pour les produits binaires, c'est presque impossible.

Il est important de noter que tous les OTS (Off the Shelf) ne sont pas des SOUP (“software of unknown provenance.”), bien que certains OTS puissent être des SOUPE. Les logiciels provenant de fournisseurs réputés spécialisés dans les logiciels critiques pour la sécurité, tels que GrammaTech, ne sont pas considérés comme SOUP. Des outils comme CodeSonar, par exemple, ne sont pas d'origine inconnue et sont conçus pour répondre aux normes critiques en matière de sécurité.

Tout produit disponible dans le commerce ou projet open source dépourvu de processus et de normes de développement documentés, sans historique de vérification ou de validation, présente un risque d'utilisation dans des logiciels de dispositifs médicaux critiques pour la sécurité.

La gestion des risques liés aux logiciels tiers et autres SOUP est déjà une activité requise pour l'approbation préalable à la commercialisation des dispositifs médicaux par la FDA. La sécurité est la principale préoccupation, mais elle devient tout aussi importante, les cyberattaques, entre autres menaces potentielles, mettant la sécurité en danger. Compte tenu du risque accru lié aux sources logicielles externes, il est essentiel de tirer parti des technologies développées pour analyser et corriger les vulnérabilités logicielles. L'analyse de la composition des logiciels peut désormais fournir un aperçu du code tiers, même sous forme binaire, ce qui facilite grandement la gestion des risques de la chaîne d'approvisionnement.

La sécurité est devenue une considération de plus en plus importante, et la FDA l'a abordé dans ses lignes directrices de 2014 sur le sujet . Étant donné que la conception, le codage et les tests de sécurité nécessitent un ensemble unique de compétences, ils échappent souvent à l’expertise des gestionnaires et développeurs de logiciels embarqués. De plus, lors de la gestion de code tiers, tel que des systèmes d'exploitation, des bibliothèques ou des logiciels open source, la sécurité est rarement une priorité. Il faut du temps et de l’argent pour évaluer ces sources logicielles externes. Les outils automatisés sont essentiels pour comprendre le risque et le gérer. De plus, il doit exister une méthode claire pour documenter, suivre et communiquer les risques de sécurité associés à SOUP.

Des outils tels que GrammaTech CodeSentry peuvent analyser SOUP et déterminer les composants constitutifs de l'open source et de l'OTS même lorsque le seul support disponible est des fichiers binaires. Ce faisant, il génère un rapport SBOM et de vulnérabilité qui détermine le risque que pose le composant SOUP. Les SBOM fournissent également :

Avec toutes les données dont vous disposez en utilisant une solution comme CodeSentry pour produire une SBOM, un score de sécurité, un rapport de vulnérabilité, des informations de licence, etc., il semble être une tâche ardue de savoir quoi en faire et comment gérer la découverte. de vulnérabilités critiques.

Comme pour la plupart des problèmes de sécurité, il est important d’évaluer les résultats en termes de probabilité et d’impact. La probabilité d'une vulnérabilité est une détermination de la possibilité qu'une attaque réussisse en utilisant la vulnérabilité découverte. L'impact est le dommage possible causé par une attaque réussie. Cet impact doit prendre en compte non seulement les dommages ou l'exposition immédiats, mais également l'impact à long terme sur votre marque, vos résultats et l'expérience client.

La prise de décision est plus subtile puisqu'il n'est souvent pas possible de simplement rejeter un logiciel essentiel au produit. Cela ajoute une autre dimension à la prise de décision et à l'approche adoptée avec l'éditeur de logiciels : Utilisation des SBOM dans le processus d'approvisionnement COTS.

De nouvelles approches en matière de développement de logiciels de dispositifs médicaux sont nécessaires si le développement actuel ne parvient pas à suivre le rythme des défis du marché. L’approche suivante peut contribuer à réduire les risques et la responsabilité liés aux logiciels tiers :

• Formation et adoption de nouvelles pratiques et lignes directrices en matière de développement de logiciels, de sûreté et de sécurité : le développement de logiciels évolue, tout comme les techniques et les méthodologies de développement de dispositifs critiques pour la sécurité et la sécurité. Un plan à long terme pour l’adoption de meilleures pratiques de développement incrémentiel et itératif, de gestion des risques et de sécurité est bénéfique, à la fois en termes de qualité des produits et de productivité du développement. L'inclusion d'un logiciel dans le cadre de la gestion de la chaîne d'approvisionnement est essentielle pour évaluer ce logiciel en termes de sûreté, de qualité et de sécurité.

• Combinez la gestion des risques avec l'analyse et l'évaluation des menaces de sécurité : comme pour le traitement approprié de la sécurité à toutes les étapes de développement, la sécurité doit faire partie d'un plan de gestion des risques liés aux dispositifs médicaux. La portée de cette évaluation doit inclure les OTS et SOUP de la chaîne d’approvisionnement. Un appareil non sécurisé n’est probablement pas un appareil sûr, et une analyse de sécurité peut négliger la sécurité.

• Gestion de la chaîne d'approvisionnement logicielle : La plupart des projets nécessitent une réutilisation ou une construction sur des produits open source ou commerciaux. Évaluer la qualité et la sécurité de SOUP et d'autres codes, internes ou externes à l'entreprise, peut réduire le risque.

• Intégrer l'automatisation des outils de développement et de test : les outils de développement logiciel progressent avec de nouvelles techniques et méthodologies. L'analyse de la composition des logiciels binaires, telle que celle fournie par GrammaTech CodeSentry, joue un rôle important dans l'automatisation de la vérification de l'open source, SOUP et OTS. Avec l'analyse statique avancée de CodeSonar, il fait partie d'une chaîne d'outils moderne qui est essentielle pour tirer parti de la sécurité, de la qualité et de la sûreté accrues qu'offrent les nouvelles techniques et approches.

• Intégrer les audits de sécurité et de sûreté dans CI/CD : Auditer les logiciels en cours de développement sur une base continue et garantir la qualité, la sécurité et la sûreté à toutes les étapes est essentiel au succès. L'automatisation permet de surveiller en permanence l'état de sécurité d'un produit en cours de développement lorsqu'il est intégré dans le cadre d'un pipeline d'intégration continue/de livraison continue. S'assurer que les produits répondent aux normes d'audit avant l'expédition illustre la diligence raisonnable et la gestion des risques requises pour l'approbation préalable à la commercialisation de la FDA. Lorsque cela est fait en continu, il n'y a pas de « surprises » en fin de cycle de développement.

Cette liste semble être un défi de taille à adopter à court terme ; heureusement, c'est une recommandation à long terme. Pour un exemple de ce qu’il faut faire maintenant, commencer par un audit de base de la chaîne d’approvisionnement est un excellent moyen de comprendre votre point de départ.

En Résumé
Le succès du développement logiciel dépend d’une prise de décision intelligente, y compris des décisions de création ou d’achat. L'introduction de code source et binaire externe, le SOUP, comporte des risques, et une bonne gestion des risques en termes de sûreté et de sécurité est nécessaire. Cependant, le risque de SOUP peut être géré grâce à une utilisation diligente et continue de l'analyse de la composition logicielle, de la génération et de la divulgation de SBOM, et à l'intégration des deux dans un pipeline de développement continu.