Comment fonctionnent les programmes de bug bounty — Apprenti white hat : du test d'intrusion au rapport professionnel

Imaginez une entreprise qui dit publiquement : « si vous trouvez une faille dans notre service et nous la signalez de façon responsable, nous vous remercierons, parfois avec une récompense ». C'est le principe du bug bounty, littéralement « prime aux bogues ». Pour un apprenti white hat, c'est une façon légale et encadrée de s'exercer sur de vrais systèmes. Mais « légale » ne veut pas dire « sans règles » : cette leçon explique comment cela fonctionne, et surtout comment éviter les erreurs qui transforment une bonne intention en infraction.

Le cadre avant tout

Un programme de bug bounty est une autorisation écrite et publique, mais limitée. Elle ne vaut que pour ce que le programme décrit : les cibles incluses, les techniques permises, les règles à respecter. Tout ce qui sort de ce périmètre n'est pas autorisé et reste soumis aux articles 323-1 à 323-3-1 du Code pénal (accès ou maintien frauduleux dans un système de traitement automatisé de données). Lisez le règlement du programme en entier, à chaque fois, avant de tester quoi que ce soit.

Dans le chapitre précédent, vous avez construit une checklist de revue de sécurité. Le fil rouge de ce chapitre est la préparation de votre premier rapport de vulnérabilité et de votre portfolio public : deux pièces essentielles de votre dossier d'apprenti white hat.

Les acteurs d'un programme

Trois acteurs interviennent :

L'organisation qui possède le service et définit les règles ;
Les chercheurs en sécurité, indépendants ou salariés, qui cherchent des failles et les signalent ;
Une plateforme intermédiaire, dans de nombreux cas, qui héberge le programme, reçoit les rapports, aide au tri, gère les échanges et le paiement. Certaines organisations gèrent leur programme elles-mêmes, sans intermédiaire.

Cette organisation d'ensemble répond à un besoin : les équipes internes ne peuvent pas tout voir, et des centaines de chercheurs apportent des regards variés. Mais elle suppose du sérieux de part et d'autre : le chercheur respecte les règles, l'organisation traite les rapports avec considération.

Bug bounty, politique de divulgation : ne pas confondre

Un programme de bug bounty offre des récompenses (financières, ou en reconnaissance publique) pour les failles valides.
Une politique de divulgation de vulnérabilités (VDP) indique simplement comment signaler une faille et ce que l'organisation s'engage à faire (accuser réception, ne pas poursuivre le chercheur de bonne foi) ; elle n'offre pas forcément de récompense.
Certains sites publient aussi un fichier standard security.txt, placé à un emplacement convenu du site, qui indique le contact à utiliser pour signaler une faille.

Programme public (ouvert à tous) ou privé (sur invitation, souvent après avoir fait ses preuves) : les programmes privés ont généralement moins de concurrence, et sont accessibles lorsque l'on a construit une réputation. En France, l'ANSSI (cyber.gouv.fr) accepte aussi les signalements de vulnérabilités de bonne foi : le Code de la défense encadre ce signalement (consultez legifrance.gouv.fr pour le texte en vigueur). Attention : ce cadre protège le signalement, il n'autorise pas à tester sans autorisation.

Lire un règlement de programme

Un bon règlement précise, au minimum :

Le périmètre (scope) : liste des domaines, applications ou services inclus. Tout ce qui n'est pas listé est hors périmètre, y compris un service voisin qui « a l'air » de la même entreprise.
Les exclusions : types de tests ou de failles non acceptés.
Les interdictions : par exemple, pas de déni de service, pas de tests qui touchent aux données d'autres utilisateurs, pas d'ingénierie sociale envers les salariés, pas de tests physiques.
Les règles sur les données : accéder au strict minimum nécessaire à la démonstration, ne pas copier, ne pas conserver.
Le processus : comment soumettre, délais de réponse, confidentialité, divulgation publique autorisée ou non.
Les récompenses : échelle selon la gravité, éventuellement reconnaissance publique.
La protection du chercheur : l'organisation s'engage souvent à ne pas poursuivre en justice le chercheur qui respecte les règles (« refuge sûr »). Vérifiez que ce point est présent et clair.

La règle d'or : si une règle est ambiguë, demandez avant d'agir. Un chercheur sérieux pose la question ; un chercheur imprudent suppose.

Le parcours d'un rapport

Découverte dans le périmètre autorisé, avec une action minimale pour confirmer.
Soumission d'un rapport clair (c'est l'objet de la leçon suivante).
Tri : l'équipe de l'organisation ou de la plateforme vérifie, reproduit, classe la gravité. Plusieurs résultats sont possibles : accepté, doublon (quelqu'un l'a déjà signalé), informatif, hors périmètre, non reproductible.
Correction par l'organisation.
Récompense et reconnaissance le cas échéant.
Divulgation publique, si elle est autorisée, après correction et selon les délais convenus.

