Du SBOM au VEX : gérer les vulnérabilités d'un dispositif médical sans noyer l'équipe

Votre SBOM est en place : généré à chaque release, au bon format, conforme aux exigences FDA et CRA. Puis vous lancez le premier scan de vulnérabilités, et le rapport tombe : des dizaines, parfois des centaines de CVE. L’équipe ne peut pas tout corriger — et le régulateur, lui, attend une décision documentée sur chacune. Entre l’inventaire et la conformité, il manque une pièce : le pipeline scan → triage → VEX, qui transforme un déluge d’alertes en analyses d’impact défendables.

Pourquoi un SBOM seul ne protège de rien ?

Définition : la surveillance des vulnérabilités consiste à confronter en continu le SBOM aux bases publiques (NVD, GitHub Advisories, OSV) pour détecter les CVE publiées après la mise sur le marché. Le SBOM est une photographie ; la menace, elle, évolue chaque jour. Un composant sain le jour de la release peut devenir le maillon faible du parc six mois plus tard — Log4Shell l’a rappelé à tout le monde.

C’est exactement ce que les textes exigent. La section 524B(b)(1) du FD&C Act impose un plan pour « surveiller, identifier et traiter » les vulnérabilités post-market, divulgation coordonnée comprise — le cœur du plan de cybersécurité attendu par la FDA. L’IEC 81001-5-1 demande un processus de veille et de traitement des vulnérabilités sur tout le cycle de vie — l’un des cinq chantiers du rattrapage à mener sur du code existant. Le MDR (art. 83) exige de son côté que la surveillance après commercialisation couvre aussi le logiciel. Le CRA ajoute une contrainte de délai : notifier toute vulnérabilité activement exploitée sous 24 heures.

Le point que les équipes venues du DevSecOps classique ratent souvent : en médical, ce n’est pas la branche main qu’il faut surveiller, c’est le parc en exploitation. Une CVE qui touche la version installée dans quarante établissements de santé compte plus qu’une CVE corrigée sur la prochaine release.

À quoi ressemble le pipeline ?

Trois étages, tous automatisables :

• Générer un SBOM à chaque release (Syft, plugin CycloneDX de votre écosystème) — et l’archiver comme un enregistrement du système qualité, une version = un SBOM.
• Scanner planifié : Grype, Trivy ou OSV-Scanner rejouent quotidiennement les SBOM archivés des versions encore sur le terrain. Pas besoin de rebuilder quoi que ce soit — on scanne le fichier, pas le dépôt :

grype sbom:./releases/v2.3.1.cdx.json

• Comparer au passage précédent : la sortie utile n’est pas la liste complète, c’est le delta — les CVE apparues depuis hier sur des versions en exploitation.

Ce pipeline s’insère naturellement dans une CI qui produit déjà la documentation depuis les sources de vérité — même logique que pour la doc IEC 62304 : l’artefact réglementaire naît du build, pas d’un document Word maintenu à la main.

Le vrai problème : le bruit

Un scanner est délibérément paranoïaque : il signale toute correspondance entre un composant et une CVE, sans savoir si le code vulnérable est appelé, si la fonction touchée est exposée, ou si une mesure d’architecture neutralise déjà l’attaque. Une grande partie des alertes concernent du code que votre produit n’exécute jamais.

En DevSecOps classique, on « mute » ces faux positifs dans la config du scanner et on passe à autre chose. En dispositif médical, cette option n’existe pas : chaque alerte doit se terminer en décision documentée — corrigée, ou écartée avec justification. Sans outillage, il ne reste que deux mauvais choix : ignorer silencieusement (indéfendable à l’audit) ou analyser chaque CVE à la main (l’équipe coule en quelques sprints).

VEX : l’analyse d’impact lisible par machine

Définition : un document VEX (Vulnerability Exploitability eXchange) déclare, pour un produit donné, le statut d’une vulnérabilité — affected, not_affected, fixed ou under_investigation — accompagné d’une justification. C’est le compagnon du SBOM : l’un dit ce que contient le produit, l’autre dit ce qui l’affecte réellement.

Pour le statut not_affected, la CISA définit cinq justifications machine-réadables : composant absent du produit final, code vulnérable absent, code vulnérable jamais dans le chemin d’exécution, code vulnérable non contrôlable par un attaquant, mitigations déjà en place. Trois formats coexistent — OpenVEX, CycloneDX VEX et CSAF — et les scanners les consomment directement : passez votre fichier VEX à Grype ou Trivy, et les not_affected documentés disparaissent de la sortie. Le rapport quotidien ne montre plus que ce qui est nouveau et non traité.

La convergence médicale est immédiate : une déclaration VEX, c’est très exactement l’analyse d’impact que votre processus post-market exige déjà — horodatée, versionnée, auditable. Et c’est la réponse outillée à la question qu’un client hospitalier vous posera un jour : « êtes-vous affectés par la CVE dont parle la presse ? »

En contexte réglementé, écarter une CVE n’est pas interdit. Ce qui est indéfendable, c’est de l’écarter sans trace. Le VEX transforme un silence en décision signée.

Quelle étape couvre quelle exigence ?

FAQ

À quelle fréquence faut-il scanner ?

À chaque build pour le code en développement — et c’est le réflexe que tout le monde a déjà. Le scan qui compte en post-market est l’autre : planifié, quotidien ou hebdomadaire, sur les SBOM des versions en exploitation. Une CVE naît par définition après votre release ; seul un scan récurrent la voit.

Le VEX est-il obligatoire ?

Aucun texte ne l’impose nommément. Ce qui est exigé — par la FDA comme par l’IEC 81001-5-1 — c’est l’analyse documentée de chaque vulnérabilité affectant le produit. Le VEX en est la forme standardisée et outillable : il fait d’une obligation de processus un artefact que la CI produit et que le scanner consomme.

Peut-on déclarer « not_affected » sans patcher ?

Oui — à trois conditions : la justification correspond à l’une des catégories reconnues, elle est vérifiée par quelqu’un qui connaît le code, et elle est réévaluée quand le produit change (une fonction non appelée aujourd’hui peut l’être dans la prochaine version). C’est un enregistrement du système qualité comme un autre : daté, signé, révisable.