Comment mettre en place un programme de divulgation des vulnérabilités en 2026

Un programme de divulgation des vulnérabilités (VDP) est un processus structuré qui permet à des chercheurs en sécurité externes de signaler des failles dans votre produit en toute sécurité et en toute légalité. Contrairement à un programme de bug bounty, qui rémunère chaque vulnérabilité découverte, un VDP établit un canal de signalement clair sans exiger de récompense financière. Toute entreprise disposant d’un produit accessible sur internet en a besoin. L’agence américaine CISA (Cybersecurity and Infrastructure Security Agency) a rendu les VDP obligatoires pour les agences fédérales en 2020 via la Binding Operational Directive 20-01, et le secteur privé a rapidement suivi.

Pourquoi votre startup a besoin d’un VDP maintenant

Les chercheurs en sécurité trouveront des vulnérabilités dans votre produit, que vous ayez un VDP ou non. La question est ce qui se passe ensuite.

Sans canal de signalement, un chercheur qui découvre une injection SQL dans votre processus de paiement a trois options : envoyer un e-mail à votre adresse de support générique en espérant qu’un technicien le lira, publier la faille sur les réseaux sociaux, ou la vendre. Aucune de ces options n’est favorable pour vous. Les vulnérabilités des applications web restent omniprésentes, comme le documente le Top Ten OWASP qui recense les risques de sécurité les plus critiques auxquels font face les organisations. Une seule vulnérabilité non signalée peut se transformer en violation de données qui coûte à votre entreprise sa réputation et ses clients.

L’argument économique est convaincant. Selon le rapport 2024 Cost of a Data Breach d’IBM, le coût moyen d’une violation de données a atteint 4,88 millions de dollars au niveau mondial. Pour une startup, une violation de cette ampleur est souvent fatale. En comparaison, la mise en place d’un VDP ne coûte pratiquement rien. Vous avez besoin d’un document de politique, d’un canal de réception sécurisé et d’une personne pour trier les rapports. Comparez cela avec l’embauche d’une société de tests d’intrusion, qui facture entre 15 000 et 50 000 dollars par mission selon les estimations du SANS Institute.

La pression réglementaire s’accélère également. La directive NIS2 de l’UE, en vigueur depuis octobre 2024, exige que les organisations opérant dans des secteurs critiques mettent en place une divulgation coordonnée des vulnérabilités. Les règles de divulgation en cybersécurité de la SEC américaine de 2023 imposent aux entreprises cotées de signaler les incidents matériels dans un délai de quatre jours ouvrables. Disposer d’un VDP est l’infrastructure minimale pour répondre à ces obligations.

VDP vs. bug bounty : lequel en premier ?

Un VDP est la fondation. Un bug bounty ajoute une couche d’incitation financière par-dessus. Commencer par un bug bounty avant d’avoir le processus de triage pour gérer les rapports est une erreur fréquente et coûteuse.

Caractéristique	Programme de divulgation des vulnérabilités	Programme de bug bounty
Coût	Gratuit (aucun paiement requis)	500-50 000+ $ par rapport valide
Périmètre	Toutes les vulnérabilités	Périmètre défini avec exclusions
Chercheurs	Tout le monde	Attire des chasseurs expérimentés
Protection juridique	Indispensable	Indispensable
Charge de triage	Modérée	Élevée (plus de volume)
Idéal pour	Toute entreprise, dès le premier jour	Entreprises avec équipes sécurité matures

Selon le rapport 2024 Hacker-Powered Security de HackerOne, 77 % des organisations qui gèrent des bug bounties ont d’abord commencé par un VDP. Construisez le processus avant d’ajouter le budget.

Que doit contenir une politique VDP

Votre politique VDP est un document juridique, un outil de communication et un ensemble d’engagements opérationnels. Elle doit couvrir clairement cinq domaines.

Périmètre : ce que les chercheurs peuvent tester

Définissez précisément quels actifs sont dans le périmètre. Soyez spécifique sur les domaines, les plages IP, les applications mobiles et les API. L’ambiguïté ici crée des problèmes dans les deux sens : les chercheurs perdent du temps sur des actifs hors périmètre, et vous recevez des rapports sur lesquels vous ne pouvez pas agir.

Une bonne définition de périmètre ressemble à ceci :

• Dans le périmètre : *.votreentreprise.com, application iOS (App Store), application Android (Google Play), API publique à api.votreentreprise.com
• Hors périmètre : Services tiers (Stripe, Intercom), sécurité physique, ingénierie sociale visant les employés

