Gestion des risques liés à la chaîne d'approvisionnement des logiciels dans le domaine des dispositifs médicaux

Temps de lecture : 7 minutes

Les dispositifs médicaux modernes gagnent en complexité, et à mesure qu'ils se connectent davantage à internet, au cloud et au monde extérieur, les défis en matière de sécurité augmentent. De plus, l'utilisation croissante des dispositifs médicaux à domicile signifie qu'ils doivent fonctionner dans des environnements non cliniques et communiquer sur des réseaux domestiques non sécurisés. Les risques de sécurité étant aussi des risques de sûreté, cela augmente les coûts de développement et la responsabilité des fabricants.

Pour répondre aux exigences de fonctionnalité, de coût et de délai de mise sur le marché, les dispositifs médicaux dépendent d'applications tierces et internes. Bien que la FDA exige déjà la gestion des risques de la chaîne d'approvisionnement logicielle, les vulnérabilités des composants tiers sont souvent sous-estimées en raison d'un manque de technologies pour analyser et comprendre leur impact. Les développeurs de logiciels pour dispositifs médicaux ont donc besoin de nouvelles approches, outils et techniques de développement.

La norme ISO/IEC 62304, qui définit un processus de développement logiciel axé sur les risques et la qualité pour les dispositifs médicaux, utilise le terme « SOUP » pour désigner le « Software of Unknown Provenance » (logiciel d'origine inconnue). Le SOUP se réfère à un logiciel dont les processus de développement, vérification et validation sont largement inconnus et peuvent ne pas être pris en charge par une entreprise ou une organisation.

Selon la norme IEC62304, le SOUP est un élément logiciel déjà développé, généralement disponible, mais qui n'a pas été créé spécifiquement pour être intégré dans un dispositif médical. Il peut aussi s'agir d'un logiciel pour lequel les dossiers de développement ne sont pas disponibles.

Tous les logiciels prêts à l'emploi (OTS) ne sont pas des SOUP, bien que certains puissent l'être. Les logiciels provenant de fournisseurs spécialisés en sécurité critique, comme CodeSecure, ne sont pas considérés comme des SOUP. Les outils comme CodeSonar, qui répondent aux normes de sécurité, ne relèvent pas d'une provenance inconnue.

Les produits prêts à l'emploi ou projets open source sans processus et normes de développement documentés posent un risque pour les logiciels de dispositifs médicaux critiques.

Avec toutes les données dont vous disposez grâce à l’utilisation d’une solution comme CodeSentry pour produire un SBOM, un score de sécurité, un rapport de vulnérabilité, des informations de licence, etc., il semble être une tâche ardue de déterminer 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.

Une bonne façon d'évaluer les vulnérabilités critiques open source trouvées dans les logiciels COTS est d'utiliser le quadrant de risque illustré ci-dessous. Par exemple, un logiciel présentant certaines vulnérabilités, dont l'exploitation est peu probable avec un faible impact, pourrait être approuvé pour un achat, un renouvellement ou un contrat de maintenance en acceptant simplement le niveau de risque faible. De toute évidence, les logiciels présentant un impact élevé et une forte probabilité de vulnérabilités d'attaque peuvent devoir être rejetés (plus d'informations à ce sujet ci-dessous).

Des outils tels que CodeSecure 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 :

• Il est primordial d’identifier et d’éviter les vulnérabilités dans les composants réutilisés dans vos propres logiciels développés et dans les logiciels achetés par votre organisation.
• Gérer les risques de la chaîne d'approvisionnement logicielle afin d'éliminer et de réduire les risques de sécurité inconnus dans les logiciels réutilisés.  Les SBOM fournissent des données pour les décisions commerciales concernant les achats de logiciels et la réutilisation de l'open source.
• Qualification de la chaîne d’approvisionnement pour garantir la cohérence et la responsabilité des fournisseurs. Les fournisseurs qui répondent aux exigences du SBOM lors de l’approvisionnement bénéficient d’un traitement préférentiel.
• Une sécurité améliorée et des avantages en aval qui accompagnent la gestion et l'atténuation des risques. Éviter et détecter les risques de sécurité avant qu'ils ne soient intégrés dans vos produits rapporte énormément lors du développement et du déploiement de vos produits.
• Compréhension commune des actifs logiciels fournie avec un SBOM standardisé parmi les développeurs de logiciels, les fournisseurs et les projets open source. Les SBOM sont devenus un moyen de communiquer le contenu et les dépendances des logiciels au sein et à l'extérieur d'une organisation.

Pour réduire les risques liés aux logiciels tiers, les développeurs de dispositifs médicaux doivent adopter des pratiques de développement et de sécurité nouvelles, combiner la gestion des risques avec l'analyse des menaces, intégrer des outils d'automatisation de test, et inclure des audits de sécurité dans les processus CI/CD.

Résumé
Le succès du développement logiciel repose sur une gestion prudente des risques de sécurité et de sûreté associés aux logiciels tiers. Ces risques peuvent être gérés grâce à l'utilisation continue de l'analyse de la composition logicielle, la génération de SBOM et leur intégration dans un pipeline de développement continu.