Pourquoi les primes de bug bounty stagnent-elles

Éditorial

Analyse des primes de bug bounty qui stagnent malgré l'inflation et la complexité croissante des systèmes, et du pouvoir capté par les plateformes intermédiaires.

~12 min de lecture8 sections

Pourquoi les primes de bug bounty stagnent-elles

Les primes de bug bounty stagnent en valeur réelle alors que les surfaces exposées accumulent identités fédérées, interfaces de programmation, chaînes d’approvisionnement logicielles et environnements cloud. Ce n’est pas une anomalie de marché : c’est le résultat d’un rapport de force où la plateforme standardise le prix, concentre les règles et transforme une découverte rare en offre de travail abondante.

Explication de la marmotte

Un bug bounty ressemble à une récompense affichée pour retrouver un défaut dans un bâtiment avant qu’un cambrioleur ne le fasse. La récompense attire des personnes capables de regarder là où personne ne regarde, mais celui qui tient le guichet décide du montant, des règles et parfois de ce qui mérite d’être payé.

→ Lire l’explication complète de la marmotte

La stagnation nominale masque une baisse réelle des récompenses

Une prime affichée en monnaie courante ne mesure pas le revenu réel du chercheur. Si la récompense critique reste inchangée pendant que le coût du logement, du matériel, de l’électricité et du temps disponible augmente, elle baisse mécaniquement en pouvoir d’achat. La complexité d’une cible augmente aussi le coût de production d’une découverte : comprendre un flux OpenID Connect, reconstruire une autorisation distribuée ou démontrer une élévation de privilèges dans Kubernetes demande plus de temps qu’un formulaire vulnérable à une injection SQL.

Le marché répond pourtant rarement par une hausse proportionnelle. Les grilles de récompense restent indexées sur des catégories de gravité, souvent dérivées du Common Vulnerability Scoring System (CVSS), un système de notation qui mesure mal l’effort d’investigation, la qualité de la preuve ou le coût de reproductibilité. Une vulnérabilité classée « moyenne » peut demander plusieurs jours de lecture de code et révéler une rupture de cloisonnement grave dans un contexte métier particulier. Une vulnérabilité classée « critique » peut parfois se démontrer en quelques requêtes. La grille paie le résultat abstrait, pas le travail ni le risque assumé.

C’est le premier vice structurel : la récompense rémunère une classe de sévérité prédéfinie, alors que la valeur économique provient de l’impact concret, de l’exploitabilité réelle et de la rapidité de correction. Le chercheur finance l’incertitude. L’organisation garde la possibilité de requalifier. La plateforme garde sa commission et le contrôle de l’accès au programme. Le capital adore les marchés où le fournisseur assume les coûts avant de connaître son prix.

La croissance de l’offre aggrave ce phénomène. Les outils d’analyse automatisée réduisent le coût d’entrée sur les failles triviales, les formations multiplient les profils disponibles et les plateformes centralisent les cibles. Cette abondance ne signifie pas que l’expertise profonde est devenue commune. Elle signifie qu’un grand nombre de personnes se disputent les mêmes points d’entrée visibles, avec une asymétrie d’information considérable sur les règles réelles de paiement.

Il faut donc cesser de lire les montants maximaux comme une politique de sécurité. Une prime maximale est une promesse conditionnelle, pas un budget. Le montant utile est la distribution des paiements effectifs par gravité, après exclusions, doublons, déclassements et délais de triage. Sans cette distribution, la grille ressemble à une fiche produit de salon : beaucoup de chiffres en gros, très peu de comportement observable.

Plateformes de bug bounty et capture de la valeur

Une plateforme apporte une valeur réelle : vérification d’identité, coordination de divulgation, canal sécurisé, gestion des doublons, règles de portée et médiation. Sans cette couche, une boîte de réception sécurité devient vite un mélange de rapports sérieux, de scans automatisés et de poésie involontaire en HyperText Markup Language (HTML). Ce service mérite une rémunération.