Safe harbor : protection juridique pour les chercheurs

C’est la section la plus importante de votre politique. Sans formulation claire de safe harbor, les chercheurs ne vous signaleront rien. Ils craindront des poursuites au titre du Computer Fraud and Abuse Act (CFAA) aux États-Unis ou de lois équivalentes dans d’autres juridictions.

Les directives CFAA du Département de la Justice américain de 2022 stipulent explicitement que “la recherche en sécurité de bonne foi ne devrait pas faire l’objet de poursuites.” Votre politique devrait refléter ce langage. Une clause de safe harbor minimale comprend :

1. L’engagement de ne pas engager de poursuites judiciaires contre les chercheurs qui respectent la politique
2. L’engagement de ne pas invoquer le CFAA ou le DMCA pour de la recherche de bonne foi
3. La déclaration que vous collaborerez avec les chercheurs si des tiers engagent des poursuites
4. La reconnaissance que la recherche menée dans le cadre de la politique est autorisée

Exigences de signalement : ce que vous attendez des chercheurs

Indiquez précisément aux chercheurs ce que leur rapport doit contenir. Un modèle fait gagner du temps aux deux parties :

• Type de vulnérabilité (ex. : XSS, SSRF, contrôle d’accès défaillant)
• URL ou point de terminaison affecté
• Étapes de reproduction (spécifiques, numérotées)
• Évaluation de l’impact (quelles données sont exposées, quel accès est obtenu)
• Captures d’écran ou preuve de concept (vidéo préférée pour les chaînes complexes)
• Coordonnées du chercheur (pour le suivi)

Engagements de réponse : vos SLA

Les chercheurs ont été conditionnés par des années d’ignorance. Selon les données de HackerOne, le temps médian jusqu’à la première réponse sur l’ensemble des programmes est de 8 heures, tandis que le quartile supérieur répond en moins d’1 heure. Vos SLA signalent si vous prenez la sécurité au sérieux.

Définissez et publiez ces délais :

• Accusé de réception : dans les 2 jours ouvrables
• Décision de triage : dans les 5 jours ouvrables
• Mise à jour de statut : au minimum tous les 14 jours jusqu’à la résolution
• Délai de correction : selon la gravité (critique : 7 jours, élevée : 30 jours, moyenne : 90 jours)

Calendrier de divulgation : coordonnée vs. complète

La plupart des VDP utilisent la divulgation coordonnée : le chercheur s’engage à garder le silence pendant que vous corrigez le problème, et vous vous engagez à le corriger dans un délai défini (généralement 90 jours, conformément au standard de Google Project Zero). Passé ce délai, le chercheur peut publier.

Soyez explicite à ce sujet. Les chercheurs respectent les organisations qui s’engagent sur des délais. Ils se méfient de celles qui demandent le silence indéfini.

Comment rédiger votre fichier security.txt

Le standard security.txt (RFC 9116) donne à votre VDP un point d’entrée lisible par les machines. C’est un fichier texte brut situé à /.well-known/security.txt qui indique aux outils automatisés et aux chercheurs où signaler les vulnérabilités.

Un fichier security.txt complet comprend :

Contact: mailto:[email protected]
Contact: https://votreentreprise.com/security/report
Expires: 2027-03-15T00:00:00.000Z
Encryption: https://votreentreprise.com/.well-known/pgp-key.txt
Policy: https://votreentreprise.com/security/policy
Preferred-Languages: fr, en
Canonical: https://votreentreprise.com/.well-known/security.txt

Le champ Expires est obligatoire dans la RFC 9116. Fixez-le à un an maximum et programmez un rappel récurrent pour le mettre à jour. Un fichier security.txt expiré signale l’abandon, ce qui est pire que de ne pas en avoir du tout.

Selon les données de securitytxt.org, l’adoption parmi le Top 1 Million Alexa est passée de moins de 2 % en 2022 à environ 8 % en 2025. Parmi les entreprises ayant subi une divulgation publique de violation, l’adoption dépasse les 30 %. N’attendez pas une violation pour publier le vôtre.

Étape par étape : lancer votre VDP en une semaine

Vous n’avez pas besoin de mois de planification pour lancer un VDP. Voici un calendrier concret pour une startup de 5 à 50 employés.

Jour 1-2 : Rédiger la politique

Commencez avec les modèles communautaires de disclose.io. Leur formulation de safe harbor a été examinée par les équipes juridiques d’organisations comme l’EFF, Dropbox et Bugcrowd. Adaptez la section périmètre à vos actifs et faites relire par votre conseil juridique (la plupart des avocats de startups peuvent traiter cela en 24 heures).

