CVD : rédiger et publier une politique de divulgation coordonnée des vulnérabilités

Un document public que la majorité des fabricants n'ont jamais rédigé

Avant le Cyber Resilience Act, aucun cadre réglementaire produit européen n'imposait au fabricant de produits connectés de publier un canal public permettant à des tiers de lui signaler des vulnérabilités. Certains acteurs du secteur IT avaient adopté cette pratique volontairement, s'inspirant des usages de la communauté de la recherche en sécurité. Dans l'industrie de la sécurité électronique, de la domotique, ou de l'équipement industriel connecté, c'était l'exception.

Le CRA change cela structurellement. L'Annexe I Partie II, point 1 impose aux fabricants d'établir et appliquer une politique de divulgation des vulnérabilités coordonnée. Cette exigence est formellement une exigence essentielle, au même titre que les exigences de conception de l'Annexe I Partie I. Son absence est un constat de non-conformité. Elle doit être en place avant la mise sur le marché des produits soumis à la conformité CRA complète (11 décembre 2027) mais, point souvent sous-estimé, elle doit être opérationnelle dès septembre 2026 pour soutenir les obligations de notification de l'Article 14.

Ce point mérite d'être précisé. L'Article 14 impose à tout fabricant qui a connaissance d'une vulnérabilité activement exploitée dans l'un de ses produits de notifier l'ENISA dans les 24 heures. La question est : comment un chercheur en sécurité, un intégrateur, ou un utilisateur avancé qui découvre une vulnérabilité dans votre produit va-t-il vous en informer, si aucun canal public de signalement n'existe ? La CVD est l'infrastructure de réception sans laquelle l'horloge de l'Article 14 ne peut jamais démarrer dans les délais légaux: parce que la notification n'arrivera pas ou arrivera par des canaux imprévisibles (réseaux sociaux, CERT nationaux, publication directe).

CVD et procédure interne : deux documents distincts

Une confusion fréquente dans les projets CRA consiste à traiter la CVD et la procédure interne de traitement des vulnérabilités comme un seul document. Ce sont deux documents différents, avec des audiences différentes, des fonctions différentes, et des niveaux de confidentialité différents.

La politique CVD est un document public. Elle s'adresse aux chercheurs en sécurité, aux intégrateurs, aux clients, aux partenaires, à tout tiers susceptible de découvrir une vulnérabilité dans vos produits. Elle communique les engagements du fabricant vis-à-vis des signalements externes. Elle est publiée sur le site web du fabricant et référencée dans le fichier security.txt. Elle ne décrit pas les processus internes : faire figurer dans un document public les noms des équipes responsables, les outils utilisés, les délais de développement des correctifs, serait une exposition opérationnelle non souhaitable.

