Divulgation coordonnée des vulnérabilités (CVD)
Comment signaler, recevoir et coordonner les vulnérabilités de sécurité, avec des exemples de politiques.
La divulgation coordonnée des vulnérabilités (coordinated vulnerability disclosure, CVD) est un terme de sécurité informatique. Il décrit la manière dont les personnes peuvent partager des signalements sur des problèmes de sécurité. Par exemple : rapports de bogues, risques d'intrusion, alertes de piratage, fuites de données, piratages de sites web, etc.
Traductions : العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文
Sommaire :
- Introduction
- Qu'est-ce que la divulgation coordonnée des vulnérabilités ?
- Étape 1 : Signaler le problème
- Étape 2 : Garantir les contacts
- Étape 3 : Travailler de bonne foi
- Vérifier la réussite
- Orientation
- Cas particuliers
- Divulgation coordonnée des vulnérabilités et divulgation responsable
- Suivi
Politiques :
- CERT : Politique de divulgation des vulnérabilités
- GitLab : Politique de divulgation responsable
- Salesforce : Politique de divulgation responsable
- The Atlantic : Divulgation responsable des vulnérabilités de sécurité
- Walmart : Politique de divulgation responsable
- Zendesk : Politique de divulgation responsable
Introduction
Ce document explique la divulgation coordonnée des vulnérabilités de manière à aider les personnes à travailler ensemble.
Objectifs du document :
Aider les personnes qui découvrent des problèmes de sécurité et souhaitent les signaler.
Aider les représentants des entreprises à comprendre les besoins, les objectifs, les pratiques et les cas particuliers de la divulgation responsable.
Inclure des exemples de politiques de divulgation coordonnée des vulnérabilités dans le dossier du dépôt.
Nous accueillons les demandes de fusion (pull requests), les tickets GitHub ou les courriels à security@joelparkerhenderson.com.
Qu'est-ce que la divulgation coordonnée des vulnérabilités ?
La divulgation coordonnée des vulnérabilités décrit trois étapes lorsque quelqu'un découvre un problème de sécurité (comme un bogue logiciel) et souhaite le signaler au producteur (comme l'entreprise qui fabrique le logiciel).
Étapes :
La personne qui a découvert le problème le signale en privé et de bonne foi au producteur.
Le producteur s'efforce de bonne foi de protéger les utilisateurs et de traiter le problème.
Après un délai convenu, le problème de sécurité est rendu public.
Étape 1 : Signaler le problème
L'étape 1 revient à la personne qui a découvert le problème : le signaler en privé et de bonne foi.
Bien : la personne envoie les informations pertinentes au producteur, par exemple par courriel à l'adresse de sécurité du producteur (généralement « security@example.com ») ou via un formulaire sur le site web du producteur (généralement « https://www.example.com/security »).
Mal : publier le signalement sur un blog public, alerter les médias, menacer, ou tenter de vendre le problème de sécurité à des pirates, etc.
Conseil : la personne qui a découvert le problème peut choisir de rester anonyme ; le producteur peut aussi choisir de rester anonyme.
Si vous le souhaitez, continuez à suivre le problème.
Bien : ouvrir des canaux de communication, fournir des informations de suivi ou surveiller la situation.
Mal : oublier le problème.
Conseil : la personne peut choisir d'aider ou non, de rester en contact ou non, et aussi de modifier l'arrangement si les circonstances changent.
Si vous le souhaitez, divulguez le problème à d'autres personnes.
Bien : attendre le délai précisé puis rendre public, par exemple en publiant les informations pertinentes sur un site d'actualités de sécurité, en contactant des chercheurs en sécurité tiers concernés, ou en annonçant le problème sur un réseau social public, etc.
Mal : ne pas divulguer le problème à d'autres, sauf si vous estimez que cela ferait courir un risque supérieur à la normale à vous-même ou à d'autres.
Conseil : si les circonstances changent, par exemple en cas de découverte d'un risque plus élevé ou d'une exploitation active dans la nature, la personne peut divulguer le problème plus tôt.
Étape 2 : Garantir les contacts
L'étape 2 revient au producteur : garantir que les contacts sont viables.
Bien : le producteur publie une adresse de courriel de contact sécurité (par convention « security@example.com ») et idéalement une clé de chiffrement de courriel sécurisé.
Bien : le producteur publie une page web de contact sécurité (par convention « https://www.example.com/security ») et la rend idéalement facile à trouver, par exemple via le pied de page du site, le plan du site et la recherche.
Mal : le producteur ne fournit ni adresse de courriel ni page web, ou ne les rend pas faciles à trouver.
Garantir les capacités du personnel.
Bien : le producteur forme le personnel d'assistance à ce qu'il faut faire en cas de demande de sécurité, par exemple comment répondre avec les coordonnées, ou comment transmettre la demande à la bonne équipe interne.
Bien : le producteur vérifie périodiquement que ces capacités fonctionnent.
Mal : le producteur ne forme pas ou ne vérifie pas.
Répondre à la personne qui a découvert le problème dans les délais.
Si la personne ne précise pas de délai, utilisez un jour ouvrable, car c'est la norme du secteur et la meilleure pratique actuelle.
Si la personne pose des questions, répondez-y. C'est particulièrement important si elle demande l'autorisation de tester. Veillez à ce que toutes les réponses soient claires et directes.
Répondre via un contact de sécurité autorisé et/ou un processus de sécurité autorisé.
Bien : une réponse depuis une adresse de courriel propre à la sécurité, comme « security@example.com ».
Par exemple, c'est mal : une réponse depuis une adresse généraliste, comme « help@example.com », ou de la part de quelqu'un qui n'est pas un professionnel de la sécurité autorisé.
Confirmer à la personne que le problème est reconnu comme un signalement de sécurité.
Bien : un vocabulaire propre à la sécurité, comme « Notre équipe de sécurité a bien reçu votre signalement de divulgation responsable », ou « Notre processus de sécurité comprend les étapes suivantes », ou « Vos informations figurent désormais dans notre outil de suivi de sécurité sous le numéro XYZ », etc.
Mal : un vocabulaire généraliste, comme « Nous apprécions votre fidélité », ou « Nous prenons la sécurité au sérieux », ou un vocabulaire qui se défausse, comme « Nous avons transmis votre courriel à un autre service », etc.
Étape 3 : Travailler de bonne foi
L'étape 3 revient conjointement à la personne qui a découvert le problème et au producteur : travailler de bonne foi.
Comprenez que la divulgation coordonnée des vulnérabilités décrit un processus de bonne foi.
L'objectif n° 1 est la bonne foi pour aider les utilisateurs à se protéger des risques de sécurité.
L'objectif n° 2 est la bonne foi pour traiter le problème de sécurité.
La personne et/ou le producteur peuvent choisir de bonne foi d'impliquer d'autres personnes de la sécurité, par exemple en contactant d'autres chercheurs en sécurité pour aider à traiter le problème.
Comprenez que la divulgation coordonnée des vulnérabilités ne crée aucune obligation.
La personne et/ou le producteur peuvent se retirer à tout moment, pour n'importe quelle raison, avec ou sans préavis. Il est courtois de tenir toutes les personnes concernées informées et à jour, mais ce n'est pas toujours possible, pratique ou souhaitable.
La divulgation coordonnée des vulnérabilités ne crée aucun accord juridique. Si la personne et le producteur ont déjà un accord juridique, nous suggérons que toutes les personnes concernées consultent les juristes appropriés ; n'utilisez pas ce document comme un conseil juridique.
Comprenez que la divulgation coordonnée des vulnérabilités vise une bonne communication et rejette les menaces.
La divulgation coordonnée des vulnérabilités est à son meilleur lorsque tous comprennent que l'objectif n° 1 est d'aider les utilisateurs à se protéger des risques de sécurité et l'objectif n° 2 de traiter le problème de sécurité.
La divulgation coordonnée des vulnérabilités rejette toute forme de menace de représailles, d'intimidation, de suspension, de révocation, d'extorsion, de charge de suivi ou de culpabilisation de la victime.
Comprenez que la divulgation coordonnée des vulnérabilités peut signifier des choses différentes selon les personnes.
La personne et le producteur peuvent avoir une compréhension différente de la divulgation coordonnée des vulnérabilités, et ces compréhensions peuvent ne pas coïncider. La bonne foi inclut que tous le comprennent.
Certains producteurs publient des politiques de divulgation coordonnée des vulnérabilités. Elles peuvent constituer une orientation utile. Si la personne choisit un autre type de divulgation coordonnée, ou a une autre compréhension de la divulgation responsable, c'est tout à fait acceptable.
Comprenez que, généralement, la personne qui a découvert le problème rend service à l'éditeur.
Généralement, elle n'a besoin de la permission de personne pour publier des vulnérabilités.
Généralement, ses informations aident l'éditeur.
Vérifier la réussite
Une fois le problème résolu, le producteur doit vérifier la réussite.
Toutes les personnes et tous les processus ont-ils géré la divulgation avec succès ? Si oui, tant mieux. Sinon, envisagez une recherche a posteriori, comme une analyse des causes profondes (RCA), des rapports post-mortem, des diagrammes d'Ishikawa ou une analyse causale fondée sur la théorie des systèmes (CAST).
Les problèmes en suspens sont-ils triés et suivis ?
Le producteur et la personne comprennent-ils tous deux ce qu'il faut faire pour les étapes suivantes ? C'est particulièrement important en cas de divulgations coordonnées ultérieures.
Orientation
Les orientations relatives à la divulgation coordonnée des vulnérabilités peuvent venir de nombreux domaines, comme les experts en éthique, les défenseurs du droit, les attentes raisonnables du grand public, etc.
Si vous cherchez une orientation, ces trois domaines, tous décrits ci-dessous, pourraient vous intéresser.
Bon samaritain
Devoir de secours
Devoir de diligence
Bon samaritain
Wikipédia : Loi du bon samaritain
Les lois du bon samaritain offrent une protection juridique aux personnes qui apportent une aide raisonnable à celles qui sont, ou qu'elles croient être, blessées, malades, en danger ou autrement incapables d'agir. Cette protection vise à réduire l'hésitation des témoins à aider, par crainte d'être poursuivis.
Devoir de secours
Un devoir de secours est un concept décrivant une situation dans laquelle une partie peut être tenue responsable de ne pas être venue au secours d'une autre partie en danger. Un devoir de secours peut avoir des domaines moraux et/ou juridiques.
Devoir de diligence
Wikipédia : Devoir de diligence
Un devoir de diligence est l'obligation de respecter une norme de précaution raisonnable lors de tout acte susceptible de nuire de manière prévisible à autrui. Un devoir de diligence peut avoir des domaines moraux et/ou juridiques. Certains aspects à considérer sont : la prévisibilité du préjudice ou de la blessure, l'ampleur possible du préjudice ou de la blessure potentiels, l'importance ou la valeur sociale de l'activité exercée par le défendeur, l'utilité de la conduite pour le défendeur, la faisabilité d'une conduite alternative, les coûts et charges associés à la conduite alternative, l'utilité relative de la conduite alternative et la sécurité relative de la conduite alternative.
Cas particuliers
Nos équipes de sécurité ont vu un large éventail de cas particuliers.
Nous les décrivons ici pour aider à comprendre où il existe un large éventail d'opinions sur ce qui peut être acceptable ou non. Nous recommandons à toutes les personnes concernées de communiquer de bonne foi à ce sujet.
Accès aux informations d'autres utilisateurs
Exemple : vous découvrez qu'une URL contient votre identifiant d'utilisateur et révèle un bogue, et vous pensez pouvoir modifier l'URL pour remplacer votre identifiant par celui d'un autre utilisateur.
Est-il acceptable que la personne le fasse, par exemple dans le seul but de découvrir si d'autres utilisateurs sont aussi touchés ?
Est-il plus important de comprendre rapidement l'étendue du risque pour tous les utilisateurs que de protéger quelques utilisateurs dont les informations sont peut-être déjà visibles pour les pirates ?
Est-il acceptable de le faire avec autant d'utilisateurs que l'on veut ?
Est-il acceptable que la personne tente de contacter les utilisateurs pour les informer qu'ils sont touchés ? Est-il acceptable de proposer des suggestions d'atténuation ?
Déni de service
Exemple : vous découvrez un bogue qui suspend accidentellement votre compte, par exemple en déclenchant un verrouillage de mot de passe.
- Cela est-il considéré comme une attaque par déni de service ?
Courriel non sollicité
Exemple : vous essayez de signaler un problème de sécurité à des personnes de l'entreprise que vous jugez concernées, et que vous trouvez en faisant des recherches sur LinkedIn, Facebook, etc., ou en utilisant des conventions de nommage telles que « webmaster@example.com » ou « security@example.com ».
Est-ce acceptable ?
Cela est-il considéré comme un courriel non sollicité ?
Cela est-il considéré comme un courriel non autorisé ?
Groupes exclus
Exemple : vous faites partie d'un groupe exclu, par exemple en tant que mineur, ou figurant sur une liste de sanctions, ou dans un pays figurant sur une liste de sanctions.
Vous est-il acceptable de faire un signalement ?
Est-il acceptable de signaler anonymement ?
Est-il acceptable de modifier délibérément des informations potentiellement identifiantes, par exemple pour échapper au groupe exclu, dans le but d'aider la divulgation à atteindre les bonnes personnes ?
Tiers
Exemple : vous découvrez que le logiciel d'une entreprise présente un bogue impliquant un tiers, comme une intégration avec un autre logiciel ou un autre site web.
Vous est-il acceptable de signaler toutes les informations trouvées aux deux parties ?
Faut-il faire deux divulgations responsables distinctes, par exemple un signalement à une entreprise et un autre à l'entreprise tierce, dans le but de limiter les informations envoyées à chacune ?
Est-il acceptable que la personne mette les entreprises en relation ?
Logiciel perturbateur
Exemple : vous êtes assez compétent pour écrire un virus qui, selon vous, aidera probablement les utilisateurs à se protéger du risque de sécurité, à identifier s'ils sont à risque, ou à corriger le risque de sécurité.
Est-ce acceptable ?
Est-il acceptable que la personne oriente les utilisateurs vers de tels logiciels et/ou vers des guides ou tutoriels décrivant comment créer ce type de logiciel ?
Divulgation coordonnée des vulnérabilités et divulgation responsable
La divulgation coordonnée des vulnérabilités est le terme préféré.
- L'aspect le plus important est la coordination entre la personne qui a découvert le problème et le producteur.
La divulgation responsable est un terme déconseillé.
- Les gens ont des vues différentes de ce qu'être responsable signifie. Par exemple, certains soutiennent qu'il est responsable que la personne informe immédiatement le public quelle que soit l'interaction avec le producteur, et irresponsable de pratiquer la divulgation coordonnée des vulnérabilités parce qu'elle cache des informations au public.
Suivi
- Paquet : coordinated-disclosure
- Site web : https://github.com/coordinated-vulnerability-disclosure/coordinated-vulnerability-disclosure
- Clonage : https://github.com/coordinated-vulnerability-disclosure/coordinated-vulnerability-disclosure
- Version : 2.7.0
- Créé : 2017-09-21
- Mis à jour : 2026-06-08T06:53:18Z
- Licence : GPL ou GFDL ou contactez-nous pour une licence sur mesure
- Contact : Joel Parker Henderson (http://joelparkerhenderson.com)
- Traqueur : f44c30d1b876f8987cf78c727e573542