Jour 3 : Mettre en place le canal de réception

Vous avez besoin d’un moyen sécurisé et fiable pour recevoir les signalements. Les options :

• E-mail dédié ([email protected]) avec chiffrement PGP
• Formulaire web sur votre page sécurité avec TLS et contrôles d’accès
• Plateforme (HackerOne, Bugcrowd, Intigriti) pour la réception et le triage gérés

Un e-mail dédié fonctionne pour la plupart des startups. Ajoutez une clé PGP pour que les chercheurs puissent chiffrer les détails sensibles. Si vous prévoyez plus de cinq rapports par mois, une plateforme vous fera gagner un temps considérable de triage.

Jour 4 : Publier security.txt et la page de politique

Créez votre fichier security.txt et publiez-le à /.well-known/security.txt. Créez une page /security sur votre site web contenant votre politique complète, votre périmètre et vos instructions de signalement.

Jour 5 : Construire le workflow de triage

Définissez qui reçoit les rapports, comment ils sont priorisés et comment les corrections sont suivies. Au minimum :

1. Réception : Les rapports de sécurité arrivent par un canal dédié (e-mail, plateforme ou formulaire)
2. Triage : Un ingénieur évalue la gravité dans les 2 jours ouvrables en utilisant CVSS 4.0
3. Suivi : Créez un ticket interne dans votre gestionnaire d’incidents (ne mettez pas les détails de vulnérabilité dans des issues GitHub publiques)
4. Correction : Assignez à l’équipe concernée selon le composant affecté
5. Communication : Tenez le chercheur informé à chaque étape
6. Clôture : Confirmez la correction avec le chercheur, proposez une mention dans votre hall of fame

Jour 6-7 : Tester et annoncer

Soumettez un rapport test à travers votre propre processus. Vérifiez que l’e-mail d’accusé de réception fonctionne, que le workflow de triage se déclenche et que les modèles de réponse sont clairs. Puis annoncez votre VDP :

• Ajoutez un lien dans le pied de page de votre site
• Publiez un article sur votre blog technique
• Informez les communautés de sécurité concernées

Erreurs courantes qui ruinent la crédibilité d’un VDP

Ignorer les rapports

Le moyen le plus rapide de détruire la réputation de votre VDP est de ne pas répondre. Les chercheurs communiquent entre eux. Si trois personnes signalent des problèmes et n’obtiennent aucune réponse, votre programme est en pratique mort. Les données de HackerOne montrent que les programmes avec des temps de réponse supérieurs à 7 jours reçoivent 40 % de soumissions en moins au trimestre suivant.

Périmètre trop restreint

Limiter votre périmètre à une seule page marketing alors que votre surface d’attaque réelle inclut des API, des applications mobiles et des intégrations tierces montre aux chercheurs que vous n’êtes pas sérieux. Si vous n’êtes pas prêt à corriger des problèmes sur l’ensemble de votre surface, soyez honnête à ce sujet dans la politique, tout en planifiant une extension.

Menacer les chercheurs

Cela arrive encore. En 2023, une grande compagnie aérienne a menacé de poursuites judiciaires un chercheur qui avait signalé une vulnérabilité via leur canal officiel. Le contrecoup en termes de réputation leur a coûté bien plus que la correction de la vulnérabilité n’aurait coûté. Votre formulation de safe harbor existe pour prévenir cela. Assurez-vous que votre équipe juridique et votre direction comprennent et soutiennent cette approche.

Absence de boucle de retour

Les chercheurs veulent savoir que leur rapport a eu un impact. Envoyez-leur l’identifiant CVE s’il en est attribué un. Indiquez-leur quand le correctif est déployé. Proposez une mention dans vos avis de sécurité. Cela ne coûte rien et construit une relation qui génère davantage de rapports de qualité.

Évaluation de la gravité avec CVSS 4.0

Le Common Vulnerability Scoring System version 4.0, publié par FIRST.org en novembre 2023, est la norme actuelle pour évaluer la gravité des vulnérabilités. CVSS 4.0 a introduit des améliorations significatives par rapport à la version 3.1, notamment des métriques supplémentaires pour l’automatisation, la récupération et la densité de valeur.

Utilisez CVSS pour créer des paliers de SLA cohérents :

