Signalée vs exploitée : la différence à 15 millions
L'alerte précoce de 24 heures n'est pas due pour chaque vulnérabilité qui atterrit dans votre boîte. Elle n'est due que lorsqu'il existe des preuves fiables que quelqu'un l'a exploitée, sans autorisation, dans un système réel. Tout tient à une ligne écrite : la qualification de l'événement.
Où l'obligation commence vraiment
Le Cyber Resilience Act ne vous demande pas de signaler des vulnérabilités. Il vous demande de signaler des vulnérabilités activement exploitées. La distinction n'est pas rhétorique : elle est écrite dans la définition elle-même à l'art. 3(42), et toute l'horloge de 24 heures de l'art. 14 y est suspendue.
Le déclencheur n'est pas l'existence d'un défaut, ni le fait que quelqu'un vous en ait parlé. Le déclencheur, ce sont des preuves fiables qu'un acteur malveillant l'a utilisée, dans un système, sans l'autorisation du propriétaire. La divulgation responsable d'un chercheur, un article académique, un scan automatique signalant une bibliothèque obsolète : rien de tout cela, à soi seul, ne démarre l'horloge.
Le risque court dans les deux sens
Signalez trop peu et vous violez l'obligation. Signalez tout, sans distinction, et vous payez un autre prix : vous perdez votre crédibilité auprès du CSIRT, vous noyez votre propre équipe dans les dépôts et vous brûlez les heures qu'il vous faudrait pour le seul signalement qui compte. Sur-signaler n'est pas un choix sûr par défaut. C'est une façon plus lente d'échouer.
L'issue aux deux risques est la même, et elle est sans éclat : une qualification motivée, faite vite et mise par écrit. Un « non » documenté est une défense que vous pouvez remettre à un inspecteur. Un « non » implicite — le signalement que vous avez silencieusement décidé de ne pas déposer — est indiscernable de la négligence quand quelqu'un demande, des mois plus tard, pourquoi rien n'a été envoyé.
Trois cas, et la ligne que vous écririez pour chacun
La qualification s'enseigne mieux par les exemples que par les définitions. En voici trois qui reviennent, avec le raisonnement exact que nous inscririons au registre — pas un verdict, mais la preuve et la conclusion qu'on en tire.
Cas 1 — E-mail d'un chercheur avec PoC
Un chercheur en sécurité écrit à votre adresse de divulgation. En pièce jointe, une preuve de concept qui déclenche de façon fiable un débordement de tampon sur le micrologiciel actuel. Aucune affirmation, aucune preuve, que quelqu'un l'ait utilisé contre un appareil client réel.
Signalée, pas exploitée. Ligne de registre : « Vulnérabilité confirmée, PoC fonctionnel reçu d'un chercheur externe le [date]. Aucune preuve d'exploitation dans un système sans autorisation. Art. 3(42) non rempli → pas d'alerte précoce de l'art. 14. Traitée dans le processus de divulgation coordonnée ; calendrier de remédiation ouvert. »
Cas 2 — Preuves de honeypot et de journaux
Votre honeypot capture une charge qui exploite le même débordement, et les journaux de production de deux installations clientes montrent le schéma de requêtes identique suivi d'une connexion sortante vers un hôte inconnu. Le comportement correspond à un usage actif dans la nature, contre des systèmes que personne n'a autorisés.
Exploitée. Déposez l'alerte précoce. Ligne de registre : « Preuves fiables d'exploitation sans autorisation : charge de honeypot + journaux de production concordants sur deux sites, [horodatages]. Art. 3(42) rempli → alerte précoce de l'art. 14 déposée auprès du CSIRT sous 24 h à compter de [heure de prise de connaissance]. Mise à jour à 72 h et rapport final planifiés. »
Cas 3 — Le scanner signale une dépendance obsolète
Un scanner de dépendances nocturne signale une CVE dans une vieille version d'une bibliothèque embarquée dans votre produit. Aucun signalement d'une vulnérabilité dans votre produit, aucun PoC contre votre build, aucun signe d'exploitation nulle part. Juste un numéro de version sous un seuil.
Ni l'un ni l'autre — mais documentez-le. Ligne de registre : « Signalement du scanner sur la bibliothèque [nom/version], CVE [id]. Pas encore confirmée comme vulnérabilité exploitable dans notre produit ; aucune preuve d'exploitation. Art. 3(42) non rempli → pas d'obligation de l'art. 14 aujourd'hui. Triage ouvert pour confirmer l'atteignabilité ; s'il s'agit d'un composant tiers, le signalement amont de l'art. 13(6) est à évaluer. »
Pourquoi « 15 millions » est dans le titre
Les obligations de signalement des art. 13 et 14 sont dans la tranche de sanction la plus élevée du règlement : jusqu'à 15 millions d'euros, ou 2,5 % du chiffre d'affaires annuel mondial total de l'exercice précédent, le montant le plus élevé étant retenu. Le chiffre n'est pas une tactique de peur. C'est le plafond que le législateur a attaché spécifiquement aux devoirs de gestion et de notification des vulnérabilités.
Ce qu'une autorité pèse, en pratique, ce n'est pas si vous avez deviné juste par hasard. C'est si vous aviez un processus et l'avez appliqué. Deux entreprises peuvent atteindre le même « non » — l'une par le silence, l'autre par une entrée de registre datée citant l'art. 3(42). Seule la seconde peut le montrer. La qualification n'est pas de la paperasse autour de la décision ; la qualification est la décision.
Le test en une ligne Existe-t-il des preuves fiables qu'un acteur malveillant l'a exploitée, dans un système, sans autorisation ? Si oui → alerte précoce sous 24 h. Si non → un « non » écrit et motivé.
Cet article décrit notre lecture du texte réglementaire et ne constitue pas un avis juridique.
Classe de risque