Le compromis central est là : on gagne une capacité de réception et de triage rapidement mobilisable, on paie par une perte de contrôle sur la relation économique avec les chercheurs. La recommandation est nette : ne pas confier à une plateforme le rôle de mécanisme principal d’assurance sécurité. L’utiliser comme canal d’exposition contrôlé, oui. Lui déléguer l’évaluation de la valeur d’une découverte, non.

La plateforme capte de la valeur à quatre endroits.

1. Elle contrôle l’accès à la demande. Les programmes privés filtrent les chercheurs invités. Les programmes publics filtrent la visibilité et les règles. L’accès à une cible rémunératrice n’est pas un marché ouvert au sens économique du terme.

2. Elle standardise la qualification. La taxonomie de gravité devient un instrument de prix. Si l’impact métier ne rentre pas dans les cases, la plateforme pousse naturellement vers le barème, car le barème réduit son coût de traitement.

3. Elle accumule des données de réputation. Les notes, classements, taux de validation et historiques de paiement deviennent difficiles à transporter. Cette réputation est produite par le chercheur mais reste souvent enfermée dans l’intermédiaire. C’est un coût de sortie déguisé en gamification.

4. Elle concentre la négociation. Un rapport refusé ou déclassé est rarement négocié à armes égales. L’organisation possède les journaux, l’architecture, le contexte métier et le pouvoir de correction. Le chercheur possède une preuve technique, parfois excellente, mais partielle par définition.

Cette concentration n’implique pas une malveillance automatique. Elle crée une incitation prévisible : réduire le coût unitaire de triage, limiter les cas ambigus et maintenir une offre de chercheurs suffisante. Les intérêts de la plateforme ne sont pas identiques à ceux du chercheur, ni même toujours à ceux de l’organisation cliente. C’est une chaîne d’approvisionnement, pas une communauté magique soudée par des stickers.

Pour évaluer ce risque, rapprocher le programme de bounty de la gouvernance et de l’analyse des menaces. Une découverte externe ne remplace ni l’inventaire des actifs, ni la journalisation, ni un propriétaire nommé pour chaque exposition Internet.

Un programme de divulgation n’est pas un contrôle de sécurité

Un bug bounty ne garantit ni l’absence de vulnérabilité, ni la découverte des défauts les plus dangereux, ni la discrétion des chercheurs non participants. Il ne détecte pas systématiquement les compromissions déjà en cours, les erreurs de configuration internes, les abus de privilèges légitimes ou les dépendances compromises.

Le mécanisme favorise les failles démontrables à distance et dans le périmètre autorisé. Un défaut de séparation entre locataires, une fuite via cache partagé, une erreur de gestion de clés ou une chaîne d’approvisionnement peut exiger des accès, des données ou des conditions que les règles interdisent. À l’inverse, une faille spectaculaire mais peu exploitable peut attirer l’attention parce qu’elle produit une preuve visuelle vendable. La sécurité adore les biais de sélection, surtout quand ils arrivent sous forme de capture d’écran.

La surface d’attaque d’un programme comprend aussi le programme lui-même :

• une portée trop large expose des environnements fragiles à des tests non coordonnés ;
• une portée trop étroite transforme les défauts hors périmètre en impayés, donc en zones aveugles ;
• des identifiants de test mal isolés deviennent une porte vers des données réelles ;
• une interface de programmation d’application, ou API (Application Programming Interface), de triage insuffisamment contrôlée peut divulguer rapports et pièces jointes ;
• une mauvaise gestion des doublons incite à la course, pas à la qualité de reproduction ;
• un délai de réponse excessif pousse les chercheurs sérieux vers d’autres programmes ou vers une divulgation non coordonnée.

La contre-mesure n’est pas d’ajouter un formulaire et une adresse security@. Il faut publier une portée versionnée, fournir des environnements de test non productifs, définir des règles d’arrêt pour les tests destructifs, accepter les rapports de bonne foi hors périmètre lorsqu’ils concernent une exposition involontaire, et tenir un délai cible de première réponse. Surtout, l’organisation doit garder un canal direct d’escalade pour les cas où la classification de plateforme échoue.

