Tout fabricant soumis au CRA a besoin d'un processus vivant de gestion des vulnérabilités pour chaque produit : savoir ce que contient le produit, trouver et corriger les vulnérabilités, tester régulièrement, publier des avis, recevoir les signalements externes et livrer gratuitement des mises à jour de sécurité. Cette page explique ce modèle opérationnel et le point où il bascule vers le signalement réglementaire urgent.
Résumé
- La gestion des vulnérabilités est un modèle opérationnel d'ingénierie dont chaque fabricant CRA a besoin pour chaque produit comportant des éléments numériques.
- Huit obligations numérotées : identifier (avec SBOM), remédier sans retard, tester régulièrement, divulguer publiquement les vulnérabilités corrigées, opérer une politique CVD, faciliter le signalement des vulnérabilités, distribuer les mises à jour de manière sécurisée, fournir gratuitement les mises à jour de sécurité.
- La gratuité n'est pas négociable : les mises à jour de sécurité sont gratuites par défaut, avec une dérogation étroite pour les produits sur mesure fournis à des utilisateurs professionnels.
- La politique CVD est obligatoire, pas optionnelle : la divulgation coordonnée des vulnérabilités fait partie de la préparation au marquage CE, pas d'une bonne pratique volontaire.
- La gestion des vulnérabilités s'opère tout au long de la période d'assistance ; le minimum est de cinq ans à compter de la mise sur le marché sauf si la durée d'utilisation prévue est plus courte et divulguée.
- La gestion des vulnérabilités n'est pas le signalement réglementaire urgent : la gestion est le processus d'ingénierie quotidien ; le signalement ne démarre qu'en cas d'exploitation active ou d'incident grave.
Les quatre repères de la gestion des vulnérabilités CRA : périmètre, durée, coût des mises à jour et frontière avec le signalement urgent.
Les huit obligations de gestion des vulnérabilités
Le CRA ne traite pas la gestion des vulnérabilités comme une simple liste de vérification. Il attend un cycle continu pendant toute la période d'assistance, depuis l'inventaire des composants jusqu'à la remédiation, la divulgation et la livraison sécurisée des mises à jour. Le tableau regroupe les huit obligations juridiques par phase opérationnelle.
| Phase | Points | Ce que cela couvre | Point d'attention opérationnel |
|---|---|---|---|
| Détecter et cataloguerEntrée et inventaire | Points 1 et 6 | Identification des composants et vulnérabilités connues à partir du SBOM, plus un canal public de signalement. | Garder les données de composants à jour et faciliter le contact avec l'équipe sécurité produit. |
| Concevoir et corrigerRemédiation et tests | Points 2 et 3 | Remédiation sans retard et tests réguliers efficaces de la base de code et de ses dépendances. | Utiliser la gravité pour fixer l'urgence et conserver la preuve que les correctifs et tests ont été réalisés à temps. |
| DistribuerCanal de mise à jour sécurisé | Points 7 et 8 | Mises à jour de sécurité signées et authentifiées, dissociables des fonctionnalités et gratuites sauf pour les produits B2B sur mesure. | Livrer les correctifs de sécurité sans forcer les utilisateurs vers des fonctionnalités nouvelles ou des paliers de maintenance payants. |
| Coordonner et divulguerCVD et avis | Points 4 et 5 | Une politique CVD appliquée et des avis publics dès qu'un correctif est disponible. | Coordonner l'entrée chercheurs, l'information utilisateurs et les reports justifiés depuis un même playbook. |
Ce que chaque obligation signifie en pratique
| # | Obligation | Ce qu'elle exige réellement |
|---|---|---|
| 1 | Identifier et documenter les vulnérabilités et les composants | Un SBOM en CycloneDX ou SPDX, couvrant au minimum les dépendances de premier niveau. Le SBOM est l'index qui rend possible la mise en correspondance avec les CVE : on ne peut pas remédier ce que l'on n'a pas catalogué. |
| 2 | Remédier sans retard, séparément des fonctionnalités | Pas de SLA fixe ; la rapidité attendue est proportionnée à la gravité. Les branches de sécurité doivent être dissociables des branches de fonctionnalités afin que les utilisateurs ne puissent pas reporter un correctif en reportant une version. |
| 3 | Tests efficaces et réguliers | Analyse statique, tests dynamiques, scan des dépendances par rapport aux flux de vulnérabilités, et tests de pénétration. « Régulier » doit correspondre au risque et au rythme d'évolution de la base de code. |
| 4 | Divulgation publique des vulnérabilités corrigées | Une fois le correctif livré, publier la description, le produit affecté, l'impact, la gravité et la remédiation. Report uniquement « dans les cas dûment justifiés » jusqu'à ce que les utilisateurs puissent appliquer le correctif. CVE plus CSAF est le support de fait. |
| 5 | Politique de divulgation coordonnée des vulnérabilités | Une politique CVD écrite et appliquée, avec canal d'entrée, SLA de réponse et conditions de divulgation. ISO/IEC 29147 et 30111 fournissent un cadre formel. |
| 6 | Faciliter le signalement externe des vulnérabilités | Une adresse de contact pour signaler les problèmes affectant le produit et ses composants tiers. security.txt au titre de la RFC 9116 satisfait à l'exigence de canal. |
| 7 | Distribution sécurisée des mises à jour | Mises à jour signées, authentifiées, automatiques lorsque c'est applicable. Les produits sans canal de mise à jour doivent en construire un ou documenter pourquoi l'automatisation n'est pas applicable. Voir mises à jour de sécurité. |
| 8 | Gratuit, avec messages d'avis | Les mises à jour de sécurité doivent être diffusées sans retard et gratuitement (seule dérogation : produits sur mesure destinés à des utilisateurs professionnels lorsque les parties en sont convenues autrement). Chaque mise à jour doit être accompagnée d'un message d'avis décrivant le problème et l'action que l'utilisateur doit entreprendre. Une barrière de maintenance payante, ou un correctif silencieux sans avis, viole le point 8. |
Gestion des vulnérabilités et période d'assistance
La gestion des vulnérabilités dure pendant toute la période d'assistance. Le minimum par défaut est de cinq ans à compter de la mise sur le marché européen, sauf si la durée d'utilisation prévue est plus courte et divulguée. La date de fin d'assistance doit figurer dans les informations produit. Une fois cette période échue, les obligations actives de gestion cessent pour cette version du produit, mais la documentation technique et la déclaration de conformité doivent encore être conservées pendant 10 ans à compter de la mise sur le marché ou pendant la période d'assistance, selon la durée la plus longue. Voir période d'assistance CRA.
La gestion des vulnérabilités n'est pas le signalement urgent
Le CRA distingue deux obligations qui opèrent sur des surfaces et des destinataires différents :
- La gestion des vulnérabilités est le processus d'ingénierie : SBOM, remédiation, politique CVD, divulgation publique et mises à jour sécurisées. Elle s'applique à toutes les vulnérabilités pendant toute la période d'assistance et relève de l'organisation de sécurité produit du fabricant.
- Le signalement réglementaire urgent ne démarre qu'en cas de vulnérabilité activement exploitée ou d'incident grave ayant un impact sur la sécurité du produit. Il est déposé via la plateforme unique de signalement ENISA selon une cadence 24h / 72h, suivie d'un rapport final (14 jours après la disponibilité d'une mesure corrective ou d'atténuation pour une vulnérabilité activement exploitée, ou un mois après la notification à 72h pour un incident grave), à l'ENISA et au CSIRT désigné comme coordinateur. Pour les modalités d'intégration à la SRP, voir intégration à la SRP ENISA.
Une équipe produit peut exécuter un processus conforme de gestion des vulnérabilités sans jamais déposer de signalement urgent, car la plupart des vulnérabilités sont remédiées avant d'être activement exploitées. Le signalement ne démarre que lorsque la remédiation n'a pas encore rattrapé l'exploitation active ou un incident grave. Voir signalement des vulnérabilités CRA.
Exposition aux sanctions
Les défaillances de gestion des vulnérabilités peuvent entraîner des amendes administratives importantes, mais le détail des niveaux relève du guide dédié à l'application. Voir sanctions et application du CRA pour les niveaux d'amende, les déclencheurs d'application et la place des défaillances de gestion des vulnérabilités dans le modèle global.
Foire aux questions
Le SBOM doit-il couvrir les dépendances transitives ?
Le plancher légal correspond aux dépendances de premier niveau, mais un SBOM exploitable doit généralement aller plus loin. On ne peut pas remédier sans retard à un CVE dans un composant transitif que l'on n'a jamais catalogué. La plupart des régulateurs et des clients attendent un SBOM en profondeur conforme à BSI TR-03183 ou à des orientations comparables. CycloneDX et SPDX sont tous deux qualifiés de formats couramment utilisés et lisibles par machine. Voir exigences SBOM CRA.
Que signifie « sans retard » en pratique pour la remédiation au titre du point 2 ?
Le CRA ne fixe pas de SLA de remédiation. « Sans retard » est proportionné au risque de cybersécurité : une vulnérabilité critique avec exploitation active dans la nature exige un correctif en quelques jours, tandis qu'un problème de faible gravité peut attendre le prochain cycle régulier. La gravité s'établit avec CVSS, s'affine avec les données de probabilité d'exploitation EPSS, et se confirme par les éléments du catalogue CISA KEV lorsque la vulnérabilité figure sur la liste des vulnérabilités activement exploitées de la CISA. Voir notation de gravité pour l'échelle opérationnelle que les autorités de surveillance du marché appliquent pour apprécier si un fabricant a remédié « sans retard ».
Les mises à jour de sécurité peuvent-elles être facturées dans certaines circonstances ?
Une seule dérogation existe : les produits sur mesure fournis à un utilisateur professionnel peuvent faire l'objet d'un arrangement payant si le fabricant et l'utilisateur professionnel en sont convenus autrement. Pour tout autre produit, y compris l'ensemble des produits grand public et des produits SaaS ou matériels B2B standard, les mises à jour de sécurité doivent être gratuites tout au long de la période d'assistance. Conditionner un correctif de sécurité à un palier de maintenance payant expose le fabricant aux amendes du niveau le plus élevé.
Les obligations de gestion des vulnérabilités se poursuivent-elles après la fin de l'assistance ?
Non. Les huit obligations de gestion des vulnérabilités cessent pour cette version du produit lorsque la période d'assistance prend fin. Les nouvelles vulnérabilités découvertes après la fin de l'assistance n'ont pas à être remédiées pour cette version, à condition que le fabricant ait publié une date de fin d'assistance claire afin que les utilisateurs puissent migrer. Deux obligations se poursuivent quoi qu'il arrive. La documentation technique et la déclaration UE de conformité doivent encore être conservées pendant 10 ans à compter de la mise sur le marché ou pendant la période d'assistance, selon la durée la plus longue. Le signalement est distinct de la gestion : si le fabricant prend connaissance d'une vulnérabilité activement exploitée ou d'un incident grave affectant le produit, l'obligation de signalement de l'article 14 peut encore s'appliquer, car elle n'est pas liée à la période d'assistance. Voir période d'assistance et divulgation de la fin d'assistance.
Quand une entrée CVD exige-t-elle un signalement urgent ?
Le déclencheur est l'exploitation active, pas un signalement privé ni une preuve d'exploitabilité. Une preuve de concept fonctionnelle jointe à un signalement CVD n'est pas en soi à signaler ; elle le devient lorsqu'il existe une croyance raisonnable qu'un acteur malveillant a utilisé la faille contre une cible réelle. Une fois ce seuil franchi, l'alerte précoce de 24 heures à l'ENISA et au CSIRT coordinateur démarre, suivie de la notification à 72 heures et d'un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. Voir signalement des vulnérabilités CRA.