Score CVSS 4.0	Gravité	SLA de réponse	SLA de correction
9,0-10,0	Critique	4 heures	7 jours
7,0-8,9	Élevée	24 heures	30 jours
4,0-6,9	Moyenne	2 jours ouvrables	90 jours
0,1-3,9	Faible	5 jours ouvrables	Meilleur effort

N’inventez pas votre propre échelle de gravité. CVSS est un standard imparfait, mais c’est un langage commun entre votre équipe et la communauté des chercheurs. S’en écarter crée de la confusion et des litiges.

Passer du VDP au bug bounty

Une fois que votre VDP fonctionne depuis 3 à 6 mois et que vous disposez d’un workflow de triage fiable, vous êtes prêt à envisager des récompenses financières.

Quand ajouter des bounties

Vous êtes prêt lorsque :

• Votre temps moyen de première réponse est inférieur à 24 heures
• Vous avez corrigé au moins 80 % des vulnérabilités signalées dans vos SLA publiés
• Vous avez un contact sécurité dédié (pas nécessairement à temps plein)
• Votre équipe d’ingénierie a un processus pour prioriser les corrections de sécurité aux côtés du travail sur les fonctionnalités

Fixer les montants de récompense

Les montants des bounties doivent refléter l’impact réel de la vulnérabilité, pas un tarif forfaitaire. Les données 2024 de HackerOne montrent les paiements médians tous secteurs confondus :

• Critique : 3 000-15 000 $ (exécution de code à distance, contournement d’authentification)
• Élevée : 1 000-5 000 $ (XSS stocké, IDOR avec exposition de données personnelles)
• Moyenne : 250-1 000 $ (XSS réfléchi, divulgation d’information)
• Faible : 50-250 $ (redirection ouverte, messages d’erreur détaillés)

Pour les startups, commencer dans le bas de ces fourchettes est tout à fait acceptable. Les chercheurs accordent plus d’importance à la réactivité et au respect qu’aux paiements maximaux. Un programme qui paie 500 $ et répond en 4 heures attirera de meilleurs talents qu’un programme qui paie 5 000 $ et ignore les rapports pendant des semaines.

Cadres de conformité qui exigent un VDP

Un VDP n’est pas seulement une bonne pratique. Plusieurs cadres de conformité l’exigent désormais explicitement.

SOC 2 Type II : Bien que SOC 2 n’impose pas un VDP nommément, les Critères Communs relatifs à l’évaluation des risques (CC3.2) et à la communication (CC2.3) sont significativement plus faciles à satisfaire avec un VDP documenté. Les auditeurs demandent de plus en plus des preuves d’un canal externe de réception des vulnérabilités.

ISO 27001:2022 : Le contrôle A.8.8 (Gestion des vulnérabilités techniques) exige des organisations qu’elles “établissent et mettent en oeuvre des règles pour la divulgation des vulnérabilités.” Un VDP satisfait directement ce contrôle.

PCI DSS 4.0 : L’exigence 6.3.1 impose aux organisations d’identifier et de gérer les vulnérabilités de sécurité, y compris via des sources externes. Un VDP démontre la conformité à l’exigence de “source externe.”

NIST Cybersecurity Framework 2.0 : La fonction Identifier (ID.RA-01) demande que les “vulnérabilités dans les actifs” soient “identifiées, validées et enregistrées,” incluant explicitement la découverte externe. La nouvelle fonction Gouverner (GV.SC-05) ajoute la gestion des risques liés à la chaîne d’approvisionnement, où les VDP jouent un rôle de plus en plus important.

Directive NIS2 (UE) : L’article 12 impose aux États membres de l’UE d’établir des politiques de divulgation coordonnée des vulnérabilités. Les organisations des secteurs essentiels et importants doivent y participer.

Si votre startup dessert des clients entreprises, un VDP apparaît souvent dans les questionnaires de sécurité. Selon une enquête Whistic de 2024, 64 % des acheteurs entreprises incluent la gestion des vulnérabilités dans les évaluations de sécurité des fournisseurs. Disposer d’un VDP publié raccourcit votre cycle de vente en fournissant une réponse immédiate aux équipes d’achat.

Hall of fame : reconnaître les chercheurs

Un hall of fame public ne coûte rien à maintenir et génère une bienveillance significative au sein de la communauté de recherche en sécurité. Il reconnaît les chercheurs qui ont divulgué des vulnérabilités de manière responsable et encourage les futurs signalements sans nécessiter de récompenses financières.

Votre hall of fame devrait inclure :

• Nom ou pseudonyme du chercheur (selon sa préférence de crédit)
• Date de la divulgation
• Catégorie générale de la vulnérabilité (sans révéler de détails exploitables)