La procédure interne de traitement des vulnérabilités est un document opérationnel confidentiel. Elle définit qui fait quoi en interne lorsqu'un signalement arrive (RACI, délais Art. 14, critères de sévérité, escalade). Elle est la base de la note de service désignant le coordinateur PSIRT: une seule personne peut suffire selon la taille de l'organisation, mais elle doit être formellement désignée, avec une astreinte définie pour les signalements critiques entrant en dehors des heures ouvrées compte tenu du délai de 24 heures de l'Article 14. Sa structure est définie par la prEN 40000-1-3 (Phase [PRE-1]) et l'EN ISO/IEC 30111. La procédure de notification réglementaire (notification à l'ENISA et à l'ANSSI dans les délais de l'Article 14) est distincte et également couverte par la prEN 40000-1-3, qui en définit le formalisme et les critères de déclenchement.

Publier la procédure interne à la place d'une vraie CVD expose les processus opérationnels sans apporter les garanties que les chercheurs attendent d'une politique CVD sérieuse. Et inversement, avoir une CVD publiée sans procédure interne qui la soutiende crée des engagements publics impossibles à honorer, une source de risque juridique et de réputation.

Ce que la CVD doit contenir : le minimum réglementaire et recommandé

La prEN 40000-1-3 (Phase [PRE-2]) précise les exigences applicables à la politique CVD. En combinaison avec l'EN ISO/IEC 29147 (divulgation des vulnérabilités) qui sert de cadre de référence, les éléments suivants doivent figurer dans la CVD :

Canal de contact

Exigence obligatoire ([PRE-2-RQ-02]) : au moins un mécanisme de contact doit être indiqué. Dans la pratique, le minimum opérationnel est une adresse email dédiée, non nominative: security@domaine.com ou vuln@domaine.com. Un formulaire web est recommandé en complément, car il permet de structurer les signalements et de réduire le bruit. L'adresse email doit être surveillée pendant les heures ouvrées et une astreinte doit être définie pour les signalements critiques. Une adresse email publiée sans surveillance active est pire qu'aucune adresse : elle crée une attente de réponse qui ne sera pas honorée.

Périmètre couvert

La CVD doit préciser quels produits et quelle durée d'assistance sont couverts. Si des produits legacy sont explicitement exclus, parce que leur période d'assistance est épuisée et que le fabricant a formellement documenté cette exclusion (Article 14 CRA), cela doit être indiqué. Cette transparence évite que des chercheurs investissent du temps sur des produits pour lesquels aucun correctif ne sera produit, et qu'ils publient directement en l'absence de réponse.

Accusé de réception et délais de réponse

Exigence obligatoire ([PRE-2-RQ-03]) : les attentes en matière de communication doivent être indiquées. La CVD doit préciser le délai dans lequel le fabricant accuse réception d'un signalement (pratique courante : 5 jours ouvrés) et le délai dans lequel une réponse substantielle est fournie (confirmation de validité et plan de remédiation). Ces délais deviennent contractuellement opposables aux chercheurs : ils peuvent les invoquer pour justifier une divulgation anticipée si le fabricant ne les respecte pas.

Période d'embargo et stratégie de divulgation

La période d'embargo est la durée pendant laquelle la vulnérabilité est maintenue confidentielle pendant le développement du correctif. La pratique courante dans l'industrie est de 90 jours, avec possibilité de prolongation en cas de complexité technique documentée. La CVD doit indiquer : la durée de l'embargo par défaut, les conditions dans lesquelles il peut être prolongé ou réduit, et ce qui se passe en cas de divulgation prématurée par le reporter. Elle doit également préciser si le fabricant publie des bulletins de sécurité publics, coordonne avec des CERT nationaux (ANSSI en France), ou notifie via la base EUVD.

Clause de non-poursuite (safe harbour)

C'est l'élément juridiquement le plus sensible de la CVD, et paradoxalement celui qui conditionne le plus la qualité des signalements reçus. Un chercheur en sécurité qui découvre une vulnérabilité dans votre produit prend un risque légal s'il doit procéder à des tests sur votre infrastructure ou sur votre firmware pour la caractériser. Sans engagement explicite du fabricant de ne pas poursuivre légalement un chercheur agissant de bonne foi et dans le périmètre défini par la CVD, les chercheurs sérieux ne signalent pas, ils publient directement, ou passent par des intermédiaires (CERT, journalistes). Le premier cas déclenche l'Article 14 par une voie non maîtrisée ; le second dilue la maîtrise du fabricant sur la divulgation.

En France, la clause de non-poursuite doit être évaluée à l'aune de l'Article 323-1 du Code pénal (accès frauduleux à un système de traitement automatisé de données) et de l'Article L.122-24 du Code de la propriété intellectuelle (restrictions à l'ingénierie inverse). La formulation de cette clause ne peut pas être générique: elle doit definir précisément le périmètre (produits concernés, types de tests autorisés, conditions de bonne foi) pour être opposable. C'est un engagement de 2 à 3 jours pour un avocat spécialisé en droit du numérique, et un investissement qui doit être budgété dans le projet CRA. Il est commun aux chantiers CVD et PSIRT et ne doit pas être réalisé deux fois.

Le security.txt : point d'entrée opérationnel de la CVD

Le fichier security.txt est défini par la RFC 9116 (IETF, mai 2022). Il s'agit d'un fichier texte standard, déposé à l'URL /.well-known/security.txt sur les domaines web du fabricant, qui centralise les informations de contact en matière de sécurité dans un format lisible par les humains et les outils automatisés.

Les champs minimaux obligatoires selon la RFC 9116 sont :

• Contact: — l'URL ou l'adresse email de signalement (champ multiple possible) ;
• Expires: — la date limite de validité du fichier (au-delà de laquelle son contenu ne doit plus être considéré comme à jour).

Les champs recommandés pour une CVD CRA-conforme :

• Policy: — URL de la politique CVD complète ;
• Preferred-Languages: — langues dans lesquelles le fabricant peut traiter les signalements ;
• Acknowledgments: — URL d'une page de remerciements aux chercheurs ayant signalé des vulnérabilités (pratique de hall of fame, optionnelle mais recommandée comme signal positif à la communauté).

Le fichier peut être signé numériquement via OpenPGP si le fabricant dispose d'une clé de sécurité. La signature augmente la crédibilité du fichier pour les chercheurs avancés mais n'est pas une exigence normative.

Un point de déploiement souvent négligé : le security.txt doit être déployé sur tous les domaines associés à un produit — le site corporate du fabricant, mais aussi les domaines de services cloud, les domaines d'applications mobiles, les portails installateurs. Un chercheur qui découvre une vulnérabilité dans un service cloud d'un système d'alarme commencera par chercher le security.txt sur le domaine du service cloud, pas nécessairement sur le site corporate du fabricant.