Les mécanismes de sécurité déjà en place restent la base : authentification résistante au hameçonnage, segmentation réseau, gestion des secrets, revue de code, analyse de dépendances et supervision. Les fondations d’identité comptent plus qu’une récompense affichée en gras. Voir aussi les principes réseau et identité et les éléments de cryptographie appliquée.

Barèmes, contrats et preuves de paiement vérifiables

Pour un programme mature, la bonne unité de pilotage n’est pas le montant maximal annoncé mais le coût évité par vulnérabilité corrigée. Cela impose de séparer trois dispositifs.

Le premier est une politique de divulgation des vulnérabilités, ouverte et sans prime obligatoire. Elle permet de recevoir les signalements de bonne foi. Elle doit définir l’autorisation de recherche, le canal de contact, les exclusions de tests destructifs et le traitement des données reçues.

Le deuxième est un bug bounty ciblé, avec une prime publique ou privée. Il sert à concentrer l’effort sur des actifs exposés, après une modification majeure, avant une échéance critique ou sur une surface difficile à tester en interne. La grille doit annoncer un plancher par catégorie, un mécanisme d’exception fondé sur l’impact métier et une indemnisation minimale pour les rapports valides hors périmètre causés par une erreur de portée.

Le troisième est un contrat de recherche ou de test d’intrusion. Il convient lorsque le système demande du temps garanti, des accès contrôlés, une connaissance métier, des tests à risque ou une confidentialité renforcée. Dans ce cas, payer à la découverte seule est une mauvaise économie : cela transforme une mission d’assurance en loterie technique.

La recommandation est de réserver les primes variables aux défauts externes, reproductibles et correctement instrumentés. Pour les domaines à forte criticité, financer du temps d’expertise avec livrables, accès de test et droit d’escalade. Le prix doit couvrir l’investigation, pas seulement le drapeau planté à la fin.

Publier au minimum les métriques suivantes, agrégées et sans données personnelles : nombre de rapports reçus, taux de validation, délai médian de première réponse, délai de correction par gravité, répartition des paiements, part des rapports déclarés doublons et nombre de décisions de requalification. Une organisation incapable de mesurer ces données ne pilote pas un programme, elle collectionne des notifications.

Exemple reproductible : mesurer l’érosion réelle des primes

Le script suivant calcule la valeur réelle d’une prime à partir d’un indice des prix choisi par l’organisation. Il ne prouve pas l’équité d’un programme, mais il élimine au moins l’argument commode selon lequel un montant inchangé serait neutre.

primes_reelles.py

# Exécution : python3 primes_reelles.py
# base_indice représente l'indice des prix lors de la définition du barème.
# indice_actuel représente le même indice à la date de revue.

prime_nominale = 5_000
base_indice = 100.0
indice_actuel = 118.5

prime_reelle = prime_nominale * base_indice / indice_actuel
hausse_necessaire = prime_nominale * indice_actuel / base_indice

print(f"Prime affichée : {prime_nominale:,.0f} €")
print(f"Valeur en monnaie de base : {prime_reelle:,.0f} €")
print(f"Prime nécessaire pour conserver le pouvoir d'achat : {hausse_necessaire:,.0f} €")

Le résultat doit alimenter une revue annuelle des planchers, pas une promesse marketing. Ajouter ensuite les délais de triage et la part des rapports validés : une prime revalorisée mais payée après des mois reste un mécanisme de financement gratuit pour l’organisation. La trésorerie ne devient pas équitable parce qu’elle porte un badge « hacker friendly ».

Conditions d’exploitation et critères de sortie

Un programme exploitable exige un propriétaire sécurité, un budget pré-approuvé, une équipe capable de reproduire, des accès de diagnostic contrôlés et une procédure de correction. Les secrets de test doivent être distincts des secrets de production, limités dans le temps et révoqués après chaque campagne. Un compte de démonstration permanent avec des privilèges excessifs finit toujours par démontrer quelque chose, mais rarement ce qui était prévu.

La supervision doit conserver les preuves nécessaires à l’analyse sans exposer des données personnelles ou des secrets aux chercheurs : journaux horodatés, identifiants de requête, traces d’autorisation et versions déployées. Sans cette observabilité, le triage devient une querelle de captures d’écran, forme de gouvernance particulièrement coûteuse.

