Bug Bounties Crypto : Être payé pour hacker la blockchain

Le stéréotype évoqué par le mot « hacker » est d'une résilience étonnante : un jeune homme en sweat à capuche noir, fixant sombrement un écran dans une pièce intensément éclairée, volant les mots de passe de personnes ayant accordé trop de confiance à Internet. Cette image a persisté à travers des décennies de culture de la sécurité réelle, car elle constitue un moyen pratique de transformer quelque chose de complexe en une figure de 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 cette transaction, débusquant les failles avant les malfrats (et étant rémunérés 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 de « bug bounty » organisé et de style moderne a été lancé le 10 octobre 1995 par Netscape. L'entreprise travaillait alors sur Navigator 2.0, son navigateur phare de l'époque, et avait lancé un appel public : trouvez un bogue de sécurité, divulguez cette vulnérabilité de manière responsable à l'entreprise, et soyez payé pour vos efforts. Bien que le budget fût modeste par rapport aux normes actuelles — 50 000 $ répartis sur l'ensemble du programme — l'idée en elle-même était véritablement originale. Netscape admettait, en effet, publiquement que son logiciel présentait des vulnérabilités qu'elle ne pouvait pas détecter en interne et que des intervenants extérieurs pourraient être mieux placés pour les découvrir. Plus que l'argent, c'était la portée de cette admission implicite qui importait.

Le mouvement a connu un démarrage lent au cours des années 2000, avant de s'accélérer lorsque les grandes plateformes s'y sont ralliées. En 2010, Google a annoncé son « Vulnerability Reward Program » qui, pour la seule année en cours, verserait plus de 12 000 000 $ aux chercheurs, pour un total cumulé de plus de 50 000 000 $ à 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.

Au milieu des années 2010, les programmes de bug bounty étaient devenus monnaie courante pour toute entreprise technologique soucieuse de sa sécurité, avec l'émergence de services tels que HackerOne et Bugcrowd pour faciliter ces programmes à grande échelle en mettant en relation les entreprises avec des chercheurs en sécurité indépendants qui se consacrent à plein temps à la recherche de vulnérabilités.

Cependant, toutes les découvertes majeures en matière de sécurité n'ont pas eu lieu dans le cadre d'un programme de primes formel, et certaines des plus lourdes de conséquences ont illustré ce qui peut arriver quand ce n'est pas le cas. En 2014, deux équipes — Neel Mehta de Google et l'équipe de la société finlandaise Codenomicon — ont révélé indépendamment une faille sérieuse dans OpenSSL, la bibliothèque cryptographique qui sous-tend une grande partie du trafic chiffré sur Internet. Cette faille nouvellement découverte, connue sous le nom de Heartbleed, permettait à un attaquant de lire la mémoire d'un serveur (à laquelle il n'aurait pas dû pouvoir accéder), exposant en clair des clés privées, des identifiants utilisés par des dizaines de milliers de services et des données utilisateur. Aucune prime de bug bounty n'était à la clé. Bien que la vulnérabilité ait été signalée de manière responsable, elle est restée exposée entre sa découverte et l'application du correctif plus longtemps que nous ne voudrions l'imaginer, et le suivi a consisté en une course effrénée mondiale de plusieurs mois pour tout gérer, des correctifs logiciels aux mises à jour de contenu et même aux réexpéditions. Le scénario contrefactuel — et si un service de renseignement gouvernemental ou une organisation criminelle l'avait découvert plus tôt — était suffisamment inquiétant pour accélérer la mise en œuvre de programmes de divulgation structurés dans l'ensemble de l'industrie.

Pourquoi la crypto a plus que tout autre besoin des « white hats »

Ainsi, le problème de sécurité au sein de la blockchain est structurellement différent (et fondamentalement plus complexe) que le problème de sécurité logicielle classique, ce qui est crucial pour expliquer pourquoi les « bug bounties » sont devenus un élément si central de ce paysage.

Dans le logiciel traditionnel, 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 les dommages sont contenus dans un système régi par des lois, des assurances, des mécanismes de détection de la fraude et la capacité d'annuler les transactions illicites. L'argent laisse une trace. Un attaquant ne travaille pas en vase clos.