Ce qui rend la CVD opérationnelle plutôt que décorative

Une politique CVD publiée sans infrastructure interne opérationnelle est une source de risque, pas une protection. Elle crée des engagements publics (délais d'accusé de réception, délais de réponse, période d'embargo) qui seront visiblement non respectés lors du premier signalement réel. Cela donne aux chercheurs une justification documentée pour une divulgation anticipée, et aux autorités de surveillance une base de non-conformité à l'Annexe I Partie II.

L'infrastructure opérationnelle minimale qui doit soutenir la CVD au 11 septembre 2026 comprend :

• Une boîte de réception surveillée derrière le canal de contact: un ticket system ou une boîte email avec SLA de traitement (pas de signalement qui reste sans réponse plus de 5 jours ouvrés) ;
• Une procédure de triage interne — qui évalue si un signalement est valide, quelle est sa sévérité (en utilisant par exemple un scoring CVSS), et qui en R&D en est responsable ;
• Un chemin d'escalade clair pour les signalements qui atteignent le seuil de l'Article 14 : « vulnérabilité activement exploitée » ou « incident grave ». Dès réception d'un tel signalement, ou dès que le triage l'identifie comme tel, l'horloge de 24 heures de l'Article 14 démarre. Il n'y a pas de marge entre la réception et la décision d'escalade ;
• Des modèles de réponse — accusé de réception initial, réponse de triage, réponse de clôture (correctif publié ou rejet documenté) ;
• Un registre des signalements — requis pour la documentation du dossier technique CRA (Annexe VII §2b — description du processus de gestion des vulnérabilités) et pour pouvoir démontrer le respect des délais en cas de contrôle.

La notion de « prise de connaissance » au sens de l'Article 14

L'Article 14 CRA déclenche les obligations de notification à partir du moment où le fabricant a connaissance d'une vulnérabilité activement exploitée ou d'un incident grave. La CVD est l'un des vecteurs possibles de cette prise de connaissance, mais pas le seul. La veille sur l'EUVD et la corrélation avec le SBOM constituent un deuxième vecteur actif, indépendant des signalements externes.

Un fabricant qui reçoit un signalement dans sa boîte security@, l'archive sans triage pendant 3 jours, puis découvre que la vulnérabilité est activement exploitée, a violé son obligation de notification : le délai de 24 heures commence à la réception du signalement, pas au moment où le triage l'identifie comme critique. Cette interprétation découle de la prEN 40000-1-3 ([RCP] Réception) lue en combinaison avec l'Article 14 CRA : la réception d'un signalement constitue une prise de connaissance initiale, même si l'évaluation complète n'est pas encore réalisée.

En pratique, cela signifie que la procédure de triage doit être adossée à un SLA d'analyse initiale (48 heures au maximum pour une première évaluation de sévérité, quelle que soit la complexité) afin que les signalements qui pourraient declencher l'Article 14 soient identifiés avant l'expiration du délai de 24 heures.

Calendrier de mise en place

Un calendrier réaliste pour une PME qui démarre le projet CVD sans infrastructure existante :

• Semaine 1–2 : rédaction de la CVD v0 (brouillon interne, non publié):  structure, périmètre, délais, clause de non-poursuite en attente de validation ;
• Semaine 3–6 : validation juridique de la clause de non-poursuite par avocat spécialisé droit du numérique ;
• Semaine 3–6 (parallèle) : création de la boîte email security@, mise en place du système de ticketing ou d'un alias redirigé, rédaction de la procédure interne v0 et du RACI PSIRT ;
• Semaine 6–8 : finalisation de la CVD post-validation juridique, déploiement du security.txt sur les domaines concernés, mise en ligne de la CVD sur le site web ;
• Avant le 11 septembre 2026 : CVD publiée, canal surveillé opérationnel, procédure interne activable, inscription ENISA effectuée.

Conclusion

La CVD n'est pas un document de communication. C'est un engagement public juridiquement structurant, qui appelle une infrastructure interne pour être honoré. Sa rédaction est en elle-même rapide: quelques jours. La difficulté est de s'assurer qu'elle est soutenue par une organisation capable de répondre dans les délais annoncés et de déclencher les notifications réglementaires quand la situation le commande.

L'absence de CVD au 11 septembre 2026 laisse le fabricant sans infrastructure de réception des signalements, ce qui signifie que des vulnérabilités activement exploitées dans ses produits seront portées à sa connaissance par des voies non maîtrisées, après que la fenêtre de 24 heures de l'Article 14 sera déjà passée. Ce n'est pas une hypothèse abstraite : c'est le scénario que l'Article 14 est précisément conçu pour prévenir.