01VDP et bug bounty : proches, mais pas identiques
Une politique de divulgation des vulnérabilités (VDP) crée un canal de signalement encadré : elle définit le périmètre, les règles du jeu et les garanties juridiques pour les personnes qui signalent – sans promesse de rémunération. Un programme de bug bounty s'appuie sur cette base et rémunère les découvertes valides afin d'orienter délibérément l'effort de test vers vos propres systèmes. Les programmes publics sont ouverts à tous et maximisent la portée, mais génèrent une charge de triage considérable ; les programmes privés invitent des chercheurs sélectionnés et vérifiés et permettent un pilotage plus fin du périmètre et de la qualité. La séquence qui a fait ses preuves : d'abord la VDP et le processus de traitement interne, ensuite le programme de bounty.
02La divulgation coordonnée des vulnérabilités comme processus
La divulgation coordonnée des vulnérabilités (CVD) désigne la démarche concertée entre découvreurs, fabricants ou exploitants et – si nécessaire – un coordinateur, jusqu'à ce qu'une vulnérabilité soit corrigée et publiée de manière contrôlée. Le processus comprend typiquement l'accusé de réception, le triage et la vérification, la correction ainsi que la publication coordonnée d'un avis de sécurité. En matière de délais, la convention des 90 jours s'est largement imposée ; Google Project Zero, par exemple, travaille avec un modèle « 90+30 ». En Allemagne, le BSI intervient comme coordinateur lorsque les fabricants ne réagissent pas ou que le processus CVD risque d'échouer ; la directive NIS2 oblige par ailleurs les États membres de l'UE à adopter des politiques CVD nationales.
03Les normes : ISO/IEC 29147 et ISO/IEC 30111
Deux normes complémentaires structurent le sujet. ISO/IEC 29147:2018 décrit l'interface vers l'extérieur : comment les organisations reçoivent les signalements de vulnérabilités, communiquent avec les personnes qui signalent et publient les informations de remédiation. ISO/IEC 30111:2019 régit le processus interne : vérifier les signalements, évaluer les impacts, développer et déployer les correctifs. Les deux éditions sont actuellement en vigueur (confirmées pour la dernière fois en 2024 et 2025 respectivement) et se prêtent bien à servir de cadre de référence pour la conception des politiques et des processus – y compris au regard des exigences du Cyber Resilience Act.
04security.txt selon la RFC 9116
La RFC 9116 (Informational, 2022) définit avec security.txt un format lisible par machine grâce auquel les personnes qui signalent trouvent le bon canal de contact : un fichier texte sous /.well-known/security.txt, servi via HTTPS. Les champs obligatoires sont Contact et Expires ; une validité inférieure à un an est recommandée afin que les informations restent à jour. Des champs optionnels comme Policy, Encryption, Preferred-Languages et Acknowledgments renvoient vers la politique de divulgation, le matériel cryptographique ou les langues préférées. Ce fichier est le premier pas le plus rapide vers une VDP opérationnelle – à condition que le contact indiqué soit réellement surveillé.
05Modèles de rémunération et d'exploitation
Les rémunérations de bug bounty sont généralement indexées sur la criticité, le plus souvent sur la base du Common Vulnerability Scoring System (CVSS) de FIRST, actuellement en version 4.0 (2023). Les montants fixes ou les fourchettes par niveau de criticité sont courants ; en règle générale, seul le premier signalement valide d'une vulnérabilité est rémunéré, les doublons et les découvertes hors périmètre ne le sont pas. Côté exploitation, il existe trois modèles de base : l'exploitation en interne (contrôle total, mais charge de triage et de paiement à assumer soi-même), les plateformes commerciales (grande portée, mais davantage de bruit dans le triage) et les programmes managés avec des chercheurs curatés et identifiés, le triage étant assuré par le prestataire. VamiSec exploite par exemple un programme de bug bounty privé et curaté en tant que service managé.
06Cyber Resilience Act : la gestion des vulnérabilités comme obligation
Le Cyber Resilience Act (règlement (UE) 2024/2847) rend la gestion structurée des vulnérabilités obligatoire pour les fabricants de produits comportant des éléments numériques. L'annexe I, partie II, exige entre autres une nomenclature logicielle (SBOM), la correction sans délai des vulnérabilités par des mises à jour de sécurité gratuites, une politique de divulgation coordonnée des vulnérabilités ainsi qu'une adresse de contact pour les signalements de vulnérabilités. À partir du 11 septembre 2026 s'appliquent en outre les obligations de notification de l'art. 14 : les vulnérabilités activement exploitées doivent être notifiées dans les 24 heures (alerte précoce) et 72 heures (notification) au CSIRT désigné comme coordinateur et à l'ENISA via la plateforme centrale de notification, un rapport final devant suivre au plus tard 14 jours après la disponibilité d'une mesure corrective. Les autres obligations s'appliquent pour l'essentiel à partir du 11 décembre 2027 – qui met en place dès maintenant sa VDP et son processus CVD pose ainsi une brique essentielle de la conformité au CRA.
