Préparer la gestion des vulnérabilités CRA d’un fabricant : réception, preuves et délais de notification

Objectif

État au 25 octobre 2026. Préparer le processus de gestion des vulnérabilités d’un fabricant afin de pouvoir retrouver les preuves, les responsabilités relatives aux produits et les échéances de notification pendant un incident. Consulter à nouveau l’article 14, l’annexe I et les instructions actuelles de la SRP de l’ENISA lors de la mise à jour du processus. Il s’agit d’une proposition de protocole de préparation, et non de l’affirmation qu’une organisation a réussi une évaluation de conformité.

Les notifications prévues à l’article 14 sont obligatoires depuis le 11 septembre 2026. L’article 71 fixe au 11 décembre 2027 l’application des exigences plus larges, dont les obligations de gestion des vulnérabilités de l’annexe I. La préparation de ces obligations ultérieures peut faciliter les notifications dès maintenant, mais leurs dates doivent rester distinctes. Orientations de la Commission sur les notifications.

Prérequis

Identifier les produits concernés du fabricant, les équipes d’ingénierie qui en sont responsables, un responsable des notifications et un suppléant. Prévoir un dossier d’incident à accès restreint, un accès aux informations sur les versions et les composants, ainsi qu’un canal de communication avec les utilisateurs concernés. Il s’agit de dispositions organisationnelles proposées. Confirmer le CSIRT coordinateur approprié au regard de l’article 14(7), plutôt que d’en choisir un simplement pour des raisons de commodité linguistique.

Étapes

1. Rattacher la réception des signalements à un responsable désigné. Préparer la politique de divulgation coordonnée des vulnérabilités et le contact de signalement décrits dans l’annexe I, partie II. Un fichier facultatif security.txt conforme à RFC 9116 peut y orienter les chercheurs : utiliser HTTPS à l’emplacement /.well-known/security.txt, inclure les champs obligatoires Contact et Expires et fournir un lien vers la politique via Policy. Maintenir le fichier et ses destinations à jour. RFC 9116, sections 2, 3 et 5.

2. Créer immédiatement un dossier. Pour une organisation pratique du dossier, distinguer l’heure de réception, les preuves reçues, le moment de la prise de connaissance d’un événement à notifier, le responsable de la décision et les révisions ultérieures. Préserver les preuves originales et expliquer les changements d’évaluation. Les approbations internes ne devraient pas réinitialiser silencieusement l’horodatage de la prise de connaissance.

3. Relier le problème aux versions. Tenir à jour une nomenclature logicielle (SBOM) avec les identifiants des produits et des versions. L’annexe I, partie II(1), impose un format lisible par machine d’usage courant couvrant au moins les dépendances de premier niveau lorsque cette exigence s’applique. Ce protocole propose de relier ces dossiers aux versions distribuées afin de pouvoir reconstituer la liste des produits affectés. Une SBOM constitue un inventaire, et non une preuve d’exploitation.

4. Évaluer séparément les faits déclencheurs prévus par la loi. Selon l’article 3(42), l’exploitation active exige des preuves fiables qu’un acteur malveillant a exploité la vulnérabilité sans l’autorisation du propriétaire du système. Confronter les incidents graves aux deux critères de l’article 14(5). Consigner les preuves et les questions non résolues ; un score de gravité ne suffit pas à établir une exploitation active. Les étapes 1, 3 et 4 s’appuient sur le règlement.

5. Tenir à jour le suivi des échéances. Planifier les étapes à 24 heures et à 72 heures à partir de la prise de connaissance, tout en conservant l’exigence d’agir rapidement. Calculer le délai du rapport final de vulnérabilité à partir de la disponibilité d’une mesure corrective ou d’atténuation, et celui du rapport final d’incident à partir de l’envoi de la notification d’incident. Conserver ensemble les accusés de réception, les versions envoyées et les demandes des autorités.

6. Préparer l’accès à la plateforme et les communications. L’ENISA exige des comptes EU Login personnels avec authentification multifacteur. Sa FAQ d’octobre recommande d’engager l’inscription à la SRP lorsqu’une notification est nécessaire ; préparer l’accès EU Login au préalable. Maintenir la communication avec les utilisateurs concernés parallèlement aux notifications aux autorités. FAQ SRP de l’ENISA, question 9.

7. Réaliser un exercice interne. Utiliser un cas de produit fictif et rédiger les projets de notification en dehors de la plateforme de notification en production. Faire retrouver les preuves par le suppléant, lui faire reconstituer les échéances et expliquer le choix des destinataires. Consigner les éléments manquants et répéter la passation qui a échoué après les avoir corrigés.

Résultat attendu

Une personne chargée de l’examen peut suivre un dossier depuis sa réception jusqu’à l’identification des produits, l’évaluation des faits déclencheurs, l’envoi de la notification et les communications aux utilisateurs, sans devoir reconstituer la chronologie à partir de messages dispersés.

Limites et base de vérification

Aucun résultat d’exercice ni de mise en pratique sur le terrain n’est revendiqué. La proposition réunit le règlement, les orientations de la Commission, la FAQ de l’ENISA mise à jour le 15 octobre 2026 et RFC 9116. Ni la publication d’un fichier de contact ni la réussite d’un exercice ne prouvent la conformité ; le périmètre des produits et les évaluations contestées des faits déclencheurs nécessitent toujours un examen qualifié.