Gestion des vulnérabilités CRA : étapes et preuves

Une bibliothèque vulnérable apparaît dans un produit déjà vendu. Le fabricant doit déterminer les versions touchées, décider des mesures, livrer un correctif et informer les destinataires concernés. Le CRA organise cette chaîne. Un tableau de scores ou un abonnement à des alertes ne remplace pas les décisions et les preuves de leur exécution.

Distinguer gestion et signalement

L’Art. 13(8) et l’annexe I, partie II du règlement (UE) 2024/2847 encadrent la gestion des vulnérabilités du produit et de ses composants pendant la période d’assistance. L’application générale commence le 11 décembre 2027, sous réserve des transitions.

Les obligations de signalement de l’article 14 s’appliquent déjà depuis le 11 septembre 2026. Elles visent les vulnérabilités activement exploitées et les incidents graves définis par le texte. Toute alerte de scanner ne déclenche donc pas automatiquement une déclaration. La procédure de signalement CRA doit néanmoins fonctionner en parallèle de la correction, sans attendre la clôture technique.

Un processus en six étapes

Cette grille est une organisation pratique. L’annexe I impose notamment l’inventaire, la correction sans retard, des tests et examens réguliers efficaces, la divulgation coordonnée, un contact et des mécanismes de distribution sécurisée.

Inventaire : ne pas confondre minimum et exhaustivité

Le SBOM doit couvrir au moins les dépendances de niveau supérieur dans un format couramment utilisé et lisible par machine. Étendre l’analyse aux dépendances indirectes et aux composants mal détectés peut être nécessaire pour maîtriser le risque ; l’automatisation à chaque livraison est un choix de mise en œuvre, pas une formulation littérale du règlement.

L’Art. 13(6) demande aussi de signaler au fabricant ou au mainteneur du composant tiers les vulnérabilités identifiées et de traiter celles qui affectent le produit. Lorsqu’un correctif a été développé, le partage du code ou de la documentation correspondants suit les conditions de cette disposition. Attendre passivement le fournisseur ne constitue pas un programme de traitement.

Prioriser sans inventer un délai légal de correction

Le CRA ne fixe pas une règle générale « critique : sept jours, élevé : trente jours ». Une cible interne doit dépendre de l’exploitation observée, de l’exposition, des conséquences et des possibilités de réduction du risque. Une exploitation en cours peut nécessiter une action immédiate, même si un délai interne plus long a été inscrit dans un tableau.

Consignez les mesures temporaires, leur efficacité attendue et la date de réexamen. Distinguez la sévérité technique d’une vulnérabilité du risque dans la configuration effectivement livrée. Aucun score unique ne décide à lui seul de la conformité.

Publier, corriger et protéger les utilisateurs

L’annexe I, partie II, point 4 prévoit la publication d’informations sur les vulnérabilités corrigées dès la publication d’une mise à jour de sécurité : produit, conséquences, gravité et moyens d’action. Dans un cas dûment justifié où le risque de publication l’emporte, l’information peut être retardée jusqu’à ce que les utilisateurs aient pu appliquer le correctif. Ce mécanisme ne reporte pas automatiquement les délais de signalement aux autorités.

Les correctifs disponibles doivent être diffusés sans retard et gratuitement, sous réserve de l’exception contractuelle précise pour un produit sur mesure destiné à un utilisateur professionnel. Leur séparation des mises à jour fonctionnelles est exigée lorsqu’elle est techniquement possible. La politique de support CRA doit intégrer ces conditions et la disponibilité des correctifs déjà émis.

Contact et divulgation coordonnée

Prévoyez un contact identifiable, une réception suivie, une qualification et un dialogue avec l’auteur du signalement. L’Art. 13(17) exclut un point de contact limité aux seuls outils automatisés. La politique de divulgation coordonnée doit expliquer le processus sans promettre une immunité pénale générale que le CRA ne crée pas.

Le fournisseur, l’intégrateur et le distributeur du produit doivent connaître leurs interlocuteurs. Une information bloquée dans une boîte commerciale peut compromettre tout le dispositif.

Mesurer la qualité du programme

Suivez des indicateurs internes qui éclairent une décision : délai de qualification, nombre de versions dont l’exposition reste inconnue, corrections disponibles mais non diffusées, mesures temporaires non réexaminées et avis sans destinataires identifiés. Ces indicateurs sont des propositions de pilotage, pas des seuils réglementaires.

Conservez les décisions et les éléments qui les justifient dans la documentation technique CRA. L’Art. 13(13) prévoit au moins dix ans après la mise sur le marché, ou la période d’assistance si elle est plus longue.

Ouvrir un dossier d’alerte qui conserve les incertitudes

Le premier document utile peut être très court : date de réception, auteur ou source, produit visé, composant annoncé, versions citées et éléments disponibles. Ajoutez un responsable de qualification et la prochaine action attendue. Cette organisation proposée évite qu’une alerte soit fermée au seul motif qu’elle ne correspond pas au nom commercial du produit.