La divulgation coordonnée est le principe central : le chercheur donne à l'organisation un délai raisonnable pour corriger avant de rendre publique la faille, afin que les utilisateurs ne soient pas exposés entre-temps. Publier une faille non corrigée, ou la révéler à des tiers, est à l'opposé de l'esprit white hat.

Les réalités du métier

Quelques vérités qui évitent les désillusions :

Ce n'est pas un revenu régulier. Beaucoup de rapports sont refusés (doublons, hors périmètre) et la concurrence est forte. Ne comptez pas dessus comme revenu stable ; voyez-le d'abord comme un terrain d'apprentissage.
Les récompenses varient énormément selon l'organisation, la gravité et la qualité du rapport. Méfiez-vous de ceux qui promettent des gains faciles.
La patience et la méthode paient. Les chercheurs réguliers se spécialisent (un type de faille, une technologie), lisent beaucoup, améliorent leurs outils.
Les débutants commencent mieux sur les plateformes d'entraînement : PortSwigger Web Security Academy, TryHackMe, HackTheBox, OWASP Juice Shop, DVWA. Vous y apprenez sans risque juridique, avant d'aborder de vrais programmes.
La confidentialité est la règle : certains programmes interdisent toute publication sans accord. Respectez-le, y compris pour votre portfolio.

Les erreurs qui coûtent cher

Erreur	Pourquoi c'est grave
Tester hors périmètre « parce que c'est la même société »	L'autorisation ne couvre pas ce qui n'est pas listé : risque pénal
Lancer des outils automatiques agressifs sans y avoir été autorisé	Risque de perturber le service ; souvent interdit
Accéder à des données d'utilisateurs réels au-delà du minimum	Atteinte à la vie privée, violation des règles
Exiger une récompense sous menace de divulgation	Peut relever du chantage : c'est l'inverse d'une démarche responsable
Publier une faille avant correction ou sans accord	Expose les utilisateurs, rompt la confiance, peut entraîner des poursuites
Rapport copié-collé d'un outil, sans vérification	Perte de crédibilité, rejet, voire exclusion de la plateforme

Se préparer à un premier programme

Maîtrisez les bases : au minimum, les principales failles web et le raisonnement d'un test, acquis dans les cours précédents.
Choisissez un programme adapté : périmètre clair, règlement détaillé, réponses rapides.
Préparez votre environnement : un laboratoire propre, un navigateur dédié, des comptes de test, un journal de notes.
Commencez petit : une seule fonctionnalité, étudiée avec soin, plutôt qu'un balayage général.
Apprenez des retours : un refus argumenté est une leçon gratuite.

À vous de jouer

Voici un extrait fictif du règlement d'un programme de l'entreprise imaginaire Atelier Boréal :

Inclus : l'application web des clients et l'API associée. Exclus : le site vitrine, les systèmes des fournisseurs, les attaques par déni de service, l'ingénierie sociale. Règles : n'utilisez que des comptes que vous avez créés ; n'accédez pas aux données d'autres clients ; signalez dans les 48 heures toute donnée personnelle accidentellement rencontrée ; pas de publication avant accord écrit.

Pour chaque action ci-dessous, dites si elle est autorisée ou interdite, et pourquoi :

Créer deux comptes de test dans l'application et vérifier que l'un ne peut pas lire les données de l'autre.
Examiner le site vitrine de l'entreprise, car il est hébergé au même endroit.
Constater qu'un champ de l'API renvoie par erreur l'adresse d'un autre client, et le signaler tout de suite sans conserver la donnée.
Publier un billet sur votre blog le jour même de la découverte.

Voir une solution

Autorisé. Comptes créés par vous, application incluse : c'est le test d'autorisation par objet, dans le règlement.
Interdit. Le site vitrine est explicitement exclu. Le fait qu'il soit hébergé au même endroit n'y change rien.
Autorisé et conforme. La rencontre accidentelle d'une donnée personnelle est prévue : vous la signalez dans le délai, sans la conserver ni la diffuser. Le minimum d'accès a été respecté.
Interdit. La publication nécessite un accord écrit préalable, et la faille n'est pas encore corrigée.

Pour votre dossier

Ajoutez une fiche « Mes règles personnelles » : cinq règles que vous vous engagez à respecter dans tout programme (lire le règlement en entier, rester dans le périmètre, accéder au minimum, rien publier sans accord, demander en cas de doute). Elle vous servira de repère lors de vos premiers essais.

À retenir

Un programme de bug bounty est une autorisation publique mais limitée : périmètre, interdictions et règles à respecter.
Bug bounty (récompense) et politique de divulgation (signalement) sont deux choses différentes.
La divulgation coordonnée donne à l'organisation le temps de corriger avant toute publication.
Ce n'est pas un revenu garanti : c'est d'abord un terrain d'apprentissage.
Hors périmètre, les actes relèvent des articles 323-1 à 323-3-1 du Code pénal : en cas de doute, demandez.