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

Un programme de divulgation des vulnérabilités (VDP) est un processus structuré qui offre aux chercheurs en sécurité externes un canal sûr et légal pour signaler des failles dans votre produit. Contrairement à un bug bounty, qui rémunère chaque découverte, un VDP se contente d’établir le mécanisme de réception. Toute entreprise disposant d’un produit exposé 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 emboîté le pas depuis.

Pourquoi votre startup a besoin d’un VDP avant tout le reste

Les chercheurs en sécurité vont trouver des vulnérabilités dans votre produit, que vous les y invitiez ou non. La seule question, c’est ce qui se passe ensuite.

Imaginez la scène : un chercheur découvre une injection SQL dans votre API. Sans VDP, il a trois options : écrire à votre adresse de support générique en espérant qu’un profil technique la lira, publier la faille sur les réseaux sociaux, ou la vendre sur un forum. Aucun de ces scénarios ne joue en votre faveur. Avec un VDP, le chercheur dispose d’un chemin clair pour signaler sa découverte, et votre équipe d’un processus structuré pour la trier et la corriger avant qu’elle ne devienne une fuite de données.

L’arithmétique est sans appel. Le rapport 2024 Cost of a Data Breach d’IBM chiffre le coût moyen d’une fuite à 4,88 millions de dollars à l’échelle mondiale. Pour une startup en phase d’amorçage, un tel montant est existentiel. À l’inverse, mettre en place un VDP ne coûte rien de plus que du temps d’ingénierie. Comparez avec un test d’intrusion, facturé en général entre 15 000 et 50 000 dollars par mission.

La pression réglementaire s’accélère elle aussi. La directive NIS2 de l’UE, en vigueur depuis octobre 2024, impose aux organisations des secteurs critiques de mettre en place une divulgation coordonnée des vulnérabilités. Les règles de cybersécurité de la SEC américaine, datant de 2023, exigent des entreprises cotées qu’elles déclarent les incidents significatifs dans un délai de quatre jours ouvrés. Les auditeurs SOC 2 réclament de plus en plus des preuves d’une réception externe des vulnérabilités, et plusieurs critères des Trust Services (CC7.1, CC7.2) correspondent directement aux capacités d’un VDP. Si vous comptez vendre à des grands comptes, un VDP publié apparaît dans les questionnaires de sécurité. Les questions de gestion des vulnérabilités font désormais partie du standard des évaluations de sécurité fournisseurs, et un VDP donne aux équipes achats une réponse immédiate qui raccourcit votre cycle de vente.

VDP vs bug bounty : par lequel commencer ?

Un VDP est la fondation. Un bug bounty ajoute une couche d’incitation financière par-dessus. Lancer un bug bounty avant d’être en mesure d’absorber le volume de rapports est une erreur fréquente et coûteuse.

Le rapport 2024 Hacker-Powered Security de HackerOne révèle que 77 % des organisations qui font tourner un bug bounty ont d’abord commencé par un VDP. Le raisonnement est simple : construisez le processus avant d’y ajouter le budget. Une startup de cinq personnes ne peut pas rivaliser avec la vélocité de triage de Google, mais elle peut tout à fait faire tourner un VDP professionnel.

Les quatre phases de la mise en œuvre d’un VDP

Lancer un VDP n’est pas une affaire d’un week-end, mais cela n’exige pas non plus des mois de préparation. Le processus se décompose en quatre phases qu’un seul ingénieur peut boucler en une semaine.

Phase 1 : définition du périmètre

Définissez précisément quels actifs les chercheurs ont le droit de tester. Soyez précis sur les domaines, les API et les applications mobiles. L’ambiguïté à ce stade pose problème 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 rien faire.

Dans le périmètre : applications web de production, API publiques, applications mobiles, sous-domaines spécifiques que vous contrôlez. Hors périmètre : infrastructure interne de l’entreprise, comptes des employés, outils SaaS tiers (Stripe, Intercom) et sécurité physique.

Un périmètre trop large est dangereux pour une entreprise en amorçage à la capacité d’ingénierie limitée. Si un chercheur signale une vulnérabilité dans un environnement de préproduction que vous aviez oublié de fermer au public, vous devez quand même répondre. Mais un périmètre trop étroit envoie un autre signal. Limiter votre VDP à une seule page marketing alors que votre véritable surface d’attaque inclut des API et des applications mobiles indique aux chercheurs que vous ne prenez pas la chose au sérieux.

Le bon équilibre : couvrir tout ce avec quoi vos clients interagissent. Autrement dit, les applications web de production, les API publiques et tous les clients mobiles que vous distribuez. Excluez ce que vous ne pouvez pas corriger (intégrations tierces, infrastructure gérée par des prestataires).

