> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/fr/helm/get-started-with-helm/dont-have-an-sbom/why-sboms-are-critical-to-your-present-and-future.md).
# Pourquoi les SBOM sont essentiels aujourd’hui et pour l’avenir
En disposant d’un SBOM qui reflète l’état actuel de votre produit, vous disposez désormais d’un catalogue de toutes ses « listes d’ingrédients », ce qui améliore la visibilité et la transparence de votre chaîne d’approvisionnement logicielle et garantit que vos logiciels sont régulièrement mis à jour et corrigés. Vous pouvez alors identifier rapidement les vulnérabilités potentiellement exploitables que vous devez évaluer et atténuer.
## Qu’est-ce qu’un SBOM ?
Les SBOM sont indispensables à la mise en œuvre de la sécurité de la chaîne d’approvisionnement logicielle ; ils constituent des éléments clés des programmes de cybersécurité de votre chaîne d’approvisionnement logicielle. Les SBOM s’apparentent à une liste d’ingrédients du logiciel qui compose les applications. Vous pouvez désigner ces éléments logiciels individuels comme des « composants » ou des « dépendances ». Helm vous permet d’assurer la transparence de votre chaîne d’approvisionnement logicielle auprès de votre entreprise, de vos auditeurs et même de vos clients, selon les politiques de votre entreprise, et de veiller à ce que les parties prenantes connaissent les dépendances, autrement invisibles, aux bibliothèques propriétaires, open source et sous licence, ainsi qu’aux bibliothèques commerciales prêtes à l’emploi (COTS).
Les éléments courants d’un SBOM comprennent :
* Bibliothèques open source.
* Plug-ins, extensions et modules complémentaires
* Code source personnalisé créé en interne
* Informations sur les versions, les licences et l’état des correctifs des composants
* SaaS : services tiers et informations sur les API nécessaires au fonctionnement de l’application SaaS.
## Les SBOM sont essentiels pour sécuriser votre présent et votre avenir
Les SBOM sont essentiels pour bâtir un avenir meilleur et plus sûr pour votre entreprise, vos clients et leurs patients. Il s’agit de la dernière étape d’une démarche visant à rendre visibles les dépendances de vos logiciels afin que vous puissiez ensuite gérer leurs vulnérabilités et vous concentrer d’abord sur celles qui présentent les risques les plus élevés et sont les plus critiques. Selon la FDA, il ne suffit plus de compter sur la « sécurité par l’obscurité » : en tant que fabricants de dispositifs médicaux, vous devez assumer la responsabilité et prendre conscience de votre [responsabilité avant la mise sur le marché](#pre-market-dependency-and-vulnerability-tracking) et [responsabilité après la mise sur le marché](#post-market-dependency-and-vulnerability-tracking) liées à l’utilisation de logiciels non sécurisés dans vos dispositifs et systèmes, qui sont ensuite transmis aux clients et aux patients.
{% hint style="info" %}
Selon Gartner, d’ici 2026, au moins 60 % des entreprises disposant de solutions logicielles essentielles à leur mission exigeront la divulgation des SBOM dans leurs contrats de licence et d’assistance.
{% endhint %}
### Attaques récentes en cybersécurité et évolution de la conjoncture économique
Au cours des dernières années, plusieurs attaques très médiatisées ont visé des chaînes d’approvisionnement logicielles. Aujourd’hui, les dispositifs connectés s’appuient sur de nombreuses bibliothèques logicielles, notamment des projets développés en interne, par des tiers et open source. À la suite de la pandémie, plusieurs pénuries de la chaîne d’approvisionnement ont touché des secteurs essentiels aux activités des entreprises, contraignant les fabricants de dispositifs et de produits à élargir leur réseau au-delà de leurs fournisseurs de confiance, ajoutant ainsi un niveau de risque à la chaîne d’approvisionnement logicielle. Voici quelques-unes des attaques récentes les plus marquantes, parmi bien d’autres :
#### **SolarWinds**
En 2020, l’attaque de la chaîne d’approvisionnement logicielle SolarWinds a eu des répercussions profondes et durables sur les infrastructures gouvernementales américaines et sur de nombreuses entreprises aux États-Unis, en Europe, en Asie et au Moyen-Orient. Des intrus ont piraté des réseaux informatiques au cours d’une opération qui a duré plusieurs mois contre SolarWinds, qui fournissait aux entreprises ciblées une plateforme de surveillance et de gestion des réseaux. Cette attaque a mis en lumière de manière saisissante l’étendue des connaissances des fabricants de dispositifs médicaux sur les logiciels utilisés dans leurs dispositifs.
#### **Log4Shell (Log4j)**
En 2021, une vulnérabilité critique d’exécution de code à distance a été découverte dans la bibliothèque open source de journalisation Java Apache Log4j, largement répandue. Son utilisation généralisée, conjuguée à la facilité avec laquelle même des pirates inexpérimentés peuvent l’exploiter, la rend particulièrement dangereuse et expose toute application Java dotée d’une interface utilisateur à une attaque Log4Shell. Cet incident a mis crûment en évidence le risque inhérent à l’utilisation de composants open source dans les dispositifs. Parmi les systèmes et services qui utilisent la bibliothèque Log4j figurent Twitter, Tesla, Apple, Minecraft et bien d’autres.
#### WannaCry
En 2017, l’attaque par rançongiciel [WannaCry](https://en.wikipedia.org/wiki/WannaCry_ransomware_attack) (également connu sous le nom de WannaCrypt) a ciblé des ordinateurs exécutant le système d’exploitation Microsoft Windows. Elle a utilisé l’exploit EternalBlue pour chiffrer les données et l’outil DoublePulsar pour installer et exécuter des copies du logiciel malveillant, puis a exigé des paiements en cryptomonnaie pour déchiffrer les données. Bien que Microsoft ait publié des correctifs pour combler la faille, de nombreuses organisations ne les avaient pas appliqués ou utilisaient d’anciennes versions de Windows qui n’étaient plus prises en charge. Selon Europol, WannaCry a infecté plus de 200 000 ordinateurs dans 150 pays, touchant le National Health Service et de nombreuses autres entreprises.
***Mon entreprise est-elle touchée par Log4j ou WannaCry ?***
Vous pouvez facilement le vérifier après avoir [généré](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.beg6wplcxva) et [chargé](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.sc55nidpf6zz) votre SBOM dans Helm !
Pour Log4j, vous pouvez [rechercher](/fr/helm/manage-vulnerabilities/check-whether-a-particular-vulnerability-impacts-your-products.md) « log4j » dans notre recherche globale afin d’obtenir la liste de tous les composants potentiellement touchés, ou rechercher l’identifiant de vulnérabilité CVE-2021-44228. Si vous pensez être concerné, consultez les [recommandations de la CISA sur la vulnérabilité Log4j](https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance) pour en savoir plus.
Pour WannaCry, vous pouvez rechercher les anciennes versions de Windows (par exemple, Windows XP et les versions ultérieures) afin de vérifier qu’elles ont été corrigées. Vous pouvez également rechercher les identifiants de vulnérabilité associés : CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147 et CVE-2017-0148. Si vous pensez être concerné, consultez la [fiche d’information de la CISA sur WannaCry](https://www.cisa.gov/sites/default/files/FactSheets/NCCIC%20ICS_FactSheet_WannaCry_Ransomware_S508C.pdf) pour en savoir plus.
### Répondre aux exigences gouvernementales
Selon Gartner, d’ici 2026, au moins 60 % des entreprises disposant de solutions logicielles essentielles à leur mission exigeront la divulgation des SBOM dans leurs contrats de licence et d’assistance.
En disposant d’un SBOM qui reflète l’état actuel de votre produit, vous disposez désormais d’un catalogue de toutes ses « listes d’ingrédients », ce qui améliore la visibilité et la transparence de votre chaîne d’approvisionnement logicielle et garantit que vos logiciels sont régulièrement mis à jour et corrigés. Vous pouvez alors identifier rapidement les vulnérabilités potentiellement exploitables que vous devez évaluer et atténuer.
### Sécurisez le présent et l’avenir de votre entreprise
Les SBOM sont essentiels pour bâtir un avenir meilleur et plus sûr pour votre entreprise, vos clients et leurs patients. Il s’agit de la dernière étape d’une démarche visant à rendre visibles les dépendances de vos logiciels afin que vous puissiez ensuite gérer leurs vulnérabilités et vous concentrer d’abord sur celles qui présentent les risques les plus élevés et sont les plus critiques. Selon la FDA, il ne suffit plus de compter sur la « sécurité par l’obscurité » : en tant que fabricants de dispositifs médicaux, vous devez assumer la responsabilité et prendre conscience de votre [responsabilité avant la mise sur le marché](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.xh1la7td7wpl) et [responsabilité après la mise sur le marché](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.pyfniwwcs9nl) liées à l’utilisation de logiciels non sécurisés dans vos dispositifs et systèmes, qui sont ensuite transmis aux clients et aux patients.
Le gouvernement américain a publié le [décret présidentiel 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) visant à améliorer la cybersécurité de la nation en 2021. Les agences fédérales ont ensuite été tenues d’adopter les directives du NIST, notamment d’utiliser des SBOM pour se conformer aux pratiques de développement logiciel sécurisé du NIST.
### Répondre aux exigences des hôpitaux
Les hôpitaux, qui utilisent les dispositifs médicaux, demandent de plus en plus souvent un SBOM détaillé dans le cadre de leurs accords de partenariat commercial (par exemple, [Mayo Clinic](https://www.mayoclinic.org/about-mayo-clinic/supplier-information/resources)). Parmi leurs attentes figurent le nom du dispositif ou de l’application, le nom du fournisseur et du produit selon le dictionnaire CPE du NIST, ainsi que la version ; l’identité du responsable de la fourniture et de l’application des mises à jour logicielles ; la fréquence des mises à jour du logiciel et l’application des correctifs de sécurité (en particulier lorsqu’une vulnérabilité est connue) ; le caractère essentiel du logiciel au fonctionnement du dispositif ; la manière dont le fabricant du dispositif médical (MDM) informera la Mayo Clinic des mises à jour ; et la date de fin de vie prévue du dispositif ou de l’application. En raison de la nécessité de réduire les dépenses d’exploitation tout en maintenant la meilleure qualité de soins, les systèmes de santé tels que la Mayo Clinic [continueront de refuser](https://www.mayoclinic.org/documents/supplier-briefings-pdf/doc-20079748) les hausses de prix des fournisseurs, les taxes répercutées (par exemple, la taxe sur les dispositifs médicaux) ou toute autre perte de valeur. Ils ont demandé aux fabricants de dispositifs médicaux (MDM) de continuer à rationaliser les processus et à améliorer leur efficacité.
## À quoi puis-je utiliser les SBOM ?
Vous pouvez utiliser les SBOM pour comprendre les risques de manière proactive et les prévenir ou les réduire, ainsi que pour répondre aux incidents lorsqu’ils surviennent.
En disposant d’un SBOM qui représente l’état actuel de votre produit, vous pouvez créer un catalogue de toutes vos « listes d’ingrédients » afin d’assurer la visibilité et la transparence de votre chaîne d’approvisionnement en logiciels, ainsi que d’identifier les vulnérabilités potentiellement exploitables que vous devez évaluer et atténuer.
### **Répondre aux exigences de la Mayo Clinic**
Si vous faites affaire avec la [Mayo Clinic](https://www.mayoclinic.org/about-mayo-clinic/supplier-information/resources), celle-ci demande souvent un SBOM détaillé dans le cadre de ses accords de partenaire commercial. Celui-ci doit notamment préciser le nom du dispositif ou de l’application, le nom du fournisseur et du produit selon le dictionnaire CPE du NIST, la version, ainsi que l’entité chargée de fournir et d’appliquer les mises à jour logicielles, leur fréquence, la fréquence d’application des correctifs de sécurité (en particulier lorsqu’une vulnérabilité est connue), le caractère essentiel du logiciel au fonctionnement du dispositif, la manière dont le fabricant de dispositifs médicaux (MDM) informera la Mayo Clinic des mises à jour et la date de fin de vie prévue du dispositif ou de l’application. En raison de la nécessité de réduire ses dépenses d’exploitation tout en maintenant les soins de santé de la plus haute qualité, la Mayo Clinic [continuera de rejeter](https://www.mayoclinic.org/documents/supplier-briefings-pdf/doc-20079748) les hausses de prix des fournisseurs, les taxes répercutées (par exemple, la taxe sur les dispositifs médicaux) ou toute autre perte de valeur. Elle a demandé aux fabricants de dispositifs médicaux (MDM) de continuer à rationaliser les processus et à améliorer leur efficacité.
### Suivi des composants et des vulnérabilités avant la mise sur le marché
Selon les recommandations de la FDA dans le document [Contenu des dossiers de soumission préalable à la mise sur le marché pour la gestion de la cybersécurité des dispositifs médicaux](http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf), les fabricants devraient prendre en compte la cybersécurité lors de la conception et du développement de leurs dispositifs médicaux, ce qui permet souvent d’atténuer plus efficacement et plus solidement les risques pour les patients et les opérateurs. Les fabricants de dispositifs médicaux doivent également définir des exigences de conception liées à la cybersécurité de leur dispositif et établir une approche de gestion des vulnérabilités en matière de cybersécurité dans le cadre de la validation logicielle et de l’analyse des risques requises par la [21 CFR 820.30(g)](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?fr=820.30). Cette approche devrait couvrir les éléments suivants :
* Identification des actifs, des menaces et des vulnérabilités
* Évaluation de l’incidence des menaces et des vulnérabilités sur le fonctionnement du dispositif et sur les opérateurs et les patients
* Évaluation de la probabilité qu’une menace se concrétise et qu’une vulnérabilité soit exploitée
* Détermination des niveaux de risque et des stratégies d’atténuation appropriées
* Évaluation du risque résiduel et des critères d’acceptation du risque.
Les dispositifs médicaux pouvant se connecter (sans fil ou par câble) à un autre dispositif, à Internet, à un autre réseau ou à un support amovible (par exemple, une clé USB ou un CD) sont davantage exposés aux menaces de cybersécurité que les dispositifs non connectés. Le niveau de sécurité nécessaire dépend de l’utilisation prévue du dispositif, de la présence et de la finalité de ses interfaces de données électroniques, de son environnement d’utilisation prévu, du type de vulnérabilités de cybersécurité présentes, de la probabilité que ces vulnérabilités soient exploitées et du risque probable de préjudice pour les patients résultant d’une atteinte à la cybersécurité. Pour déterminer si votre dispositif est considéré comme un cyberdispositif, consultez la section [Qu’est-ce que la FDA classe comme cyberdispositif ?](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.iuaf0u3xzfna) .
### Suivi des composants et des vulnérabilités après la mise sur le marché
Selon les recommandations de la FDA dans le document [Gestion de la cybersécurité des dispositifs médicaux après leur mise sur le marché](https://www.fda.gov/files/medical%20devices/published/Postmarket-Management-of-Cybersecurity-in-Medical-Devices---Guidance-for-Industry-and-Food-and-Drug-Administration-Staff.pdf), compte tenu de l’évolution constante des risques de cybersécurité auxquels sont exposés les dispositifs médicaux, les fabricants ne peuvent pas atténuer complètement les risques au moyen des seuls contrôles préalables à la mise sur le marché. Il est donc essentiel qu’ils mettent en œuvre des programmes complets de gestion de la cybersécurité et une documentation conformes au règlement sur le système qualité ([21 CFR part 820](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=820)), notamment en matière de traitement des réclamations, d’audits qualité, d’actions correctives et préventives, de validation logicielle et d’analyse des risques, ainsi que de maintenance.
Les programmes de gestion des risques de cybersécurité devraient traiter les vulnérabilités susceptibles de permettre un accès non autorisé, une modification, une utilisation abusive ou une indisponibilité, ainsi que l’utilisation non autorisée des informations stockées dans un dispositif médical, auxquelles celui-ci donne accès ou qu’il transmet, et pouvant entraîner un préjudice pour les patients. Ce programme devrait inclure :
* La surveillance des sources d’information sur la cybersécurité afin d’identifier et de détecter les vulnérabilités et les risques en matière de cybersécurité.
* Le maintien de processus robustes tout au long du cycle de vie logiciel, notamment des mécanismes permettant de :
* surveiller les composants logiciels tiers afin de détecter de nouvelles vulnérabilités tout au long du cycle de vie du dispositif
* vérifier et valider la conception des mises à jour logicielles et des correctifs utilisés pour remédier aux vulnérabilités, y compris pour les logiciels prêts à l’emploi
* Comprendre, évaluer et détecter la présence d’une vulnérabilité et son incidence
* Établir et communiquer des processus de réception et de traitement des signalements de vulnérabilités.
* Utiliser la modélisation des menaces pour définir clairement comment préserver la sécurité et les performances essentielles d’un dispositif, en élaborant des mesures d’atténuation qui protègent contre les risques de cybersécurité et permettent d’y répondre et de s’en remettre
* Adopter une politique et des pratiques de divulgation coordonnée des vulnérabilités
* Déployer des mesures d’atténuation des risques de cybersécurité dès que possible, avant toute exploitation.
### Participer à un ISAO pour partager des informations sur les vulnérabilités et les menaces
Selon les recommandations de la FDA dans le document [Gestion de la cybersécurité des dispositifs médicaux après leur mise sur le marché](https://www.fda.gov/files/medical%20devices/published/Postmarket-Management-of-Cybersecurity-in-Medical-Devices---Guidance-for-Industry-and-Food-and-Drug-Administration-Staff.pdf), il est vivement recommandé aux fabricants de dispositifs médicaux de participer à un ISAO qui partage des informations sur les vulnérabilités et les menaces affectant les dispositifs médicaux. Le partage et la diffusion, entre plusieurs secteurs, d’informations et de renseignements sur la cybersécurité concernant les vulnérabilités et les menaces sont essentiels à la réussite d’un programme de surveillance de la cybersécurité après la mise sur le marché.
Au cas où vous ne le sauriez pas, Medcrypt est propriétaire d’un ISAO, [MedISAO](https://www.medisao.com/) — nous serions ravis que vous vous joigniez à nous pour partager des informations !
### Modélisation des menaces
Dans le cadre de votre programme de cybersécurité, [Recommandations de la FDA sur la gestion après la mise sur le marché](https://www.fda.gov/files/medical%20devices/published/Postmarket-Management-of-Cybersecurity-in-Medical-Devices---Guidance-for-Industry-and-Food-and-Drug-Administration-Staff.pdf) indique que les fabricants doivent définir la sécurité et les performances essentielles de leur dispositif, la probabilité et la gravité des préjudices susceptibles d’être causés aux patients si le dispositif est compromis, ainsi que les critères d’acceptation des risques. Ces éléments vous permettront de trier rapidement les vulnérabilités à corriger et à atténuer. La modélisation des menaces est essentielle pour vous aider à comprendre et à évaluer la facilité d’exploitation d’une vulnérabilité, ainsi qu’à garantir que la correction de celle-ci permet de maîtriser raisonnablement le risque de préjudice pour les patients. Les mesures d’atténuation acceptables varient selon la gravité des préjudices potentiels pour les patients.
### Gestion d’une violation de données
Disposer d’un SBOM complet est essentiel en cas de violation de données : cela vous permet de détecter et d’analyser rapidement les logiciels concernés, de comprendre les conséquences de la violation et de déterminer quels autres composants pourraient être affectés, afin d’agir rapidement pour en limiter les conséquences pour votre entreprise, vos clients et leurs patients. Cela vous aide également à repérer les domaines critiques auxquels vous devez vous attaquer et à définir les priorités de votre plan de cybersécurité.
### **Détecter et analyser**
Les SBOM sont très utiles lors des phases de détection et d’analyse : ils donnent une visibilité sur le contenu du logiciel et fournissent le contexte et les détails nécessaires à l’analyse. Cela réduit considérablement le temps perdu à recueillir des informations à partir de fichiers binaires, ce qui est particulièrement important en cas de violation de données.
### **S’engager et rétablir le service**
En intervenant plus tôt dans le processus visant à assurer la transparence de l’ensemble de votre chaîne d’approvisionnement logicielle, vous pouvez obtenir les informations nécessaires auprès de vos fournisseurs et de tiers afin de déterminer les conséquences dans l’environnement particulier de votre dispositif. Cela vous permet également de repérer de manière proactive les correctifs nécessaires et d’en informer vos clients avant qu’une exploitation ne se produise.
Si votre SBOM est complet et exact, votre équipe de réponse aux incidents peut plus facilement comprendre le fonctionnement d’une application ou d’une API et ainsi replacer une attaque dans son contexte. Il peut également l’aider à retrouver les dépôts et les personnes impliquées dans le projet, ce qui réduit le temps de réponse. Si votre SBOM contient des informations sur les services, par exemple les connexions des systèmes dorsaux aux bases de données, aux files d’attente, aux API et aux répertoires, l’équipe peut s’en servir pour évaluer les conséquences d’une violation pendant qu’elle se produit. Elle peut également rechercher des composants ou des dépendances touchés ou concernés dans des domaines qu’elle n’a pas encore commencé à examiner, afin de s’assurer plus rapidement qu’une attaque donnée a été entièrement éliminée.
### **Réponse après incident**
Après avoir traité une exploitation, vous pouvez utiliser votre SBOM dans votre analyse rétrospective afin de repérer les domaines critiques à traiter et de définir les priorités à court et à plus long terme.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.medcrypt.com/fr/helm/get-started-with-helm/dont-have-an-sbom/why-sboms-are-critical-to-your-present-and-future.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.