Bug bounties crypto : être payé pour hacker la blockchain

Le stéréotype évoqué par le mot « hacker » est étonnamment tenace : un jeune homme en sweat à capuche noir, fixant d'un air sombre un écran dans une pièce vivement éclairée, dérobant les mots de passe de personnes ayant placé trop de confiance en Internet. Cette image a persisté à travers des décennies de culture de la sécurité réelle, car c'est un moyen pratique de transformer quelque chose de complexe en méchant — et les méchants sont toujours utiles. Ce dont on entend généralement moins parler, c'est que certains des meilleurs hackers se trouvent de l'autre côté de la transaction, trouvant des failles avant que les criminels ne le fassent (et se faisant payer pour leurs efforts). Cette pratique a un nom, une mémoire institutionnelle et une structure professionnelle remontant à plusieurs décennies avant la conception de la blockchain.

Le premier programme moderne et organisé de bug bounty a été lancé le 10 octobre 1995 par Netscape. L'entreprise travaillait sur Navigator 2.0, son navigateur alors leader du marché, et avait lancé un appel public : trouvez un bug de sécurité, divulguez cette vulnérabilité de manière responsable à l'entreprise et recevez une rémunération pour vos efforts. Bien que le budget fût modeste selon les normes actuelles — 50 000 $ répartis sur l'ensemble de l'opération —, l'idée en elle-même était véritablement originale. Netscape admettait en réalité publiquement que son logiciel contenait des vulnérabilités qu'elle ne pouvait pas détecter en interne et que des personnes extérieures pouvaient être mieux placées pour les découvrir. Plus que l'argent, c'était ce que signifiait cet aveu implicite.

Les débuts ont été lents tout au long des années 2000, avant de s'accélérer lorsque les grandes plateformes ont emboîté le pas. En 2010, Google a annoncé son programme Vulnerability Reward Program qui, aujourd'hui à lui seul, a versé plus de 12 000 000 $ aux chercheurs et plus de 50 000 000 $ en cumulé à ce jour. Ce n'est qu'en 2013 que Microsoft a suivi la tendance avec un programme officiel, et Apple — qui avait longtemps résisté à l'idée — a finalement ouvert son propre programme public en 2020. Dès le milieu des années 2010, les bug bounties étaient monnaie courante pour toute entreprise technologique soucieuse de sa sécurité, des services tels que HackerOne et Bugcrowd émergeant pour faciliter ces programmes à grande échelle en mettant en relation les entreprises avec des chercheurs en sécurité indépendants qui traquent les vulnérabilités à plein temps.

