Gestion des CVE dans un produit connecté :
les 3 erreurs courantes
La veille CVE ne suffit pas à respecter le CRA. La plupart des équipes font les mêmes erreurs — et ne s’en rendent compte qu’au moment d’une notification d’incident ou d’un audit.
Le Cyber Resilience Act impose aux fabricants de gérer activement les vulnérabilités qui affectent leurs produits — pas seulement de surveiller les CVE publiées, mais d’analyser leur impact réel, de corriger ou de justifier l’absence de correction, et de notifier les autorités en cas d’exploitation active. En pratique, la plupart des équipes qui pensent avoir un processus de gestion des CVE commettent trois erreurs structurelles qui les exposent directement aux sanctions CRA.
Erreur #1 — Surveiller les CVE sans les corréler à vos produits
L’équipe s’abonne aux flux NVD ou CVE Mitre, reçoit les alertes, les lit… et ne sait pas quoi en faire. Parce que personne ne sait exactement quels composants sont dans quels produits, en quelle version, dans quelle configuration.
Résultat : soit on ignore les alertes par défaut, soit on traite toutes les CVE qui mentionnent un composant qu’on utilise — y compris celles qui ne sont pas exploitables dans votre configuration. Les deux approches sont problématiques face au CRA.
La bonne pratique : la corrélation CVE doit partir du SBOM. Pour chaque CVE publiée, la question est « est-ce que l’un de mes produits utilise ce composant en version affectée ? ». Sans SBOM à jour, cette question prend des jours. Avec un SBOM automatisé corrélé aux bases de vulnérabilités, la réponse est disponible en quelques minutes.
Le test des 24h : si une CVE critique est publiée ce soir sur une bibliothèque répandue, combien de temps faut-il à votre équipe pour répondre à la question « est-ce que l’un de nos produits est affecté et en quelle version » ? Si la réponse dépasse 2h, vous ne serez pas conforme au délai de notification CRA de 24h.
Erreur #2 — Traiter toutes les CVE avec la même priorité
Le score CVSS est utile, mais il décrit la gravité théorique d’une vulnérabilité — pas son exploitabilité réelle dans votre contexte. Une CVE CVSS 9.8 sur un composant utilisé uniquement dans une fonction interne non exposée au réseau est concrètement moins dangereuse qu’une CVE CVSS 7.0 sur un composant directement exposé aux requêtes utilisateurs.
Traiter toutes les CVE critiques avec la même urgence crée une surcharge qui épuise les équipes — et conduit à négliger les vraiment importantes. Ou à l’inverse, ignorer des CVE « medium » qui sont en réalité critiques dans votre configuration.
La bonne pratique : combiner le CVSS avec l’EPSS (Exploit Prediction Scoring System) — un score probabiliste qui indique si une CVE est susceptible d’être exploitée dans les 30 prochains jours — et avec le contexte d’exposition de votre produit. Une CVE CVSS 9.0 avec EPSS 2% sur un composant interne est moins urgente qu’une CVE CVSS 7.5 avec EPSS 35% sur un endpoint public.
Le piège du « on ne peut pas tout corriger » : le CRA ne demande pas de corriger toutes les CVE immédiatement. Il demande de les analyser, de documenter votre décision, et de justifier pourquoi une CVE non corrigée n’expose pas vos utilisateurs. L’absence de documentation est ce qui crée une exposition réglementaire — pas l’absence de correctif.
Erreur #3 — Traiter les CVE comme un problème d’infrastructure, pas de produit
Beaucoup d’équipes ont un processus de gestion des CVE pour leur infrastructure interne — serveurs, outils DevOps, plateformes cloud. C’est bien, mais ce n’est pas ce que le CRA cible.
Le CRA vise les composants embarqués dans vos produits commerciaux — les bibliothèques compilées dans votre firmware, les dépendances de votre SDK, les composants de votre application embarquée. Ce sont des composants que vous ne « patchez » pas en un clic : il faut produire une nouvelle version du produit, la tester, la distribuer aux clients, et documenter tout le processus.
La bonne pratique : distinguer explicitement la gestion CVE infrastructure (équipe IT/Ops) et la gestion CVE produit (équipe R&D + PSIRT). Pour les CVE produit, le processus doit inclure : analyse d’impact, décision correctif/workaround/acceptation documentée, planification de la version corrective, communication client via VEX, et archivage de la décision pour audit.
Alertes contextualisées par produit, priorisation CVSS + EPSS, génération de VEX et traçabilité complète pour audit CRA.
Ce que le CRA exige concrètement sur les CVE
Pour être conforme CRA sur la gestion des vulnérabilités, voici les quatre exigences concrètes :
- Processus de surveillance continue — un mécanisme automatisé qui corrèle chaque nouvelle CVE publiée avec les composants de vos produits et génère une alerte en cas de correspondance.
- Analyse documentée pour chaque CVE — chaque CVE affectant un composant de vos produits doit faire l’objet d’une analyse documentée : impact réel, vecteur d’attaque accessible, décision prise et justification.
- Notification ENISA en 24h — si une CVE est activement exploitée dans l’un de vos produits, notification obligatoire à l’ENISA dans les 24h. Rapport final sous 14 jours.
- Communication client — les utilisateurs affectés doivent être informés des vulnérabilités et des correctifs disponibles. Le standard pour cette communication est le VEX.
Par où commencer
Si vous partez de zéro, voici les trois priorités dans l’ordre :
- Priorité 1 — SBOM : sans inventaire précis des composants, rien d’autre n’est possible. Commencez par automatiser la génération de SBOM sur vos produits les plus exposés.
- Priorité 2 — Corrélation CVE : connectez vos SBOM à une base de vulnérabilités (NVD, OSV ou solution commerciale) pour recevoir des alertes contextualisées par produit.
- Priorité 3 — Processus de décision documenté : définissez qui analyse chaque alerte, quel délai, quelle documentation obligatoire, et comment la décision est archivée. C’est ce qui vous protège en cas d’audit.
L’objectif n’est pas zéro CVE — c’est zéro surprise : le CRA ne demande pas d’avoir un produit sans vulnérabilité (c’est impossible). Il demande de savoir ce que contient votre produit, de surveiller activement les CVE qui l’affectent, et d’être capable de démontrer que vous gérez le risque de façon documentée et traçable.
VAST corrige les 3 erreurs à la source
SBOM automatisé, corrélation CVE contextuelle par produit, priorisation CVSS + EPSS et génération de VEX — le tout tracé et archivé pour vos audits CRA.