Les scénarios de perte en DeFi sont donc bien différents : une exploitation de faille (réussie ou non) se déroule différemment sous presque tous les aspects. En quelques secondes, tous les fonds d'un protocole peuvent être siphonnés si un intrus exploite une faille de synchronisation dans le contrat intelligent. En cas de succès, Certains sont liés à des États-nations, d'autres sont des entreprises criminelles sophistiquées, et bien d'autres se contentent de suivre la carte de l'immoralité en ayant pris leurs quartiers dans Solidity ; ils disposent de liquidités et sont aux aguets, surveillant tout ce qui est déployé. Attendre que les utilisateurs s'en aillent à cause 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'embaucher des personnes assez talentueuses pour les débusquer.

L'audit et les tests d'intrusion — faire examiner le code par une société de sécurité avant son déploiement — sont nécessaires, mais loin d'être 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 contrats « intelligents » 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. Ces programmes de bug bounty élargissent considérablement l'horizon de recherche et s'appuient sur un vivier mondial de chercheurs aux parcours variés, aux modèles mentaux différents et disposant d'un temps indéfini. La combinaison des deux — un audit interne complet avant le déploiement sur le mainnet, puis un programme de primes permanent — est aujourd'hui la norme adoptée par ceux qui se soucient de la sécurité des protocoles.

Le calcul du PDG : entre mille dollars et un million

La logique économique des programmes de bug bounty est assez simple pour ne pas nécessiter d'explication ; en pratique, elle en demande pourtant une, car la dépense est immédiate, tandis que les économies sont théoriques et s'étalent 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é. C'est ce même protocole qui pourrait ne révéler aucune vulnérabilité (nous venons de voir un acteur malveillant exploiter cela) et qui pourrait maintenant perdre toutes ses réserves, des dizaines de millions envolés rapidement, avec bien plus de complexité à gérer, risquant même l'arrêt total de ses opérations. La prime n'était pas une dépense — c'était le versement d'une assurance préventive avant même que le sinistre ne survienne. Aucun argumentaire ne permet d'acquérir la clairvoyance nécessaire pour expliquer ces calculs avant le lancement — tout PDG ayant subi une faille majeure le comprend viscéralement. Ceux qui ne l'ont pas vécu considèrent les dépenses de sécurité comme un simple coût opérationnel supplémentaire à minimiser pour cocher la case de la conformité.

Les données de coûts sont fournies par l'historique des failles de la DeFi. À titre d'exemple, pour la seule année 2022, le pont au sein du réseau Ronin a subi une perte de 625 millions de dollars. Un autre pont, Wormhole, a été piraté en janvier pour un coût 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 déterminé — une vulnérabilité qui n'aurait pu coûter que 50 000 $ en primes (bounties) pour être découverte et corrigée. Il ne s'agit pas de cas isolés. C'est le bilan officiel de ce qui se passe dans un environnement à haute valeur où la découverte de « failles » de red teaming est très bien récompensée et où le coût de l'exploitation est nul.

Le risque 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 de fait une invitation ouverte à trouver tout ce que son équipe interne a manqué — et si la base de code est mal auditée, cela pourrait bien concerner la quasi-totalité du système. Par exemple, un programme plafonné à 100 000 $ lancé contre 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 rendant le fonctionnement du protocole non sécurisé.

Imaginez ce scénario permettant de dire que de nombreux projets DeFi de la première heure se sont retrouvés à peu près dans cette situation : un programme de bug bounty est annoncé publiquement, et les signalements commencent à affluer, révélant que l'audit interne n'était qu'un simple survol ; cependant, les coûts de remédiation ont rapidement dépassé ce que l'équipe avait budgétisé pour l'ensemble de son approche sécuritaire. La morale de l'histoire n'est pas que les bug bounties sont risqués — c'est qu'ils supposent un standard 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 bounty pour remplacer un travail de sécurité interne de fond, plutôt que de s'y ajouter.

