Toute personne qui découvre une vulnérabilité dans votre produit a besoin d'un moyen clair, accessible par un humain, pour la signaler, et votre équipe a besoin d'une politique écrite indiquant comment ce signalement est accusé réception, trié, corrigé et divulgué. Au titre du Règlement (UE) 2024/2847 (Cyber Resilience Act), cela signifie mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités (DCV), ainsi que publier un point de contact unique 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 vulnerability reporting et le cadre général de la vulnerability handling.
Synthèse
- La politique DCV est obligatoire. Rédigée, publiée, appliquée, sans seuil de taille. Détaillée dans Ce qu'exige réellement le CRA ci-dessous.
- Un point de contact unique est obligatoire. Les utilisateurs doivent pouvoir joindre un humain; 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 à l'ENISA. La DCV régit votre relation avec la personne qui signale; l'horloge réglementaire vers l'ENISA et le CSIRT coordinateur s'exécute en parallèle. Voir Coordination avec l'ENISA ci-dessous.
- La divulgation publique des vulnérabilités corrigées est obligatoire, avec une possibilité étroite de délai lorsque 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 sanctions sont traitées dans le guide enforcement. Voir pénalités et exécution pour l'échelle des amendes et les mesures de marché.
Les quatre points d'ancrage d'une posture DCV conforme au CRA : politique, contact, publication et renvoi vers l'enforcement.
Ce qu'exige réellement le CRA en matière de DCV
L'obligation DCV est courte : les fabricants doivent « 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 différemment :
| Exigence | Ce que cela signifie en pratique | Échec courant |
|---|---|---|
| Mettre en placePolitique documentée | Une politique écrite et accessible existe. Elle indique aux personnes qui signalent ce qui est dans le périmètre, comment signaler, quelle réponse attendre et quand la divulgation intervient. | Une habitude interne non documentée consistant à trier les e-mails reçus sur security@ ne remplit pas cette condition. |
| AppliquerProcessus opéré | 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 sont respectés en pratique. | Une politique promettant un accusé de réception sous 72 heures qui prend systématiquement trois semaines n'est pas appliquée. |
| Faciliter les signalementsCanal accessible | La politique facilite le partage d'informations sur les vulnérabilités par les personnes externes : une adresse de contact, un processus publié et un canal accessible par un humain qui n'est pas verrouillé derrière une connexion ou un chatbot. | Un portail accessible uniquement après connexion, une prise en charge automatisée seule ou un contact enfoui ne servent pas la finalité de l'obligation. |
| Ne pas pénaliser les personnes qui signalentNorme de recherche de bonne foi | Ce n'est pas littéralement une clause du CRA. Le CRA présente la DCV comme un signalement structuré et note que les programmes de bug bounty peuvent inciter aux signalements. ISO/IEC 29147 et le guide de bonnes pratiques de l'ENISA traitent la sphère de sécurité pour la recherche de bonne foi comme une caractéristique normale d'une politique DCV. | Se réserver le droit d'engager des poursuites contre une recherche de bonne foi dans le périmètre fait s'effondrer le canal de signalement, même si une adresse de contact existe. |
Pour le cadre général (les huit obligations numérotées dont la DCV est l'une), voir la vulnerability handling.
Le point de contact unique
La politique DCV ne fonctionne que si les personnes qui signalent peuvent trouver un vrai contact et disposer d'une voie humaine vers le fabricant. L'obligation de point de contact unique du CRA en fait trois exigences concrètes :
- Facilement identifiable. Le contact doit être facile à trouver pour les utilisateurs et figurer dans les instructions destinées à l'utilisateur accompagnant le produit. En pratique, cela signifie le rendre visible là où les utilisateurs cherchent, par exemple sur une page de sécurité ou de contact publique, et non l'enfouir dans une politique de confidentialité.
- 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. « Ces moyens n'étant pas limités aux outils automatisés » exclut une configuration où la seule adresse joignable est
security-noreply@ou un chatbot qui clôt 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 ni aucun format de publication spécifique. Il exige un canal de contact « facilement 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 reste préféré.
Au-delà de security.txt. Le standard « facilement identifiable » implique que le contact doit également figurer sur la page de support ou de contact du produit, dans les instructions destinées à l'utilisateur accompagnant le produit, dans la documentation développeur pour les produits API, et sur une page publique de politique DCV 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 » et à l'obligation « non limité aux outils automatisés » 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 | Échec 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 inapplicable sur sa face même. |
| Triage | Valider (reproductible sur une version supportée), évaluer la gravité (CVSS v3.1 ou v4.0 avec ajustements environnementaux, voir la severity scoring), apprécier l'exploitabilité (exploit connu, PoC public ou preuve d'exploitation réelle, qui ouvre la porte à l'escalade réglementaire) et délimiter les versions affectées via le SBOM. | Clôturer en « non reproductible » sans nommer la plage de versions testée. |
| Relation avec la personne qui signale | 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 une recherche dans le périmètre, ce qui fait s'effondrer 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, la raison la plus fréquente pour laquelle les politiques DCV paraissent non appliquées vues de l'extérieur. |
Coordination avec l'ENISA et les chercheurs externes
La prise en charge DCV et le signalement à l'ENISA sont des obligations distinctes avec des destinataires différents. La politique DCV régit votre relation avec la personne qui signale. La notification réglementaire régit votre obligation envers l'ENISA et le CSIRT coordinateur. Les deux s'exécutent en parallèle et se déclenchent différemment.
Quand un signalement DCV devient un déclencheur réglementaire. Les fabricants doivent notifier « toute vulnérabilité activement exploitée » via la SRP selon une cadence de 24 heures, 72 heures et 14 jours. Le déclencheur est « activement exploitée », pas « signalée ». Un signalement DCV accompagné d'une preuve de concept fonctionnelle n'est pas en lui-même un déclencheur réglementaire; il le devient lorsqu'il existe des preuves fiables qu'un acteur malveillant a exploité la vulnérabilité dans un système sans autorisation.
Les incidents graves suivent une cadence différente : 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 regroupez pas dans une présentation unique « 24h/72h/14j ». Voir le vulnerability reporting.
L'ENISA et les CSIRT désignés comme coordinateurs. La soumission se fait via la SRP en utilisant le point final électronique du CSIRT désigné comme coordinateur dans l'État membre de l'établissement principal du fabricant. Les fabricants peuvent recevoir les signalements directement, ou indirectement par l'intermédiaire d'un CSIRT désigné comme coordinateur au titre de la directive NIS2. Pour les modalités d'intégration à la SRP, voir ENISA SRP onboarding.
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. Une fois qu'une mise à jour de sécurité a été mise à disposition, les fabricants doivent partager et rendre publiquement accessibles une description de la vulnérabilité, des informations permettant aux utilisateurs d'identifier le produit affecté, l'impact, la gravité et des indications claires de remédiation. Un délai est autorisé « dans des cas dûment justifiés » lorsque les risques de sécurité liés à la publication l'emportent sur les bénéfices, mais uniquement « jusqu'à ce que les utilisateurs aient eu la possibilité d'appliquer le correctif adapté ».
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 le rapport final réglementaire est dû 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 la personne qui a signalé a accepté d'être nommée. 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é » est étroit. Il permet de retenir les détails publics jusqu'à ce que les utilisateurs puissent appliquer le correctif; il ne permet pas des correctifs silencieux jamais publiés. Un fabricant qui livre un correctif et ne décrit jamais ce qu'il corrige manque à l'obligation de divulgation publique, quelle que soit son intention.
Pièges courants
| Piège | Pourquoi cela ne satisfait pas au CRA |
|---|---|
| Menaces juridiques contre les chercheurs de bonne foi | Brise l'obligation d'« appliquer une politique de divulgation coordonnée des vulnérabilités » et dissuade le canal d'entrée qu'exige ce même devoir. |
| Aucun canal de contact public, uniquement un portail interne nécessitant une connexion | Ne satisfait pas à l'obligation de point de contact unique « facilement identifiable » ni à l'obligation de « fournir une adresse de contact ». |
Répondeur automatique security-noreply@ sans triage humain |
Le point de contact unique interdit de limiter la communication aux outils automatisés. |
| Accuser réception puis ne plus jamais répondre | La politique est « mise en place » mais pas « appliquée »; les deux sont obligatoires. |
| Clôturer les signalements en « refus de corriger » sans justification | Indiscernable de l'extérieur d'un signalement ignoré; les chercheurs escaladent en publiant. |
| Regrouper des correctifs de sécurité dans des versions fonctionnelles que les utilisateurs reportent | Les mises à jour de sécurité doivent être séparables des mises à jour fonctionnelles « lorsque cela est techniquement possible ». |
| Correction silencieuse sans avis | Manque à l'obligation de divulgation publique. |
| Traiter la prise en charge DCV comme la soumission à l'ENISA | Destinataires différents, obligations différentes. La DCV ne dispense pas du signalement réglementaire, et le signalement réglementaire 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 amendes liées aux délais d'alerte précoce de 24 heures, mais l'exonération ne touche que [ces amendes](/cra-compliance/penalties-and-enforcement), pas l'obligation sous-jacente, et ne s'étend pas aux moyennes entreprises. Un fournisseur de firmware de deux personnes a besoin d'une politique DCV publiée, d'un canal de contact et d'un processus de triage au même titre qu'un grand fournisseur.
`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 « facilement 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 destinées à l'utilisateur accompagnant le produit est également conforme. L'exigence absolue est un canal publié, fonctionnel et accessible par un humain; le format est un choix.
La prise en charge DCV peut-elle être le même canal que la soumission à l'ENISA ?
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 à l'ENISA est la notification réglementaire du fabricant à l'ENISA et au CSIRT coordinateur, effectuée via la plateforme unique de signalement. Un chercheur ne dépose 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 sérieuse).
Que se passe-t-il quand 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 la personne qui a signalé. Le processus réglementaire régit la relation avec l'ENISA et le CSIRT coordinateur : une alerte précoce de 24 heures, 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, ce qui peut être le moment où les preuves apportées par le chercheur rendent cette conclusion crédible. 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.
La politique DCV doit-elle offrir une sphère de sécurité juridique aux chercheurs ?
Non, le CRA n'exige pas de clause de sphère de sécurité explicite. Le CRA présente la DCV comme un processus structuré de signalement et mentionne les programmes de bug bounty comme moyen d'inciter aux signalements; il ne codifie pas de sphère de sécurité ni de réduction du risque juridique pour les chercheurs. La norme provient de la pratique du secteur plutôt que du règlement : 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 sphère de sécurité 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'obligation DCV.