Un programme de bug bounty organise la recherche de vulnérabilités par des chercheurs externes : l’organisation définit un périmètre et des règles d’engagement, puis récompense financièrement les découvertes signalées selon leur gravité. Ce cadre contractuel autorise des tests qui, menés sans le consentement de l’entité concernée, tomberaient sous le coup de la loi.
Un exercice distinct du test d’intrusion
Le test d’intrusion commandité repose sur un prestataire identifié, une fenêtre de quelques jours à quelques semaines et une obligation de moyens : l’équipe déroule une méthodologie convenue et restitue un rapport couvrant l’ensemble du périmètre examiné. Le bug bounty inverse plusieurs de ces paramètres. Il fonctionne en continu et mobilise une population de chercheurs aux profils hétérogènes ; seule une vulnérabilité démontrée et non déjà signalée donne lieu à rémunération.
La distinction vaut aussi vis-à-vis des exercices dirigés par la menace. Les tests fondés sur la menace (TLPT) rejouent le mode opératoire d’un attaquant plausible, construit à partir du renseignement sur la menace disponible ; pour certaines entités financières, le règlement DORA encadre ces exercices selon des modalités proches du cadre TIBER-EU. Un bug bounty ne relève pas de cette logique de simulation ; son intérêt tient au nombre et à la diversité des regards portés sur le périmètre exposé.
Le socle préalable : une politique de divulgation coordonnée
Un chercheur peut se manifester à tout moment, en dehors de toute promesse de récompense. La première brique reste donc une politique de divulgation coordonnée : un document public qui indique comment rapporter une vulnérabilité, ce que l’organisation s’engage à en faire et sous quels délais elle répond. Les CERT documentent ce cadre de longue date, dont le CERT-FR en France ; les normes ISO/IEC 29147 et ISO/IEC 30111 décrivent respectivement la divulgation des vulnérabilités et leur traitement interne. L’ENISA a publié une étude des politiques de divulgation coordonnée dans les États membres de l’Union.
Le canal de signalement prend généralement la forme d’une adresse dédiée, référencée le cas échéant dans un fichier security.txt à l’emplacement normalisé du site. En France, l’article L. 2321-4 du code de la défense permet par ailleurs à une personne de bonne foi de signaler une vulnérabilité à l’ANSSI, la confidentialité de l’identité du déclarant étant alors préservée.
Périmètre, règles d’engagement et barème
La rédaction du programme délimite d’abord ce qui peut être testé : domaines, applications, plages d’adresses, versions d’API. Les règles d’engagement précisent ensuite la conduite attendue des participants et couvrent le plus souvent :
- les actifs inclus et exclus, identifiés sans ambiguïté ;
- les techniques proscrites, comme le déni de service ou l’ingénierie sociale visant les collaborateurs ;
- la marche à suivre en cas d’accès fortuit à des données réelles, interruption du test comprise ;
- le format du rapport et ses critères de recevabilité, notamment la reproductibilité de la démonstration.
À la réception, l’équipe tente de reproduire la démonstration et écarte les doublons. Vient ensuite l’évaluation de la gravité : le score CVSS, standard maintenu par le FIRST, sert fréquemment de base, ajustée selon l’impact métier réel de l’actif touché. Le barème associe une fourchette de récompense à chaque niveau de gravité. L’attractivité du programme dépend en partie des montants affichés, les chercheurs arbitrant entre les programmes ouverts.
Ouverture progressive et rôle des plateformes
La plupart des organisations débutent en mode privé, avec quelques chercheurs invités sur un périmètre restreint. Cette phase rode le circuit de qualification et mesure la capacité des équipes à absorber les signalements. L’ouverture au public élargit la surface d’examen mais multiplie les rapports de faible valeur, ce qui suppose un triage outillé.
Des plateformes spécialisées se sont constituées autour de cette intermédiation. Elles fédèrent des communautés de chercheurs et assurent un premier niveau de triage ; elles prennent aussi en charge les paiements et donnent au programme une visibilité qu’une simple page institutionnelle n’offre pas. Le recours à un intermédiaire ne décharge pas l’organisation de la qualification finale ni de la décision de correction.
Du signalement au correctif
Une fois accepté, le rapport rejoint le processus de gestion des vulnérabilités de l’organisation : le signalement y est priorisé au regard de l’exposition réelle de l’actif touché, puis suivi jusqu’à la vérification du correctif déployé. Les équipes de réponse, CSIRT ou CERT interne, jouent souvent le rôle de point d’entrée et de coordination ; informer le SOC des campagnes en cours évite que l’activité des chercheurs soit traitée comme une attaque réelle.
Certains rapports visent un composant tiers plutôt qu’un développement interne. La vulnérabilité relève alors de la chaîne d’approvisionnement logicielle : le correctif dépend de l’éditeur du composant, et encore faut-il localiser les applications concernées, exercice que facilite un inventaire des composants logiciels (SBOM) tenu à jour. Une politique de divulgation aboutie organise alors la transmission du signalement à l’éditeur.
Les précautions propres au secteur financier
Dans la banque et l’assurance, les périmètres exposés manipulent des données couvertes par le secret bancaire et des opérations de paiement. Les programmes du secteur restreignent en conséquence les environnements ouverts aux tests. Les chercheurs reçoivent des comptes de test sur des environnements de préproduction alimentés en données synthétiques, et les parcours engageant des transactions réelles figurent parmi les exclusions explicites. Lorsqu’un participant atteint malgré tout des données de production, les règles d’engagement imposent l’arrêt du test et un signalement immédiat, assorti d’un engagement de non-conservation.
Le cadre contractuel est lui aussi renforcé. Les clauses de confidentialité s’accompagnent d’une interdiction d’exploiter les données rencontrées, et les programmes privés conditionnent souvent la participation à une identification vérifiée des chercheurs. S’ajoute l’articulation avec les prestataires d’hébergement, dont l’autorisation peut être requise avant de tester une infrastructure mutualisée ; quand une plateforme opère le programme, elle devient elle-même un prestataire soumis au dispositif d’évaluation des tiers.
Questions fréquentes sur les programmes de bug bounty
Un bug bounty peut-il remplacer les tests d’intrusion réguliers ?
Les deux exercices répondent à des besoins différents. Le test d’intrusion garantit qu’un périmètre donné a été examiné méthodiquement à une date donnée, ce qu’exigent certains référentiels d’audit ; le bug bounty apporte une pression d’examen continue, sans promesse d’exhaustivité. Un programme s’ajoute donc aux campagnes commanditées plus qu’il ne les remplace.
Quel budget prévoir pour lancer un programme ?
Le coût combine les primes versées, la commission éventuelle d’une plateforme et le temps interne consacré à la qualification puis à la correction, poste souvent sous-estimé. Un programme privé à périmètre étroit permet de calibrer ces charges avant toute ouverture élargie ; le barème évolue ensuite avec la maturité du périmètre exposé.
Que se passe-t-il si une faille est signalée hors de tout programme ?
Un signalement spontané emprunte le canal prévu par la politique de divulgation coordonnée et suit ensuite le même traitement qu’un rapport de programme, sans contrepartie financière. Une organisation qui n’a rien publié s’expose à recevoir l’information par des voies détournées, voire à découvrir la vulnérabilité divulguée publiquement sans coordination préalable.
Les chercheurs peuvent-ils publier leurs découvertes ?
Chaque programme fixe ses règles de publication. La plupart autorisent la divulgation une fois le correctif déployé et validé par l’organisation, parfois au terme d’un délai convenu, et l’interdisent tant que la vulnérabilité reste exploitable. Le chercheur accepte ces conditions au moment de sa participation, ce qui leur donne une portée contractuelle.
