Le jour où un dossier art. 14 s'ouvre

euvex croise le SBOM du scan rattaché à un produit avec le catalogue CISA des vulnérabilités activement exploitées, dit KEV : quand vous créez le produit ou y rattachez un scan, quand vous déposez un scan rattaché, puis à chaque revérification quotidienne. Un composant de compilation, marqué comme tel, ne compte pas ; un composant dont on ignore s'il est distribué compte.

Un dossier s'ouvre par produit, par vulnérabilité et par composant. Il est dans la console, sous « Signalements », et un email part à l'adresse du compte si elle est confirmée, un seul par passe, qui regroupe tous vos produits concernés.

Le catalogue KEV est une source américaine, sans portée juridique dans le CRA. Il atteste une exploitation constatée quelque part, pas nécessairement dans votre produit ni dans votre configuration. C'est pourquoi la suite commence par une qualification, la vôtre.

Un dossier s'ouvre aussi à la main, depuis la page « Signalements » d'un produit : pour un incident grave, qu'euvex ne peut pas détecter, ou une vulnérabilité absente du scan, dans votre propre micrologiciel par exemple.

L'obligation porte sur une vulnérabilité activement exploitée « contenue dans le produit » (art. 14, paragraphe 1). Le règlement définit la première comme « une vulnérabilité pour laquelle il existe des preuves fiables qu'elle a été exploitée par un acteur malveillant dans un système sans l'autorisation du propriétaire du système » (art. 3, point 42).

Les questions que le dossier ne tranche pas pour vous :

• Le composant est-il bien dans le produit mis sur le marché, dans la version touchée ?
• La partie vulnérable est-elle présente et atteignable dans votre configuration ?
• Quand en avez-vous eu connaissance, vous, et pas euvex ?

Si vous concluez qu'aucun signalement n'est dû, gardez la trace de votre raisonnement dans votre documentation, puis « Clore le dossier » : il reste consultable, et se rouvre. Cette qualification est une question de droit et de technique ; un conseil peut vous y aider, euvex ne la fait pas.

Les deux premières courent « sans retard injustifié et, en tout état de cause » dans ces délais. Le rapport final ne court jamais de la prise de connaissance : pour une vulnérabilité, il attend qu'une mesure existe, et une mesure d'atténuation suffit à le déclencher, pas seulement un correctif ; pour un incident, il part du dépôt de la notification.

La notification et le rapport final sont dus « à moins que les informations pertinentes n'aient déjà été communiquées ». Apprécier cette dispense vous revient : euvex ne l'affiche pas comme une case à cocher, pour ne pas inviter à sauter une étape.

Dans le dossier, chaque échéance porte sa date en UTC et son état : « À déposer », « Échéance dépassée », « Déposé », « Déposé hors délai », ou « Échéance non déclenchée » tant que son point de départ n'est pas connu. Jamais une date inventée.

Quand euvex ouvre un dossier, il y inscrit l'heure où lui l'a relevé : le dépôt ou le rattachement du scan, ou sa revérification quotidienne. Ce n'est pas forcément la vôtre. Si vous le saviez avant, par un avis de votre fournisseur ou un chercheur, corrigez la date : c'est elle qui commande l'alerte précoce et la notification.

Les dates se saisissent en UTC, et aucune ne peut être dans le futur. Pour une vulnérabilité, la date de la mesure de correction ou d'atténuation se saisit au même endroit, le jour où elle est disponible : c'est elle qui déclenche le rapport final.

La révision du scan où la vulnérabilité a été relevée est datée dans le dossier de scan, sous « Surveillance dans le temps » : deux documents distincts qui portent la même date.

euvex prépare un brouillon d'alerte précoce, et un champ par étape pour rédiger les suivantes. Ce que le texte demande au minimum :

Le dépôt se fait sur la plateforme unique de signalement de l'ENISA (art. 16), par le point de notification du CSIRT désigné comme coordinateur de l'État membre de votre établissement principal dans l'Union ; la notification est mise en même temps à la disposition de l'ENISA (art. 14, paragraphe 7). Le CSIRT peut vous demander un rapport intermédiaire (paragraphe 6).

Une fois l'étape déposée, cochez dans euvex « Déposé sur la plateforme unique », saisissez la date du dépôt en UTC, et enregistrez. Pour un incident, c'est cette date de notification qui fixe le rapport final.

Après avoir pris connaissance d'une vulnérabilité activement exploitée ou d'un incident grave, le fabricant en informe les utilisateurs touchés, et s'il y a lieu tous les utilisateurs, avec les mesures qu'ils peuvent prendre, s'il y a lieu dans un format structuré et lisible par machine. euvex ne le fait pas pour vous, et ne tient pas de liste de vos utilisateurs.

Le « Dossier imprimable » reprend les dates, les dépôts et les textes de chaque étape. Rangez-le avec votre documentation technique. « Clore le dossier » le marque clos sans l'effacer, et « Rouvrir le dossier » le rouvre.

Tant qu'un dossier est ouvert, le scan dont il dépend ne peut pas être effacé. Supprimer un compte ou un scan.

• Règlement (UE) 2024/2847, le Cyber Resilience Act. Article 3, point 42 ; article 14, paragraphes 1, 2, 4, 6, 7 et 8 ; article 16. L'art. 14 est applicable au 11 septembre 2026 (art. 71, paragraphe 2).
• Le catalogue KEV, ce qu'il couvre et ce qu'il ne couvre pas : nos sources.
• Toutes les échéances, avec leur article : les repères.