Ne publiez pas les détails complets des vulnérabilités, les points de terminaison affectés ou les étapes de reproduction dans votre hall of fame. Limitez-vous aux noms et aux dates. L’avis de sécurité détaillé (s’il est publié) doit être un document séparé, publié après le déploiement et la vérification du correctif.

Certains chercheurs construisent leur réputation professionnelle grâce aux crédits de hall of fame. Pour les consultants indépendants et les étudiants, une reconnaissance publique de votre entreprise peut avoir plus de valeur qu’une petite prime. Traitez-la avec le sérieux qu’elle mérite.

Comment Kit gère la divulgation des vulnérabilités

Kit intègre un module CSIRT (Computer Security Incident Response Team) qui traite la divulgation des vulnérabilités comme un workflow de premier ordre, pas comme un ajout tardif greffé sur un système de tickets.

Le module comprend un portail de sécurité personnalisable auquel les chercheurs accèdent via votre domaine. Vous publiez votre politique VDP, votre périmètre et vos consignes de signalement directement depuis Kit. Les chercheurs soumettent leurs rapports via un formulaire structuré qui collecte exactement les informations dont votre équipe de triage a besoin : type de vulnérabilité, actifs affectés, étapes de reproduction et évaluation de l’impact. Plus besoin d’analyser des e-mails en texte libre ou de perdre des rapports dans une boîte mail partagée.

Chaque rapport suit un pipeline de triage défini avec des SLA configurables. Kit suit automatiquement le temps jusqu’à la première réponse, jusqu’au triage et jusqu’à la résolution. Quand une échéance approche, le membre de l’équipe assigné est notifié. Quand elle est dépassée, les règles d’escalade se déclenchent. C’est le même mécanisme d’application des SLA utilisé par les plateformes dédiées comme HackerOne, intégré dans le même outil que votre équipe utilise déjà pour le recrutement.

Kit génère et maintient automatiquement votre fichier security.txt, y compris le champ obligatoire Expires avec une vérification récurrente qui vous avertit avant son expiration. Le portail de sécurité prend en charge les domaines personnalisés, permettant aux chercheurs d’interagir avec security.votreentreprise.com plutôt qu’une plateforme tierce.

Le module comprend également un hall of fame public, une intégration Slack pour les notifications en temps réel des rapports, et la communication avec les chercheurs directement via le portail. Les décaissements pour les récompenses de bug bounty sont suivis avec un registre complet, vous fournissant des dossiers prêts pour l’audit lors des revues SOC 2 et ISO 27001.

Pour les startups qui ont besoin à la fois d’une infrastructure de recrutement et de sécurité, Kit élimine la nécessité de gérer des plateformes séparées. Votre module CSIRT fonctionne aux côtés de votre ATS, utilisant les mêmes comptes d’équipe, le même espace de travail Slack et la même facturation. Cela signifie un fournisseur de moins, un questionnaire de sécurité de moins à remplir et un identifiant de connexion de moins pour votre équipe.

Checklist : lancez votre VDP cette semaine

Utilisez cette checklist pour suivre votre progression. Chaque point peut être accompli par un seul ingénieur en une semaine.

1. Rédigez votre politique VDP en utilisant les modèles de disclose.io
2. Définissez votre périmètre (domaines, API, applications mobiles)
3. Rédigez la formulation de safe harbor et faites-la relire par votre conseil juridique
4. Mettez en place un canal de réception sécurisé (e-mail avec PGP, formulaire web ou plateforme)
5. Créez votre fichier security.txt à /.well-known/security.txt
6. Publiez votre page de politique à /security ou /security/policy
7. Définissez les niveaux de gravité et les SLA de réponse avec CVSS 4.0
8. Construisez le workflow de triage interne (qui reçoit, qui trie, qui corrige)
9. Créez des modèles de réponse (accusé de réception, décision de triage, mise à jour de statut, résolution)
10. Mettez en place une page de hall of fame publique
11. Soumettez un rapport test à travers votre propre processus
12. Annoncez votre VDP (pied de page du site, article de blog, communautés de sécurité)

Un VDP n’est pas un projet ponctuel. C’est un engagement continu envers vos utilisateurs que vous prenez leur sécurité au sérieux. La mise en place prend une semaine. La crédibilité qu’il construit prend des années. Commencez maintenant, pendant que c’est encore un avantage concurrentiel plutôt qu’une exigence réglementaire que vous devez rattraper dans l’urgence.