L'Annexe I Partie II point 5 du Règlement sur la cyberrésilience de l'UE (Règlement (UE) 2024/2847) impose à chaque fabricant de mettre en place et d'appliquer une politique de divulgation coordonnée des vulnérabilités (DCV), et l'Article 13(17) exige un point de contact unique, accessible par un humain, pour les signalements de vulnérabilités. Aucune exemption de taille n'est prévue. Cette page traite du contenu obligatoire de la politique, de la manière de publier le canal de contact, et des interactions entre la DCV, le signalement au titre de l'Article 14 et le cadre général de l'Annexe I Partie II.
Synthèse
- La politique DCV est obligatoire au titre de l'Annexe I Partie II point 5 : rédigée, publiée, appliquée, sans seuil de taille.
- L'Article 13(17) impose un point de contact unique permettant aux utilisateurs de signaler des vulnérabilités ; le canal ne peut pas être limité à des outils automatisés.
security.txt(RFC 9116) est la convention de fait pour publier le contact, mais le CRA n'impose pas de format spécifique.- La DCV n'est pas le signalement de l'Article 14 : la DCV régit votre relation avec les chercheurs ; l'Article 14 est l'horloge réglementaire vers l'ENISA et le CSIRT coordinateur dès qu'une vulnérabilité est activement exploitée.
- La divulgation publique des vulnérabilités corrigées est obligatoire au titre de l'Annexe I Partie II point 4, avec une possibilité de délai dans les cas dûment justifiés où le risque de sécurité lié à la publication l'emporte sur le bénéfice jusqu'à ce que les utilisateurs aient eu la possibilité d'appliquer le correctif.
- Les amendes les plus élevées s'appliquent : jusqu'à €15 000 000 ou 2,5 % du chiffre d'affaires mondial annuel total au titre de l'Article 64(2), le montant le plus élevé étant retenu.
Les quatre points d'ancrage qui définissent une posture DCV conforme au CRA : l'obligation de politique, le devoir de contact, la convention de publication et le plafond des sanctions.
Ce qu'exige réellement le CRA en matière de DCV
L'Annexe I Partie II point 5 est courte. Texte du Règlement (UE) 2024/2847 :
(5) mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités ;
Cette seule phrase comporte quatre composantes opérationnelles, chacune pouvant faire défaut de manière différente en pratique :
Signifie qu'une politique rédigée et accessible existe. Une habitude interne non documentée consistant à trier les e-mails adressés à security@ ne remplit pas cette condition.
Signifie que la politique est opérée, pas seulement publiée. Les délais d'accusé de réception, les engagements de triage et les conditions de divulgation figurant dans le document doivent être respectés en pratique. Une politique promettant un accusé de réception sous 72 heures mais qui prend systématiquement trois semaines n'est pas appliquée.
Est la direction que la politique doit servir. L'Annexe I Partie II point 6 le rend explicite : les fabricants doivent « faciliter le partage d'informations sur les vulnérabilités potentielles », « notamment en fournissant une adresse de contact ».
Ne figure pas dans le texte du CRA. Le considérant 76 décrit la DCV comme un processus structuré de signalement et mentionne les programmes de récompense (bug-bounty) pour inciter aux signalements ; il ne codifie pas de protection juridique pour les chercheurs. La norme provient de la pratique du secteur (ISO/IEC 29147, guide de bonnes pratiques de l'ENISA), et non du règlement.
Pour le cadre général de l'Annexe I Partie II (les huit obligations numérotées dont la DCV est l'une d'elles), consultez la gestion des vulnérabilités CRA.
Le point de contact unique (Article 13(17))
L'Article 13(17) s'articule avec l'Annexe I Partie II point 5 et lui donne une forme opérationnelle. Texte :
- Aux fins du présent règlement, les fabricants désignent un point de contact unique permettant aux utilisateurs de communiquer directement et rapidement avec eux, notamment afin de faciliter le signalement de vulnérabilités affectant le produit comportant des éléments numériques.
Les fabricants s'assurent que le point de contact unique est aisément identifiable par les utilisateurs. Ils indiquent également ce point de contact unique dans les informations et instructions à l'intention des utilisateurs, telles que prévues à l'Annexe II.
Le point de contact unique doit permettre aux utilisateurs de choisir leurs moyens de communication préférés et ne pas limiter ces moyens à des outils automatisés.
Trois règles à intégrer :
- Aisément identifiable. Le contact doit être visible dans les informations produit, dans les instructions accompagnant le produit conformément à l'Annexe II, et sur le site web public. Un contact accessible uniquement en lisant la politique de confidentialité ne satisfait pas à cette exigence.
- Plusieurs canaux. « Choisir leurs moyens de communication préférés » signifie au moins deux. Une boîte mail
security@fonctionnelle accompagnée d'un formulaire web, avec une clé PGP disponible pour les signalements sensibles, constitue la base réaliste. - Pas de prise en charge uniquement automatisée. « Ne pas limiter ces moyens à des outils automatisés » exclut une configuration où la seule adresse joignable est
security-noreply@ou un chatbot clôturant les tickets sans examen humain.
Le CRA n'impose pas de séparer le support consommateur et la prise en charge des signalements de vulnérabilités, mais la plupart des fabricants opèrent une boîte de sécurité dédiée, acheminée vers l'équipe de sécurité produit, afin de distinguer la DCV du support général.
Publier votre politique DCV : security.txt et au-delà
Le CRA ne cite pas security.txt, RFC 9116 ou tout format de publication spécifique. Il exige un canal de contact « aisément identifiable » et une politique DCV « mise en place et appliquée ». Dans ces limites, le secteur a convergé vers security.txt comme convention de fait.
Champs RFC 9116 à publier :
| Champ | Objet |
|---|---|
Contact: |
Un ou plusieurs canaux de signalement. Au moins un est obligatoire. |
Expires: |
Date après laquelle le fichier est périmé. Obligatoire selon RFC 9116. |
Encryption: |
Clé publique (PGP, S/MIME) pour les signalements confidentiels. |
Acknowledgments: |
Page créditant les chercheurs pour les divulgations passées. |
Policy: |
Lien vers le document complet de politique DCV. |
Preferred-Languages: |
Langues dans lesquelles votre équipe de triage opère. |
Canonical: |
URL où le fichier est censé résider. |
Où l'héberger. L'emplacement conventionnel est https://example.com/.well-known/security.txt, servi en HTTPS. RFC 9116 accepte également https://example.com/security.txt comme solution de repli, mais .well-known est préféré.
Au-delà de security.txt. Le standard « aisément identifiable » implique que le contact doit également figurer sur la page de support ou de contact du produit, dans les instructions accompagnant le produit conformément à l'Annexe II, dans la documentation développeur pour les produits API, et sur une page de politique DCV publique que les chercheurs peuvent référencer.
Les fabricants qui opèrent des programmes de bug bounty ajoutent généralement HackerOne, Bugcrowd ou Intigriti comme canaux d'entrée supplémentaires. Ceux-ci satisfont à l'obligation de « faciliter les signalements » (Annexe I Partie II point 6) et à l'obligation « non limité à des outils automatisés » (Article 13(17)) uniquement s'ils sont ouverts à des chercheurs externes avec une réponse humaine. Un bounty privé, sur invitation uniquement, ne satisfait pas par lui-même à l'exigence de contact public et doit coexister avec un canal public.
Recevoir et trier les signalements de vulnérabilités
Une politique DCV est appliquée au travers d'un flux documenté de prise en charge et de triage. Les mécanismes ci-dessous ne sont pas prescrits par le CRA, mais c'est ainsi qu'une politique applicable se présente en pratique.
| Étape | Ce que fait une politique applicable | Défaut courant |
|---|---|---|
| Accusé de réception | Confirmer la réception dans le SLA publié. La base du secteur est 72 heures ; de nombreuses politiques s'engagent à 24 ou 48 heures pour les signalements de gravité élevée. Ce que vous publiez est ce que vous faites. | « Nous répondrons dans les meilleurs délais » est non exécutoire de par sa formulation. |
| Triage | Valider (reproductible sur une version supportée), évaluer la gravité (CVSS v3.1 ou v4.0 avec ajustements environnementaux, voir la notation de gravité), apprécier l'exploitabilité (exploit connu, PoC public ou preuve d'exploitation réelle, qui est la porte d'entrée vers l'Article 14), et délimiter les versions affectées via le SBOM. | Clôturer comme « non reproductible » sans mentionner la plage de versions testée. |
| Relation avec le chercheur | Publier trois éléments : une clause de sphère de sécurité pour la recherche de bonne foi dans le périmètre ; les éléments hors périmètre (données de production, ingénierie sociale, déni de service contre l'infrastructure en production) ; et les conditions de divulgation (fenêtre d'embargo, conditions de correction, crédit). Embargo typique : jusqu'à la livraison du correctif, avec une limite absolue de 90 jours. | Se réserver le droit d'engager des poursuites contre des recherches dans le périmètre, ce qui effondre le canal. |
| Clôture | Chaque signalement reçoit une réponse finale : corrigé (avec avis et CVE), doublon, refus de corriger (avec justification), ou hors périmètre. | Accuser réception une fois puis ne plus jamais répondre, raison la plus fréquente pour laquelle les politiques DCV ne semblent pas appliquées de l'extérieur. |
Coordination avec l'ENISA et les chercheurs externes
La prise en charge DCV et le signalement ENISA au titre de l'Article 14 sont des obligations distinctes ayant des destinataires différents. La politique DCV régit votre relation avec le chercheur. L'Article 14 régit votre notification réglementaire à l'ENISA et au CSIRT coordinateur. Ils s'exécutent en parallèle et se déclenchent différemment.
Quand un signalement DCV devient un déclencheur de l'Article 14. L'Article 14(1) impose aux fabricants de notifier « toute vulnérabilité activement exploitée » via la SRP. L'Article 14(2) fixe la cadence : alerte précoce de 24 heures, notification de 72 heures, et rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. Le déclencheur est « activement exploitée », et non « signalée ». Un signalement DCV accompagné d'une preuve de concept fonctionnelle n'est pas en lui-même un déclencheur de l'Article 14 ; il le devient lorsqu'il existe une conviction raisonnée qu'un acteur malveillant a utilisé la faille contre une cible réelle. Pour les incidents graves au titre de l'Article 14(3) et 14(4), la cadence est de 24 heures, 72 heures, puis un rapport final dans le mois suivant la notification de 72 heures. Les deux flux partagent les premières étapes et divergent sur le volet du rapport final. Ne les confondez pas dans une présentation unique « 24h/72h/14j ». Voir le signalement CRA Article 14.
L'ENISA et les CSIRT désignés comme coordinateurs. L'Article 14(7) exige la soumission via la SRP en utilisant le point de contact électronique du CSIRT désigné comme coordinateur dans l'État membre de l'établissement principal du fabricant. Le considérant 76 ancre le cadre général : les fabricants peuvent recevoir des signalements directement, ou indirectement par l'intermédiaire d'un CSIRT désigné comme coordinateur au titre de l'Article 12(1) de la Directive (UE) 2022/2555 (NIS2). Pour les modalités d'intégration à la SRP, voir l'intégration à la SRP ENISA.
Coordination avec les chercheurs. Lorsqu'un chercheur propose un embargo pendant que vous livrez un correctif, documentez la fenêtre convenue et respectez-la. Lorsque le chercheur refuse ou publie prématurément, votre politique DCV doit préciser comment vous réagissez, généralement en accélérant l'avis et le correctif.
Calendrier de divulgation publique
La divulgation publique d'une vulnérabilité corrigée n'est pas optionnelle au titre du CRA. L'Annexe I Partie II point 4 impose aux fabricants, « une fois qu'une mise à jour de sécurité a été mise à disposition », de « partager et rendre publiquement accessibles les informations relatives aux vulnérabilités corrigées, notamment une description des vulnérabilités, des informations permettant aux utilisateurs d'identifier le produit comportant des éléments numériques concerné, les impacts des vulnérabilités, leur gravité et des informations claires et accessibles aidant les utilisateurs à remédier aux vulnérabilités ». Le même point autorise un délai « dans les cas dûment justifiés, lorsque les fabricants estiment que les risques de sécurité liés à la publication l'emportent sur les avantages pour la sécurité », mais uniquement « jusqu'à ce que les utilisateurs aient eu la possibilité d'appliquer le correctif concerné ».
Fenêtres d'embargo. La norme de fait du secteur est de 90 jours entre le signalement et la divulgation publique, mesurés à compter de la date à laquelle le fabricant a été notifié pour la première fois. Project Zero, CERT/CC et la plupart des CSIRT nationaux opèrent sur ou à proximité de ce point de référence. Pour les vulnérabilités activement exploitées, la fenêtre se réduit généralement à quelques jours, car l'Article 14(2)(c) exige un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective.
Format de la divulgation publique. Un avis aligné sur le CRA doit comporter, au minimum, un identifiant CVE, une description claire, le produit et la plage de versions affectés, la gravité (score de base CVSS), l'impact, la remédiation, et un crédit lorsque le chercheur a accepté d'être nommé. CSAF (Common Security Advisory Framework) est le support lisible par machine que la plupart des CSIRT nationaux et la base de données de vulnérabilités de l'ENISA attendent.
Le délai « dûment justifié » du point 4 est limité. Il permet de retenir les détails publics jusqu'à ce que les utilisateurs puissent appliquer le correctif ; il ne permet pas des correctifs silencieux sans publication. Un fabricant qui livre un correctif sans jamais décrire ce qu'il corrige manque à l'obligation du point 4, quelle que soit son intention.
Erreurs courantes
| Erreur | Pourquoi elle ne satisfait pas au CRA |
|---|---|
| Menaces juridiques à l'encontre de chercheurs de bonne foi | Brise « appliquer une politique de divulgation coordonnée des vulnérabilités » (Annexe I Partie II point 5) et dissuade le canal d'entrée qu'exige le point 6. |
| Absence de canal de contact public, uniquement un portail interne nécessitant une connexion | Ne satisfait pas à « aisément identifiable » de l'Article 13(17) ni à « en fournissant une adresse de contact » de l'Annexe I Partie II point 6. |
Répondeur automatique security-noreply@ sans triage humain |
L'Article 13(17) interdit de limiter la communication à des outils automatisés. |
| Accusé de réception sans jamais donner suite | La politique est « mise en place » mais pas « appliquée ». L'Annexe I Partie II point 5 exige les deux. |
| Clôture des signalements comme « refus de corriger » sans justification | Indiscernable de l'extérieur d'une ignorance du signalement ; les chercheurs escaladent en publiant. |
| Regrouper les correctifs de sécurité dans des versions fonctionnelles que les utilisateurs reportent | Viole l'Annexe I Partie II point 2 : les mises à jour de sécurité doivent être séparables des mises à jour fonctionnelles « lorsque c'est techniquement réalisable ». |
| Correction silencieuse sans avis | Viole l'obligation de divulgation publique de l'Annexe I Partie II point 4. |
| Traiter la prise en charge DCV comme la soumission ENISA au titre de l'Article 14 | Destinataires différents, obligations différentes. La DCV ne dispense pas de l'Article 14, et l'Article 14 ne dispense pas de la DCV. |
Foire aux questions
Les petits fabricants ont-ils besoin d'une politique DCV au titre du CRA ?
Oui. L'obligation de politique DCV ne comporte aucun seuil de taille. Elle s'applique à tout fabricant qui met sur le marché de l'UE un produit comportant des éléments numériques, sans considération d'effectif ou de chiffre d'affaires. Les microentreprises et les petites entreprises bénéficient d'une exonération restreinte concernant les délais de 24 heures de l'Article 14 au titre de l'Article 64(10)(a), qui couvre à la fois l'Article 14(2)(a) pour les vulnérabilités activement exploitées et l'Article 14(4)(a) pour les incidents graves. L'exonération ne touche que ces amendes, et non l'obligation sous-jacente, et ne s'étend pas aux moyennes entreprises. (Annexe I Partie II point 5 ; Article 64(10)(a) ; Article 3(19).)
`security.txt` est-il obligatoire au titre du CRA ?
Non. Le CRA ne cite pas security.txt ni RFC 9116. Il impose un point de contact unique « aisément identifiable » et une adresse de contact pour le signalement des vulnérabilités. security.txt est la convention de fait utilisée pour satisfaire à ces obligations car c'est ce que les scanners automatisés et la plupart des chercheurs vérifient en premier, mais un contact publié de façon bien visible sur une page de sécurité publique et dans les instructions de l'Annexe II est également conforme. L'exigence absolue est un canal publié, fonctionnel et accessible par un humain ; le format est un choix. (Article 13(17) ; Annexe I Partie II point 6 ; RFC 9116.)
Le canal de prise en charge DCV peut-il être le même que la soumission ENISA au titre de l'Article 14 ?
Non. Ce sont des destinataires différents et des obligations différentes. La prise en charge DCV est le canal par lequel les chercheurs et utilisateurs externes signalent des vulnérabilités au fabricant. La soumission au titre de l'Article 14 est la notification réglementaire du fabricant à l'ENISA et au CSIRT coordinateur, effectuée via la Plateforme de signalement unique ENISA. Un chercheur ne soumet pas à la SRP ; c'est le fabricant qui le fait. Confondre les deux conduit soit à ne pas accuser réception d'un chercheur (manquement à la DCV), soit à ne pas notifier l'ENISA lorsque l'exploitation est confirmée (exposition à la sanction maximale). (Article 14(1) et 14(7) ; Article 16 ; Article 64(2).)
Que se passe-t-il lorsqu'un chercheur externe signale une vulnérabilité activement exploitée ?
Deux horloges démarrent en parallèle. Le processus DCV régit la relation avec le chercheur : accuser réception, trier, convenir d'un embargo, livrer un correctif, publier un avis, créditer le chercheur. Le processus de l'Article 14 régit la relation avec le régulateur : une alerte précoce de 24 heures à l'ENISA et au CSIRT coordinateur, une notification de 72 heures, et un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. L'horloge de 24 heures démarre lorsque le fabricant prend conscience que l'exploitation est active ; attendre une certitude judiciaire fera manquer l'échéance. Les deux processus s'exécutent en parallèle et se terminent sur des supports différents. (Article 14(1) et 14(2) ; Annexe I Partie II point 5.)
La politique DCV doit-elle offrir une sphère de sécurité juridique aux chercheurs ?
Non, le CRA n'exige pas de clause de protection juridique explicite. Le considérant 76 décrit la divulgation coordonnée des vulnérabilités comme un processus structuré de signalement et mentionne les programmes de récompense (bug-bounty) pour inciter aux signalements ; il ne codifie pas de protection juridique ni de réduction du risque légal pour les chercheurs. La norme provient de la pratique du secteur : ISO/IEC 29147, le guide de bonnes pratiques de l'ENISA et la plupart des recommandations des CSIRT nationaux convergent vers une clause écrite de protection juridique couvrant la recherche de bonne foi dans le périmètre publié. Une politique qui se réserve le droit d'engager des poursuites contre la recherche dans le périmètre fait s'effondrer le canal et échoue, en pratique, à la moitié « appliquer » de l'Annexe I Partie II point 5. (Considérant 76 ; ISO/IEC 29147 ; guide de bonnes pratiques CVD de l'ENISA.)