La prise en compte de ces enseignements a donné lieu à la séquence réelle suivante : revue interne, un ou plusieurs audits externes par des cabinets de confiance, puis mise en production avec un bug bounty permanent. D'autres intègrent une mesure supplémentaire de déploiement progressif — en plafonnant la valeur maximale à risque (VaR) du protocole pendant une durée déterminée tant que le bounty est actif, et en n'augmentant la liquidité qu'une fois qu'aucune faille critique n'est apparue. Cette approche est plus lente et souvent plus coûteuse que de simplement déployer le code. 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 et a été lancée en décembre 2020. Elle a désormais versé plus de 100 millions de dollars à des chercheurs pour plus de 3 000 rapports de bugs, et affirme avoir aidé à prévenir des pertes de plus de 25 milliards de dollars sur au moins 500 protocoles d'ici début 2026. La plateforme dessert une communauté d'environ 45 000 chercheurs en sécurité enregistrés, soutient des processus de divulgation structurés et sert d'intermédiaire dans les négociations entre chercheurs et protocoles concernant la classification de la sévérité et le montant des paiements.

Immunefi prélève une commission sur les primes versées, ce qui aligne raisonnablement leurs intérêts avec les deux extrémités du marché : ils sont plus performants lorsque les chercheurs découvrent de véritables failles et que les protocoles les rémunèrent.

La plus importante récompense unique 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é dans le pont Wormhole. Cette vulnérabilité aurait pu, si elle avait été exploitée, exposer des ressources verrouillées d'une valeur d'environ 736 millions de dollars. Le chercheur l'a divulguée de manière responsable et a reçu ce qui était, à l'époque, la plus importante prime de bug bounty jamais enregistrée. En décembre 2021, Polygon avait racheté une faille critique au chercheur Leon Spacewalker pour 2,2 millions de dollars, laquelle aurait pu permettre la frappe de jusqu'à 9,3 milliards de jetons MATIC — ce qui équivalait à des milliards de dollars aux cours de l'époque. Le calcul est sans appel dans les deux sens : la prime était élevée en termes absolus, mais dérisoire par rapport à ce qui aurait pu être perdu si les attaques n'avaient pas été évitées.

Les programmes d'incitation dédiés, gérés au niveau des protocoles, atteignent désormais des montants qu'il aurait été difficile d'imaginer il y a seulement quelques années. La récompense maximale s'élève à 15,5 millions de dollars pour les vulnérabilités critiques dans le cadre du programme v4 d'Uniswap. LayerZero propose des primes ouvertes de 15 millions de dollars. En 2026, la récompense maximale de la Fondation Ethereum a été portée à 1 million de dollars.

Non seulement ces chiffres doivent être corrélés à la valeur de ce que ces protocoles tentent de sécuriser, mais ils doivent également être proportionnels au calibre des chercheurs dont vous souhaitez attirer l'attention — un plafond de 1 000 $ n'incitera pas quelqu'un capable d'exploiter une vulnérabilité critique dans un protocole se chiffrant en milliards de dollars.

Code4rena et Sherlock sont légèrement différents : vous organisez un concours d'audit compétitif dans un laps de temps défini, plusieurs chercheurs inspectent la base de code simultanément et perçoivent des parts de cagnottes totales en fonction de la gravité et de la validité de leurs découvertes. Avec une communauté de plus de 8 300 auditeurs inscrits et plus de 24 000 découvertes uniques sur l'ensemble des audits Code4rena. Plus de 175 concours de ce type ont été organisés par Sherlock. Un format compétitif modifie la structure d'incitation ; les chercheurs sont encouragés à rechercher des problèmes que d'autres pourraient ignorer, car les découvertes signalées en grand nombre ne reçoivent souvent qu'une faible récompense, voire aucune. En général, cela révèle également des problèmes à une échelle plus vaste que ce que les audits séquentiels ou les programmes de bounty ouverts peuvent traiter séparément. 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 du bug bounty dans le Web3, plus de 162 millions de dollars de primes sont désormais proposés au cas où les choses ne se passeraient pas comme prévu, ce qui représente à la fois l'ampleur des enjeux et un indicateur de la voie de professionnalisation empruntée par de nombreux chercheurs.