Cependant, toutes les découvertes majeures en matière de sécurité n'ont pas eu lieu dans le cadre d'un programme officiel de primes, et certaines des plus importantes ont illustré ce qui peut arriver lorsque ce n'est pas le cas. En 2014, deux équipes — Neel Mehta de Google et l'équipe de la firme finlandaise Codenomicon — ont révélé indépendamment une faille critique dans OpenSSL, la bibliothèque cryptographique qui sous-tend une grande partie de l'ensemble du trafic chiffré sur Internet. Cette faille nouvellement découverte, appelée Heartbleed, permettait à un attaquant de lire la mémoire d'un serveur (à laquelle il n'aurait pas dû avoir accès), exposant en texte clair des clés privées, des identifiants utilisés par des dizaines de milliers de services et des données utilisateur. Aucun bug bounty n'était prévu pour cela. Bien que la vulnérabilité ait été signalée de manière responsable, elle est restée exposée entre sa découverte et son correctif plus longtemps qu'aucun de nous n'aimerait y penser, et le suivi s'est traduit par une ruée mondiale de plusieurs mois pour tout, des correctifs logiciels aux mises à jour de contenu et même aux réacheminements. La situation contrefactuelle — et si un service de renseignement gouvernemental ou une organisation criminelle l'avait découverte avant ? — était suffisamment inconfortable pour accélérer la mise en place de programmes de divulgation structurés dans toute l'industrie.

Pourquoi la crypto a plus que tout besoin des white hats

Ainsi, le problème de sécurité dans la blockchain est structurellement différent (et fondamentalement plus complexe) que le problème moyen de sécurité logicielle, ce qui importe pour expliquer pourquoi les bug bounties sont devenus un élément aussi central du paysage ici.

Dans les logiciels traditionnels, une vulnérabilité est grave mais limitée. L'application web compromise d'une banque peut laisser fuiter des données ou déclencher une fraude, mais le dommage est contenu dans un système doté de lois, d'assurances, de détection des fraudes et de la capacité d'annuler les transactions illicites. L'argent laisse une trace écrite. Un attaquant n'évolue pas dans un vide juridique ou technique.

Scénarios de perte en DeFi, alors : un exploit réussi (ou non) se déroule différemment dans presque toutes les dimensions. En quelques secondes, tous les fonds d'un protocole peuvent être siphonnés si un intrus exploite une faille de timing dans le smart contract. S'il réussit, l'attaquant obtient une cryptomonnaie non seulement difficile à tracer, mais presque impossible à récupérer sans la coopération de son détenteur. Personne ne peut annuler la transaction car il n'y a pas d'autorité centrale. À tout moment, des milliards de dollars reposent de manière immuable dans ces smart contracts lisibles publiquement et au comportement autonome. Votre code est votre produit, et votre produit est un coffre-fort. C'est le principe du premier arrivé, premier servi pour presque tous les mécanismes, le seul recours étant le registre inviolable on-chain.

C'est ce qui rend la dynamique du glaive contre le bouclier si urgente dans la crypto. Dès l'instant où vous déployez un protocole détenant de la valeur, les forks constituent un vecteur d'attaque dès le premier jour. Les attaquants ne sont pas désorganisés. Certains sont liés à des États-nations, d'autres sont des entreprises criminelles de pointe, et beaucoup d'autres manient simplement l'amoralité et le code Solidity avec brio ; ils disposent de capitaux et surveillent comme des faucons tout ce qui est déployé. Attendre que les utilisateurs partent en raison de problèmes de sécurité n'est pas une stratégie commerciale viable. Non, la seule option est de trouver ces vulnérabilités avant les autres — et d'engager des personnes suffisamment talentueuses pour les débusquer.

Les audits et les tests d'intrusion — faire examiner le code par une entreprise de sécurité avant de le déployer — sont nécessaires, mais absolument pas suffisants. Les audits sont généralement limités dans le temps et réalisés par des équipes de taille restreinte. Un système de smart contracts peut comporter des millions de chemins d'interaction potentiels et une équipe d'audit soumise à des contraintes de temps ne couvrira que les plus évidents. Les programmes de bug bounty élargissent la recherche vers un horizon bien plus vaste et s'appuient sur un vivier mondial de chercheurs aux parcours divers, aux modèles mentaux variés et sans limite de temps. La combinaison des deux — un audit interne approfondi avant le mainnet, puis un programme permanent de primes — constitue désormais la norme pour tout protocole soucieux de sa sécurité.

Calculs de CEO : mille dollars ou un million

La logique économique des programmes de bug bounty est suffisamment limpide pour ne pas nécessiter d'explication ; en pratique pourtant, elle en demande une, car la dépense est immédiate, tandis que les économies sont théoriques et réparties sur une longue période.

Un protocole offrant une prime de 10 000 $ pour une vulnérabilité critique a dépensé 10 000 $ pour sa sécurité. Ce même protocole ne révélant aucune vulnérabilité (un acteur malveillant venant tout juste de l'exploiter) pourrait désormais voir s'envoler toutes ses réserves, des dizaines de millions disparus en un instant avec bien d'autres complexités à gérer, perdant généralement toute capacité opérationnelle par la suite. La prime n'était pas une dépense — c'était le paiement d'une assurance préventive avant même que le sinistre ne survienne. Aucun argument théorique ne remplace la prise de conscience nécessaire pour comprendre ce calcul avant le lancement — chaque CEO ayant vécu un exploit majeur le comprend viscéralement. Ceux qui ne l'ont pas vécu considèrent encore les dépenses de sécurité comme un coût opérationnel de plus à minimiser afin de cocher la case de la conformité.

Les données financières nous sont fournies par l'histoire des exploits DeFi. À titre d'exemple, rien qu'en 2022, le bridge du Ronin Network a subi une perte de 625 millions de dollars. Et un autre bridge, Wormhole, a été piraté en janvier pour un montant de 320 millions de dollars. Nomad Bridge — 190 millions de dollars perdus car chaque utilisateur pouvait vider le protocole une fois le schéma d'attaque initial identifié — une vulnérabilité qui n'aurait peut-être coûté que 50 000 $ en primes pour être découverte et corrigée. Ce ne sont pas des cas isolés. C'est le bilan officiel de ce qui se produit dans un environnement à forte valeur ajoutée où trouver des failles côté red team est très bien rémunéré et où le coût de l'exploitation est nul.

Le risque le moins souvent mentionné va en réalité dans l'autre sens. Un protocole qui ouvre un programme de bug bounty avant d'y être suffisamment préparé lance concrètement une invitation ouverte à trouver tout ce que son équipe interne a manqué — et si la base de code a été mal auditée, cela pourrait bien être à peu près tout. Par exemple, un programme plafonné à 100 000 $ lancé sur un système de contrats comportant vingt vulnérabilités critiques pourrait subir des divulgations simultanées vidant l'intégralité du budget de primes en quelques jours, tout en laissant le protocole dans un état de fonctionnement non sécurisé. Ce scénario permet d'affirmer que de nombreux projets DeFi à leurs débuts se sont retrouvés précisément dans cette situation : un programme de primes est annoncé publiquement, les signalements affluent et révèlent que l'audit interne n'était que superficiel ; cependant, les coûts de remédiation ont rapidement dépassé ce que l'équipe avait alloué à l'ensemble de sa stratégie de sécurité. La morale de l'histoire n'est pas que les bug bounties sont risqués — c'est qu'ils exigent un niveau minimal de qualité de code. Les protocoles découvrent leurs pires problèmes de la pire manière possible en lançant un programme de primes pour remplacer un travail de sécurité interne de fond plutôt que pour le compléter.

Ces constats ont mené à la séquence concrète suivante : revue interne, un ou plusieurs audits externes par des cabinets reconnus, puis passage en production avec un bug bounty permanent. D'autres intègrent une mesure supplémentaire de déploiement progressif — plafonnant la valeur maximale à risque du protocole pendant une durée déterminée pendant que la prime est active, et n'ouvrant la liquidité qu'une fois qu'aucune faille critique n'est apparue. C'est plus lent et souvent plus coûteux qu'un simple lancement direct. L'alternative est parfois catastrophique.

Écosystème : plateformes, programmes et paiements records

L'infrastructure des bug bounties crypto a considérablement mûri depuis l'époque des e-mails de divulgation informels et des récompenses ad hoc.

Immunefi est la plus grande plateforme du secteur, lancée en décembre 2020. Elle a désormais distribué plus de 100 millions de dollars aux chercheurs sur plus de 3 000 signalements de bugs, et affirme avoir contribué à prévenir des pertes de plus de 25 milliards de dollars sur au moins 500 protocoles d'ici début 2026. La plateforme rassemble une communauté d'environ 45 000 chercheurs en sécurité enregistrés, prend en charge des processus de divulgation structurés et sert d'intermédiaire dans les négociations entre chercheurs et protocoles sur la classification de la gravité et le montant des primes. Immunefi prélève une commission sur les primes versées, ce qui aligne judicieusement ses intérêts avec les deux extrémités du marché : la plateforme prospère lorsque les chercheurs trouvent de vrais bugs et que les protocoles paient pour cela.

Le paiement individuel le plus élevé de l'histoire de la plateforme reste une prime de 10 millions de dollars versée en février 2022 à l'un de ses chercheurs connu sous le pseudonyme « satya0x » pour avoir découvert une vulnérabilité de proxy non initialisé sur le bridge Wormhole. Si elle avait été exploitée, la vulnérabilité aurait menacé des ressources verrouillées d'une valeur d'environ 736 millions de dollars. Le chercheur l'a divulguée de manière responsable et s'est vu attribuer ce qui était à l'époque la plus importante prime de bug bounty jamais enregistrée. En décembre 2021, Polygon avait racheté un bug critique au chercheur Leon Spacewalker pour 2,2 millions de dollars, lequel aurait pu permettre l'émission de jusqu'à 9,3 milliards de jetons MATIC — soit une valeur de plusieurs milliards de dollars aux cours de l'époque. Le calcul est sans équivoque dans les deux sens : la prime était imposante en valeur absolue et minime par rapport aux pertes potentielles évitées.

Les programmes de récompense dédiés gérés au niveau des protocoles atteignent désormais des montants difficiles à imaginer il y a seulement quelques années. La prime maximale s'élève à 15,5 millions de dollars pour les vulnérabilités critiques dans le programme Uniswap v4. LayerZero propose des primes ouvertes allant jusqu'à 15 millions de dollars. En 2026, la récompense maximale de l'Ethereum Foundation a été portée à 1 million de dollars. Non seulement ces montants doivent être en corrélation avec la valeur des actifs que ces protocoles cherchent à sécuriser, mais ils doivent également être à la hauteur du calibre des chercheurs qu'ils souhaitent attirer — un plafond de 1 000 $ n'incitera personne capable d'exploiter une faille destructrice dans un protocole pesant plusieurs milliards de dollars.

Code4rena et Sherlock fonctionnent un peu différemment : ils organisent un concours d'audit compétitif sur une période définie, au cours duquel plusieurs chercheurs inspectent la base de code simultanément et reçoivent une part d'une cagnotte totale selon la gravité et la validité de leurs trouvailles. Avec une communauté de plus de 8 300 auditeurs enregistrés et plus de 24 000 rapports uniques sur l'ensemble des audits Code4rena. Plus de 175 concours de ce type ont été organisés par Sherlock. Le format compétitif modifie la structure des incitations : les chercheurs sont encouragés à chercher des failles que d'autres pourraient ignorer, car les soumissions multiples d'une même anomalie n'offrent souvent qu'une rémunération faible ou nulle. Généralement, cela permet également de mettre en lumière des problèmes à plus grande échelle que ne peuvent le faire séparément des audits séquentiels ou des programmes de primes ouverts. Des programmes crypto pour d'autres détenteurs de Bitcoin Cash comme Coinbase et MakerDAO sont toujours hébergés sur GitHub. Sur l'ensemble du marché actif des bug bounties dans le Web3, plus de 162 millions de dollars de primes sont désormais proposés au cas où les choses ne se dérouleraient pas comme prévu, ce qui illustre à la fois l'ampleur des enjeux et la professionnalisation d'un grand nombre de chercheurs.

L'artisanat sous la loupe : pourquoi ce n'est pas de l'argent facile

L'image du chasseur de primes qui repère une vulnérabilité en un après-midi et empoche un chèque à six chiffres ne correspond pas à la réalité du terrain. Les praticiens qui gagnent régulièrement leur vie en tant que chercheurs en sécurité dans l'univers crypto sont généralement des spécialistes, dont le parcours nécessite de nombreuses années de préparation technique dans des domaines où la plupart des développeurs s'aventurent rarement.

Détecter les défaillances les plus critiques dans le code de smart contracts en production exige une expertise pointue de l'Ethereum Virtual Machine — il ne suffit pas de savoir écrire en Solidity, il faut comprendre en quoi il est compilé, ce que l'EVM exécute réellement au niveau du bytecode et quelles fonctionnalités du langage sont garanties par le compilateur ou générées par lui, par opposition à leurs cas limites susceptibles de devenir des failles de sécurité lorsqu'ils sont couplés aux choix d'optimisation du gas faits par des développeurs pressés par les délais. Cela nécessite non seulement la maîtrise des classes de vulnérabilités courantes — réentrance, dépassement d'entier (integer overflow), manipulation de flash loans, manipulation du prix des oracles, défauts de contrôle d'accès, failles d'initialisation —, mais aussi la capacité à déceler de nouveaux vecteurs d'attaque qui ne correspondent à aucun schéma connu. Les découvertes les plus précieuses sont celles que personne ne cherchait.

La boîte à outils avec laquelle les chercheurs abordent ce travail s'est considérablement perfectionnée et comprend désormais des outils qui, dans la plupart des cas, sont indiscernables de ceux qu'un pirate utiliserait :

Slither, un framework d'analyse statique développé par Trail of Bits, peut scanner votre code Solidity à la recherche de 40 modèles de vulnérabilités connus et fournir un rapport structuré. C'est une première étape, pas la dernière — il génère des faux positifs et ignore complètement les vulnérabilités situées au niveau de la logique métier.

Mythril utilise l'exécution symbolique pour parcourir les états possibles d'un contrat et vérifie si un état atteignable enfreint certaines propriétés de sécurité définies par le chercheur. Cependant, il est coûteux en ressources et ne permet qu'une analyse superficielle des contrats complexes.

Il s'agit d'un fuzzer basé sur les propriétés : à partir d'un ensemble d'invariants qu'un contrat doit toujours respecter, le chercheur les transmet à Echidna qui génère des milliers de séquences de transactions aléatoires pour tenter de les briser. Il est particulièrement efficace pour déceler les cas limites dans l'arithmétique et la logique de gestion des états.

La majorité des recherches de sécurité sérieuses s'effectuent aujourd'hui avec Foundry, car la transition entre « je pense que cela fonctionnera » et « je peux prouver que cela fonctionne » y est minime, d'autant que la plupart des chercheurs rédigent leurs tests et leurs exploits directement en Solidity sur Foundry.

Grâce aux outils de vérification formelle de Certora, les chercheurs peuvent exprimer les spécifications comportementales d'un contrat sous forme d'énoncés mathématiques, puis les vérifier face au bytecode réel. Il s'agit de la méthode la plus rigoureuse et aussi de la plus ardue à mettre en œuvre en termes de compétences et d'efforts.

Autre outil conçu par Trail of Bits, Manticore réalise des analyses dynamiques et peut être utilisé pour générer automatiquement des entrées qui empruntent des chemins d'exécution spécifiques dans le contrat — ce que l'analyse statique ne peut atteindre.

Aucun outil ne détecte automatiquement et à lui seul des vulnérabilités critiques parmi cette panoplie. Ils réduisent le champ des candidats potentiels et mettent en évidence les zones qu'un humain doit ensuite évaluer. Si un chercheur ne sait pas lire l'assembleur EVM, raisonner sur l'ordonnancement des transactions et appréhender l'économie d'un protocole DeFi à l'échelle systémique, il ne pourra pas faire grand-chose des résultats fournis par ces outils. Ces outils amplifient l'expertise mais ne la remplacent pas.

Ces difficultés pratiques dépassent largement le cadre purement technique. La concurrence est féroce. Lors d'un concours d'audit sur Code4rena ou Sherlock, des dizaines de développeurs étudient la même base de code au même moment. Un chercheur revendique généralement une faille critique en premier — tous les autres ayant identifié le même problème ne reçoivent rien ou des miettes. Un chercheur qui consacre une semaine à un concours et ne déniche que des problèmes de gravité moyenne peut repartir avec quelques centaines de dollars seulement. La variabilité des revenus est forte et les périodes de disette sont bien réelles.

De plus, prouver un résultat peut s'avérer aussi complexe que de l'identifier. Il faut faire une démonstration pratique de l'exploitabilité (généralement via une véritable preuve de concept de l'exploit). Certains contestent ensuite la classification de gravité d'un problème jugé critique ou moyen, arguant que certains éléments en atténuent l'impact. Les chercheurs qui ne documentent pas minutieusement leurs travaux ou qui ne disposent pas de l'autorité conférée par une solide réputation peuvent se retrouver sous-payés pour des découvertes pourtant majeures.

Enfin, le cadre juridique et fiscal constitue une complication en soi. La majorité des primes sont versées sous forme de cryptomonnaies — qu'il s'agisse d'USDT, d'USDC, d'ETH ou du token natif du protocole. Recevoir un virement d'USDT comme revenu constitue un événement imposable qui oblige le bénéficiaire à consigner sa valeur au moment de la réception avant de la convertir pour sa déclaration, tout en subissant une imposition sur les plus-values en cas de fluctuation du cours si le versement a été effectué dans un autre type d'actif numérique. Les bug bounties s'accompagnent d'une réelle charge de gestion — structurer une activité de bug bounty, comme toute entreprise, nécessite d'arbitrer entre temps investi et résultats concrets. Négliger les aspects administratifs crée un autre problème qui s'aggrave insidieusement.

Mais le défi le plus profond réside dans le fait que cette profession offre un plafond très élevé pour un plancher de rémunération nul. Un chercheur qui développe une réelle expertise avec un palmarès éprouvé — qui a découvert des vulnérabilités critiques de protocoles et dont le nom apparaît dans des rapports d'audit ou des post-mortems — peut prétendre à des gains comparables aux salaires d'ingénieurs seniors dans de grandes entreprises. Pour y parvenir, il faut soit une prédisposition innée singulière, soit des années de perfectionnement d'un savoir-faire pointu. Presque tous ceux qui tentent d'en vivre exclusivement réalisent rapidement que le temps d'apprentissage est bien plus long que prévu, que la concurrence est mieux préparée qu'anticipé et que, durant cette phase d'apprentissage, les revenus ne suffisent tout simplement pas à couvrir les dépenses.

Cela ne signifie pas pour autant qu'il s'agisse d'un mauvais secteur. Cela en fait un domaine intègre. Les compétences mêmes qui permettent à un chercheur de bug bounty de réussir — concentration technique intense, pensée systémique, créativité face à l'incertitude et volonté de travailler des heures sur un sujet sans garantie de retour sur investissement — sont précisément celles recherchées par les professionnels de la sécurité dans tous les domaines. Une personne ayant développé ces compétences au niveau requis pour la recherche en sécurité crypto est en position de force pour choisir sa voie. Le bug bounty en est une, et de plus en plus convoitée par le cercle restreint de ceux qui s'y engagent.

C'est une excellente nouvelle pour quiconque gère des flux de travail basés sur l'USDT — qu'il s'agisse de déterminer le montant des primes à verser, de répartir les gains entre plusieurs collaborateurs ou simplement de transférer la récompense hors du protocole. Le calculateur de transferts USDT de Netts fait exactement cela : indiquez les adresses d'expédition et de réception et il vous précise exactement la quantité d'Energy et de Bandwidth nécessaire pour la transaction, les montants brûlés par défaut ou l'utilisation des ressources existantes, ainsi qu'une comparaison des coûts pour envoyer vers une adresse détenant déjà des USDT (13.84 TRX contre 2-3 TRX avec de l'Energy louée) ou vers une nouvelle adresse (27.70 TRX contre 4-5 TRX avec des ressources louées) — soit plus de 80 % d'économies dans les deux cas !