Le rapprochement doit porter sur ce qui a effectivement été distribué. Un inventaire issu de la branche de développement actuelle peut différer de celui d’une version encore utilisée. Si le composant n’est pas retrouvé, distinguez « absence établie dans cette version » et « inventaire insuffisant pour conclure ». La seconde situation appelle une recherche complémentaire, pas une déclaration de produit non affecté.

Dans un scénario entièrement fictif, le fabricant Noisetier reçoit une alerte concernant une bibliothèque présente dans les éditions 3.0 et 3.1 de son logiciel. Son équipe connaît la composition de la version 3.1, mais n’a pas encore retrouvé le dossier complet de la 3.0. La fiche ne doit donc pas attribuer aux deux versions la conclusion obtenue pour une seule. Elle conserve une ligne ouverte pour la 3.0, avec la pièce recherchée et son responsable. Aucun résultat technique ni exploitation effective n’est supposé dans cet exemple.

Préparer la décision de correction

Pour chaque version concernée, rassemblez les conditions nécessaires à l’exploitation, les fonctions exposées, les conséquences possibles et les protections déjà présentes. Précisez la source de chaque information. Un avis du mainteneur constitue une pièce utile, mais sa portée doit être rapprochée de la configuration intégrée au produit.

La décision peut comparer plusieurs actions : corriger le composant, désactiver temporairement une fonction, limiter une exposition ou remplacer une dépendance. Pour chaque option, décrivez l’effet attendu et les conséquences pour l’utilisateur. Une limitation temporaire doit être accompagnée d’un responsable et d’un réexamen ; elle ne devient pas une correction définitive par la seule expiration d’un délai interne.

Si une mesure ne peut pas être livrée immédiatement, expliquez le blocage réel et les actions engagées. « Attente fournisseur » est une indication trop pauvre : identifiez la demande, la réponse reçue, la solution provisoire étudiée et l’escalade nécessaire. Le dossier doit permettre de comprendre comment le fabricant traite son propre produit, même lorsque la modification initiale dépend d’un tiers.

Organiser la vérification et la mise à disposition

Avant une vérification, définissez son objectif, les versions couvertes et les conditions d’exécution. La méthode proposée consiste à examiner la correction du défaut identifié, puis les effets sur les fonctions pertinentes du produit. Conservez les résultats et les limites : une vérification sur une configuration ne couvre pas automatiquement toutes les installations possibles.

La fiche de livraison peut réunir les éléments suivants :

• versions concernées et moyen permettant à l’utilisateur de les identifier ;
• version corrigée ou mesure d’atténuation proposée ;
• prérequis, instructions et conséquences opérationnelles connues ;
• canal de distribution retenu et interlocuteur en cas d’échec ;
• informations publiées et justification d’un éventuel report autorisé.

Il s’agit d’un outil de travail, à adapter au produit. Reliez-le aux éléments qui établissent la mise à disposition effective. L’annonce d’une livraison prochaine ne suffit pas à montrer qu’un utilisateur peut déjà obtenir le correctif. Inversement, sa disponibilité ne prouve pas qu’il a été installé chez chaque destinataire.

Clore les tâches sans perdre le suivi

Dans le dossier fictif Noisetier, trois suivis peuvent rester distincts : la qualification de la version 3.0, la livraison destinée aux versions affectées et les communications requises. La clôture de l’un ne doit pas fermer automatiquement les autres. Un signalement réglementaire peut continuer alors que le travail de développement est terminé.

La revue du dossier peut ensuite examiner les versions encore sans conclusion, les mesures temporaires toujours actives et les difficultés remontées par les utilisateurs. Attribuez chaque point restant à une action identifiable. Si un élément nouveau contredit la première analyse, conservez cette analyse avec sa date et exposez pourquoi elle est révisée.

Cette chronologie donne une portée utile aux indicateurs : elle distingue une décision justifiée, une attente documentée et une tâche oubliée. Elle ne dispense ni de traiter sans retard les vulnérabilités ni de respecter les signalements applicables selon leurs propres critères.

Ce qu’il faut retenir

• La gestion des vulnérabilités couvre le produit et ses composants pendant l’assistance.
• Les signalements requis fonctionnent en parallèle de la correction.
• Les délais internes ne remplacent pas l’exigence de correction sans retard.
• Chaque alerte doit conduire à une décision traçable, puis à son suivi.

FAQ

Faut-il déclarer toutes les CVE ?

Non. L’article 14 prévoit des critères précis, dont l’exploitation active pour les vulnérabilités. Il faut documenter la qualification et examiner séparément l’existence d’un incident grave.

Un scanner suffit-il à respecter le CRA ?

Non. Il peut aider à détecter des composants ou vulnérabilités, mais ne remplace ni l’analyse du risque, ni les corrections, ni la communication et les preuves.

Le fabricant doit-il agir sur un composant tiers ?

Oui, lorsque ses vulnérabilités affectent le produit. Le dialogue avec le mainteneur et les mesures de correction ou d’atténuation font partie du travail à organiser.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.