Analyser l'artisanat et pourquoi il ne s'agit pas d'argent facile

L'image du chasseur de primes (bug bounty hunter) qui découvre une vulnérabilité un après-midi et encaisse une récompense à six chiffres n'est pas confirmée par la réalité du travail. Les professionnels qui gagnent durablement leur vie en effectuant des recherches en sécurité dans l'espace crypto sont généralement des spécialistes, dont le parcours a nécessité de nombreuses années de préparation technique dans des domaines où la plupart des développeurs s'aventurent rarement.

Détecter les failles les plus critiques dans le code de contrats intelligents en production exige une expertise de l'Ethereum Virtual Machine (EVM) — il ne s'agit pas seulement de savoir écrire en Solidity, mais de comprendre en quoi le code est compilé, ce que l'EVM fait réellement lors de l'exécution du bytecode et quelles fonctionnalités du langage sont garanties ou même connues pour être exécutées par son compilateur, par opposition à leurs cas limites potentiels pouvant devenir des problèmes de sécurité lorsqu'ils sont associés à des choix d'optimisation du gas faits par des développeurs aux ressources limitées et soumis à des délais serrés. Cela nécessite non seulement une compréhension des classes de vulnérabilités courantes — réentrance, dépassement d'entier (integer overflow), manipulation de prêts flash (flash loans), manipulation de prix d'oracles, failles de contrôle d'accès, vulnérabilités d'initialisation — mais aussi la capacité de détecter de nouveaux vecteurs d'attaque ne correspondant à aucun schéma connu. Les découvertes les plus utiles sont celles que personne ne cherchait même à trouver.

La boîte à outils dont disposent les chercheurs pour ce travail a considérablement mûri et comprend désormais des outils qui, dans la plupart des cas, sont indiscernables de ceux qu'un acteur malveillant déploierait :

Slither, un framework d'analyse statique développé par Trail of Bits, peut analyser votre code Solidity par rapport à 40 schémas de vulnérabilité connus et vous fournir un rapport ordonné. 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 de la couche logique.

Mythril utilise l'exécution symbolique pour parcourir les états possibles d'un contrat et vérifie si un état atteignable viole certaines propriétés de sécurité spécifiées 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 va alors explorer des milliers de séquences de transactions aléatoires pour tenter de les briser. Nous excellons particulièrement dans la recherche de cas limites au sein de l'arithmétique et de la logique de gestion d'état.

La majorité des recherches sérieuses en sécurité sont désormais effectuées à l'aide de Foundry, car cet outil offre une transition très fluide entre « je pense que cela va fonctionner » et « je peux prouver que cela fonctionne », d'autant plus que la plupart des chercheurs écrivent leurs tests et leurs exploits directement en Solidity avec Foundry.

Grâce aux outils de vérification formelle de Certora, les chercheurs peuvent utiliser des spécifications de comportement de contrat sous forme de contrats mathématiques, puis les vérifier par rapport au bytecode réel. C'est la méthode la plus exigeante et aussi la plus difficile à mettre en œuvre, tant en termes de compétences que d'efforts.

Un autre outil de Trail of Bits, Manticore, effectue des analyses dynamiques et peut être utilisé pour générer automatiquement des entrées qui empruntent certains chemins de code dans le contrat — ce que l'analyse statique ne peut atteindre.

Aucun de ces outils ne permet de trouver automatiquement des vulnérabilités critiques de manière isolée. Ils restreignent l'espace des candidats potentiels et mettent en évidence ceux qu'un humain doit ensuite évaluer. Si un chercheur ne sait pas lire l'assembleur EVM, raisonner sur l'ordonnancement des transactions et comprendre l'économie d'un protocole DeFi au niveau systémique, il ne pourra pas tirer grand-chose des résultats de ces outils. Ces outils sont des amplificateurs d'expertise et non des substituts à celle-ci.

Ces difficultés pratiques vont bien au-delà de l'aspect technique. La compétition est intense. Lors d'un concours d'audit sur Code4rena ou Sherlock, des dizaines de développeurs étudient simultanément la même base de code.