Phase 2 : mécanismes de signalement et security.txt

Les chercheurs ont besoin d’un canal sûr et fiable pour soumettre leurs découvertes. L’approche minimale viable est une adresse e-mail dédiée [email protected] avec chiffrement PGP. Pour les startups qui reçoivent plus d’une poignée de rapports par mois, un formulaire web structuré ou une plateforme gérée (HackerOne Response, Bugcrowd VDP, Intigriti) fait gagner un temps de triage considérable.

Quel que soit le canal retenu, le mécanisme de découverte est standardisé : security.txt. Défini dans la RFC 9116, il s’agit d’un fichier texte brut, lisible par machine, situé à /.well-known/security.txt, qui indique aux chercheurs exactement où et comment signaler des vulnérabilités.

Un security.txt complet ressemble à ceci :

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

Le champ Expires est obligatoire. Fixez-le à un an maximum et programmez un rappel récurrent dans votre agenda pour le mettre à jour. Un security.txt expiré signale un programme à l’abandon, ce qui est pire que de ne pas en avoir. L’adoption reste faible. D’après les données de securitytxt.org, seuls 1,25 % environ du million de sites web les plus visités publiaient un fichier security.txt en 2025, contre environ 0,5 % en 2022. Cette faible adoption signifie que le vôtre se remarquera auprès des chercheurs. Publiez-le avant d’en avoir besoin.

Phase 3 : politique de safe harbor

C’est le composant le plus sensible juridiquement de votre VDP. Sans une clause de sphère de sécurité (Safe Harbor) explicite, 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 ailleurs dans le monde.

Les recommandations 2022 du ministère américain de la Justice sur le CFAA indiquent explicitement que « la recherche en sécurité menée de bonne foi ne devrait pas faire l’objet de poursuites ». Votre clause de safe harbor doit comporter quatre engagements : la promesse de ne pas engager d’action en justice contre les chercheurs qui respectent la politique, l’engagement de ne pas invoquer le CFAA ou le DMCA pour de la recherche de bonne foi, la déclaration que vous épaulerez les chercheurs si des tiers engagent une action en justice, et la reconnaissance que toute recherche menée dans le cadre de la politique est autorisée.

Une clause de safe harbor mal rédigée peut soit exposer l’entreprise à des risques juridiques, soit ne pas protéger les chercheurs, qui renonceront alors complètement à signaler. Partez des modèles communautaires de disclose.io, relus par les équipes juridiques de l’EFF, de Dropbox et de Bugcrowd. Faites-les ensuite valider par votre propre conseil juridique. La plupart des avocats spécialisés startup peuvent boucler cela en 24 heures.

Ne rédigez pas votre clause de safe harbor à partir de zéro. C’est un document juridique. Les modèles de disclose.io existent précisément pour que les startups n’aient pas à débourser 10 000 dollars de frais juridiques pour en écrire une.

Phase 4 : SLA internes et processus de triage

Le délai de réponse est le signal le plus fort de tous pour savoir si votre VDP est réel ou de pure façade. Le Success Index de HackerOne montre constamment que les programmes aux délais de réponse rapides attirent nettement plus de soumissions, et de meilleure qualité. Les chercheurs se parlent entre eux. Si trois personnes signalent des problèmes et n’obtiennent aucune réponse, votre programme est mort dans les faits.

Définissez et publiez ces SLA, calibrés sur ce qu’une petite équipe peut réellement tenir :

Utilisez CVSS 4.0 (spécification FIRST.org, publiée en novembre 2023) pour le scoring de sévérité. N’inventez pas votre propre échelle. CVSS est imparfait, mais c’est un langage commun entre votre équipe et la communauté des chercheurs.

Construisez un workflow de triage qui couvre cinq étapes : réception (les rapports arrivent sur un canal dédié), triage (un ingénieur évalue la sévérité avec CVSS), suivi (créez un ticket interne, jamais dans des issues GitHub publiques), remédiation (assignez à l’équipe concernée) et réponse (informez le chercheur à chaque transition). Une fois le correctif déployé, prévenez le chercheur et proposez-lui d’être crédité dans un tableau d’honneur public.

Les référentiels de conformité qui imposent un VDP

Un VDP n’est pas qu’une bonne pratique. Plusieurs référentiels l’exigent désormais explicitement ou y incitent fortement.

SOC 2 Type II n’impose pas de VDP nommément, mais les critères communs sur l’évaluation des risques (CC3.2) et la communication (CC2.3) sont nettement plus faciles à satisfaire avec une réception externe documentée des vulnérabilités. Les auditeurs s’y attendent de plus en plus.