Prévoir aussi la reprise : indisponibilité de la plateforme, indisponibilité du portail de signalement, perte d’accès à l’historique des rapports et litige sur une récompense. Exporter périodiquement les rapports, décisions, pièces jointes et statuts dans un format exploitable hors plateforme. La réversibilité n’est pas une clause décorative : elle conditionne la capacité à poursuivre la divulgation quand l’intermédiaire devient indisponible ou inacceptable.

🐝 Ce qui arrive si on s’en passe

Sans revalorisation des planchers ni politique de divulgation publiée, le prix d’une découverte n’est plus fixé par le programme mais par les autres acheteurs possibles. Une faille exploitable à distance garde sa valeur sur les marchés d’intermédiaires d’exploits, alors que la prime officielle s’érode chaque année ; l’écart creusé rend la vente hors canal relativement plus attractive, et l’organisation n’apprend l’existence du défaut qu’au moment de son exploitation. L’absence d’autorisation de recherche explicite produit un second filtre : les chercheurs soucieux du cadre légal s’abstiennent, tandis que ceux qui ignorent l’autorisation continuent de sonder. La population qui teste réellement la surface exposée se déplace alors vers ceux qui n’ont aucune raison de signaler, et le volume de rapports reçus cesse de refléter l’activité réelle sur les actifs.

🦫 Explication de la marmotte 🍫

Une organisation propose parfois de payer des personnes qui trouvent des défauts dans ses services accessibles depuis Internet. Ces personnes cherchent des erreurs qui pourraient permettre de consulter des informations, contourner une autorisation ou prendre le contrôle d’un compte. Elles envoient ensuite une preuve. L’organisation ou une plateforme vérifie le rapport, décide si le défaut est réel, choisit sa gravité et fixe le paiement.

Le problème est que les montants ne suivent pas toujours l’augmentation du coût de la vie ni le temps nécessaire pour comprendre des systèmes devenus plus compliqués. Les plateformes facilitent la réception et le classement des rapports, mais elles fixent aussi des règles, gardent les historiques de réputation et peuvent imposer leurs catégories de paiement. La personne qui trouve le défaut connaît rarement à l’avance le montant réellement reçu.

Un tel programme ne remplace pas les protections normales. Il ne garantit pas que tous les défauts seront trouvés, surtout ceux qui demandent un accès interne ou une longue analyse. L’organisation doit donc continuer à contrôler les accès, protéger les informations secrètes, surveiller ses systèmes et corriger rapidement.

Pour éviter les conflits, il faut publier les règles, prévoir un budget, répondre vite, garder les preuves techniques et conserver une copie des rapports hors de la plateforme. Les recherches longues ou risquées doivent être payées par contrat, pas uniquement par récompense aléatoire.

À lire aussi

• L'injection de prompt n'est pas un bugL'injection de prompt n'est pas un défaut qu'un correctif fera disparaître : elle découle de ce qu'un modèle de langage reçoit instructions et données dans le même canal. On ne la résout pas en filtrant ce que le modèle lit, on la contient en limitant ce qu'il peut faire.
• Comment lire un rapport OWASP Top 10Lire un rapport de scan OWASP Top 10 sans confondre signal technique, risque exploitable et bruit de détection.
• Faille Facebook Voir en tant que 2018 et vol de jetons d'accèsAnalyse de la faille Facebook Voir en tant que de septembre 2018, où trois bogues enchaînés ont livré des jetons d'accès, et de ce qu'elle impose à l'émission et à la révocation des jetons.
• Pourquoi les CTF créent des compétences offensives réutilisablesLes concours de hacking éthique forment efficacement, mais produisent aussi des compétences offensives dont l'usage échappe aux organisateurs après la compétition.

Pages voisines

Pourquoi les primes de bug bounty stagnent-elles

Elle cite

• ⇄Lien dans les deux sens :Bug bounty et inégalités structurelles de la chasse aux primes
• Bug bounty gouvernemental et immunité pénale
• Pourquoi les postes juniors cyber disparaissent

⇄ : les deux pages se citent l’une l’autre.