En général, un seul chercheur revendique une découverte critique — tous les autres qui identifient le même problème ne reçoivent rien ou des miettes. Un chercheur qui consacre une semaine à un concours et ne trouve que des problèmes de sévérité moyenne peut repartir avec seulement quelques centaines de dollars. La variabilité des revenus est élevée et les périodes de creux sont bien réelles.

Cependant, prouver un résultat peut s'avérer aussi difficile que de le découvrir. Il faut effectuer une démonstration pratique de l'exploitabilité (généralement via une preuve de concept, ou PoC). Certains contestent parfois la classification de la sévérité d'une découverte critique ou moyenne, arguant que certains aspects en atténuent la portée. Les chercheurs qui ne documentent pas soigneusement leur travail, ainsi que ceux qui ne disposent pas de l'influence conférée par leur réputation, peuvent se retrouver sous-payés pour des découvertes importantes.

Enfin, l'environnement juridique et fiscal devient une complication en soi. La majorité des primes sont payées en cryptomonnaies — qu'il s'agisse d'USDT, d'USDC, d'ETH ou du jeton natif d'un protocole. Recevoir un transfert en USDT en tant que revenu constitue un événement imposable, obligeant le bénéficiaire à suivre la valeur lors de la réception avant de la convertir pour sa déclaration, et à déclarer des plus-values sur tout mouvement de prix si le paiement a été effectué via un actif numérique. Les bug bounties impliquent une réelle charge administrative — structurer une activité de bug bounty, comme pour toute entreprise, nécessite d'équilibrer les compromis entre le temps investi et les résultats tangibles — si vous ignorez l'aspect administratif, cela devient un problème supplémentaire qui s'aggrave silencieusement.

Mais le défi le plus profond réside dans le fait que ce travail possède un plafond très élevé mais un plancher de revenus nul. Un chercheur qui développe une véritable expertise avec un historique éprouvé — quelqu'un qui a découvert des vulnérabilités critiques de protocole, dont le nom apparaît dans des rapports d'audit ou des post-mortems — peut percevoir des revenus comparables aux salaires des ingénieurs seniors dans les grandes entreprises. Il faut soit une étrange prédisposition génétique de naissance, soit des années de perfectionnement d'un savoir-faire spécifique pour y parvenir. Presque tous ceux qui tentent d'en vivre exclusivement découvrent rapidement que le temps d'apprentissage est bien plus long que prévu, que la concurrence est mieux préparée qu'escompté et que, pendant la phase de formation, les revenus ne suffisent tout simplement pas à couvrir les dépenses.

Cela ne signifie pas nécessairement que c'est un mauvais domaine. Cela en fait un domaine honnête. L'ensemble des compétences qui permet à un chercheur en bug bounty de réussir — concentration technique approfondie, pensée systémique, créativité face à l'incertitude et volonté de travailler pendant des heures sur quelque chose qui pourrait ne rapporter aucun retour sur investissement — est précisément celui recherché par les professionnels de la sécurité dans tous les domaines. Une personne ayant développé ces compétences au niveau nécessaire pour la recherche en sécurité crypto est en mesure de choisir. L'une de ces carrières est la voie du bug bounty, et ce de plus en plus pour les rares personnes qui s'y engagent.

C'est une excellente nouvelle pour quiconque gère un flux de travail basé sur l'USDT — qu'il s'agisse de déterminer qui reçoit quelle prime, de répartir les paiements entre plusieurs collaborateurs ou simplement de transférer la récompense hors protocole. Le calculateur de transfert USDT de Netts fait exactement cela : saisissez les adresses de l'expéditeur et du destinataire et il vous indique précisément la quantité d'Énergie et de Bande passante nécessaire pour la transaction, ce qui est brûlé par rapport aux paramètres par défaut ou si les ressources existantes sont utilisées, ainsi qu'une comparaison des coûts pour un envoi vers une adresse détenant déjà de l'USDT (13,84 TRX contre 2-3 TRX pour de l'Énergie louée) ou vers une nouvelle adresse (27,70 TRX contre 4-5 TRX de ressources louées) — soit plus de 80 % d'économie dans les deux cas !