Rédiger une politique de divulgation coordonnée des vulnérabilités
Sur cette page
Tôt ou tard, quelqu’un d’extérieur à votre entreprise trouvera une vulnérabilité dans votre produit : un chercheur en sécurité, l’équipe sécurité d’un client, un étudiant. Une politique de divulgation coordonnée des vulnérabilités lui dit comment la signaler, ce que vous ferez, et quand les détails pourront être rendus publics. Elle transforme une mauvaise surprise possible en coopération à l’issue connue.
Pourquoi le CRA l’exige
L’annexe I, partie II, point 5 du Cyber Resilience Act demande à tout fabricant de mettre en place et d’appliquer une politique de divulgation coordonnée des vulnérabilités, et de fournir une adresse de contact pour les signalements. La politique doit exister à la mise sur le marché du produit et pendant toute sa période d’assistance. Les intendants de logiciels ouverts doivent eux aussi avoir une politique de cybersécurité qui encourage le signalement des vulnérabilités.
Le CRA s’articule ici avec la directive NIS2 : chaque État membre a un CSIRT qui joue le rôle de coordinateur de la divulgation, et peut servir d’intermédiaire entre un auteur de signalement et un fabricant qui ne s’entendent pas. Votre politique doit en tenir compte.
Ce que doit dire la politique
La référence internationale est la norme ISO/IEC 29147 (divulgation des vulnérabilités), avec l’ISO/IEC 30111 pour le traitement interne. En pratique, une bonne politique tient sur une page et couvre :
Le périmètre
Quels produits, versions et services sont couverts, et ce qui ne l’est pas (par exemple les attaques physiques sur vos locaux, l’ingénierie sociale contre le personnel, les tests de déni de service sur la production).
Comment signaler
L’adresse (une boîte securite@ ou un formulaire), une clé de chiffrement si vous en proposez une, les langues que vous lisez, et ce que contient un signalement utile : produit et version touchés, étapes pour reproduire, impact, et comment joindre son auteur.
Vos engagements
Des délais concrets créent la confiance :
- un accusé de réception sous quelques jours ouvrés ;
- une première évaluation (confirmée ou non, gravité) sous une à deux semaines ;
- des nouvelles régulières jusqu’au correctif ;
- la publication d’un avis une fois un correctif disponible, en citant l’auteur du signalement s’il le souhaite.
Coordination et publication
Quand les détails peuvent devenir publics. Beaucoup d’organisations retiennent 90 jours après le signalement comme délai par défaut, prolongé d’un commun accord quand un correctif demande plus de temps, et raccourci quand la vulnérabilité est déjà exploitée. Le CRA impose aussi de publier les informations sur les vulnérabilités corrigées une fois une mise à jour de sécurité disponible, avec un report possible dans des cas dûment justifiés, le temps que les utilisateurs puissent l’appliquer.
L’engagement de non-poursuite
Si vous vous engagez à ne pas poursuivre les personnes qui cherchent de bonne foi et respectent la politique : pas d’extraction de données au-delà de ce qu’il faut pour montrer le problème, aucun tort aux utilisateurs, signalement rapide, confidentialité jusqu’à la publication. C’est un engagement juridique : faites-le relire par votre avocat, et gardez en tête qu’il n’engage ni les tiers ni les autorités.
Les récompenses
Si vous proposez une prime aux bogues ou seulement des remerciements. Dites-le clairement ; une politique sans prime est tout à fait normale pour une petite entreprise.
Les vulnérabilités exploitées
Ce qui se passe quand un signalement montre une exploitation active. Avec le CRA, cela peut lancer votre délai de signalement de 24 heures : les personnes qui lisent la boîte sécurité doivent savoir quand faire remonter l’alerte.
La publier
- Placez-la à une adresse stable de votre site, comme
/securite/politique-de-divulgation. - Pointez-y depuis votre fichier security.txt avec le champ
Policy. - Liez-la depuis la documentation du produit et les pages d’assistance.
- Gardez-la dans votre documentation technique comme preuve pour le CRA, avec la date de chaque version.
La faire vivre
Une politique n’est utile que si le processus derrière fonctionne :
- Faites suivre la boîte sécurité par au moins deux personnes, avec un accusé de réception automatique.
- Tenez un registre de chaque signalement : date de réception, état, décisions, publication.
- Reliez chaque vulnérabilité confirmée aux versions touchées, au correctif et à l’avis.
- Relisez la politique une fois par an, et quand vos produits ou votre équipe changent.
Vous pouvez rédiger une première version avec notre générateur de politique de divulgation gratuit, en français, en anglais ou en allemand.
Ce que fait Provetry
Avec les offres payantes, Provetry rédige votre politique de divulgation et votre security.txt à partir de vos réponses, y liste vos produits et leurs périodes d’assistance, fait relire le brouillon par un expert en sécurité certifié, et publie vos avis en CSAF une fois les correctifs sortis. Chaque version de la politique est inscrite dans votre journal de preuves.
Ce guide est une information générale, pas un conseil juridique.
Sources
- Règlement (UE) 2024/2847, le Cyber Resilience Act, article 13, article 24 et annexe I partie II
- Directive (UE) 2022/2555 (NIS2), article 12 sur la divulgation coordonnée des vulnérabilités
- ISO/IEC 29147 : divulgation des vulnérabilités et ISO/IEC 30111 : traitement des vulnérabilités
- CISA : modèle de politique de divulgation des vulnérabilités