ISO 27001:2022 Le contrôle A.8.8 demande aux organisations d’« établir et de mettre en œuvre 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 d’identifier et de gérer les vulnérabilités de sécurité provenant de sources externes. Un VDP démontre la conformité à cette exigence.

NIST Cybersecurity Framework 2.0 demande que les vulnérabilités des actifs soient « identifiées, validées et consignées » (ID.RA-01), en incluant explicitement la découverte externe. La nouvelle fonction Govern (GV.SC-05) ajoute la gestion des risques de 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 d’établir des politiques de divulgation coordonnée des vulnérabilités. Les organisations des secteurs essentiels et importants doivent y participer.

Pour une startup en amorçage, l’argument de conformité est tourné vers l’avenir. Vous n’avez peut-être pas besoin de SOC 2 aujourd’hui, mais votre premier contrat grand compte le réclamera. Avoir un VDP déjà en place à l’arrivée de l’auditeur vous épargne des mois de course contre la montre.

Du VDP au bug bounty : quand ajouter des récompenses financières

Une fois que votre VDP tourne depuis trois à six mois avec un workflow de triage fiable, vous pouvez envisager d’ajouter des primes. Vous êtes prêt lorsque votre délai moyen de première réponse est inférieur à 24 heures, que vous avez corrigé au moins 80 % des vulnérabilités signalées dans les SLA que vous avez publiés, et que votre équipe d’ingénierie dispose d’un processus pour prioriser les correctifs de sécurité au milieu du travail sur les fonctionnalités.

Le montant des primes doit refléter l’impact réel. Les données 2024 de HackerOne donnent les médianes de versement : Critique (exécution de code à distance, contournement d’authentification) : 3 000 à 15 000 $. Élevée (XSS stocké, IDOR exposant des données personnelles) : 1 000 à 5 000 $. Moyenne (XSS réfléchi, divulgation d’informations) : 250 à 1 000 $. Faible (redirection ouverte, erreurs trop verbeuses) : 50 à 250 $.

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

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

Kit intègre un module CSIRT (Computer Security Incident Response Team) qui traite la divulgation de vulnérabilités comme un workflow de premier plan.

Le module est livré avec un portail de sécurité personnalisable sur votre domaine. Les chercheurs soumettent des rapports structurés mentionnant le type de vulnérabilité, les actifs affectés, les étapes de reproduction et une évaluation de l’impact. Fini l’analyse manuelle d’e-mails en texte libre ou les rapports perdus dans une boîte partagée. Chaque rapport passe par un pipeline de triage doté de SLA configurables. Kit suit automatiquement le délai de première réponse, le délai de triage et le délai de résolution, en notifiant les personnes assignées à l’approche des échéances et en déclenchant des règles d’escalade lorsqu’elles sont dépassées.

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

Le module comprend aussi un tableau d’honneur public, une intégration Slack pour les notifications de rapports en temps réel, et une communication avec les chercheurs directement via le portail. Les versements de primes de bug bounty sont suivis dans un grand livre financier complet, qui vous fournit des enregistrements prêts pour l’audit lorsque votre revue SOC 2 ou ISO 27001 arrive.

Pour les startups qui ont besoin à la fois d’une infrastructure de recrutement et de sécurité, piloter les deux depuis une seule plateforme, c’est un fournisseur de moins, un questionnaire de sécurité de moins et un identifiant de moins pour votre équipe.

Lancez votre VDP cette semaine

Vous n’avez pas besoin de mois de préparation. Voici ce qu’un seul ingénieur peut accomplir en cinq jours.

Jours 1 et 2 : rédigez la politique. Partez des modèles de disclose.io. Définissez le périmètre. Faites valider la clause de safe harbor par le service juridique.

Jour 3 : mettez en place le canal de réception. Configurez une adresse security@ avec PGP, ou montez un formulaire web. Publiez votre security.txt à l’adresse /.well-known/security.txt.

Jour 4 : construisez le workflow de triage. Définissez qui reçoit les rapports, comment la sévérité est évaluée et comment les correctifs sont suivis en interne.

Jour 5 : testez en soumettant un rapport via votre propre processus. Vérifiez que les e-mails d’accusé de réception partent bien, que le workflow de triage achemine correctement les rapports et que les modèles de réponse sont clairs. Annoncez ensuite le programme : ajoutez un lien dans le pied de page de votre site, publiez un article sur votre blog technique et informez les communautés de sécurité concernées.

Un VDP n’est pas un projet ponctuel. C’est un engagement opérationnel continu envers vos utilisateurs. La mise en place prend une semaine. La crédibilité qu’elle bâtit se renforce au fil des années. Lancez-vous maintenant, tant que c’est encore un avantage concurrentiel plutôt qu’une case réglementaire à cocher dans l’urgence.