Aller au contenu
Financial Context Wiki

Fonctionnement des programmes de bug bounty crypto

Un bug bounty crypto est un processus versionné de signalement et de récompense dont le périmètre, l'autorisation, les preuves, la gravité, la remédiation, la divulgation et le paiement doivent être audités séparément.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un bug bounty crypto est un processus versionné par lequel un projet invite à signaler confidentiellement certaines vulnérabilités et peut récompenser les rapports conformes à ses règles en vigueur. Il ne se confond pas avec une politique de divulgation des vulnérabilités, qui peut fournir un canal et des conditions d’autorisation sans promettre de paiement. Aucun des deux ne certifie la sécurité, n’assure le système ni ne crée de relation de travail.

L’objet de référence est un instantané daté du programme, pas le nom du projet ni sa page actuelle. Il faut conserver URL, révision et heure ; réseaux, contrats, implémentations de proxy, dépôts, commits et versions exacts ; impacts éligibles ; systèmes et méthodes exclus ; barème et plafond ; règles de soumission et de divulgation ; clause de protection ; conditions d’identité, de sanctions, de fiscalité et de paiement. Le périmètre est l’intersection de l’actif, la version, le réseau, l’impact et la méthode autorisée.

Une clause de protection indique comment l’organisation entend traiter une recherche de bonne foi conforme à ses règles. Elle n’élargit pas le périmètre, ne lie ni tiers ni autorités, ne prévaut pas sur d’autres juridictions et n’excuse ni atteinte à la vie privée, ni interruption, ni extorsion, ni mouvement de fonds non autorisé. En cas d’ambiguïté, il faut demander par le canal officiel avant de tester.

Tenez quatre registres distincts : autorisation et preuves ; exploitabilité technique et impact économique ; atténuation, remédiation et divulgation ; récompense, conformité et paiement. Le label critical ne fixe pas seul la récompense, une décision d’attribution n’est pas un reçu et la réussite d’un test unitaire ne prouve pas la sûreté du déploiement concerné.

Fonctionnement

Les tests doivent rester dans les règles archivées. Un PoC minimal progresse normalement de l’analyse statique et des tests unitaires ou de propriétés vers un fork local ou autre environnement expressément autorisé. Mainnet, testnet public, déni de service, ingénierie sociale, tiers ou données personnelles peuvent être interdits. Ne déplacez ni ne conservez de fonds réels pour démontrer l’impact et ne supposez pas qu’un bounty ordinaire autorise un sauvetage pendant une attaque.

Un rapport utile fixe le réseau, l’adresse, l’implémentation, le commit, le bloc d’état et l’instantané du programme. Il précise prérequis, reproduction exacte, résultats attendu et réel, suite de transactions ou calldata, empreintes des artefacts, chemin technique, limite réaliste d’impact, capital et privilèges de l’attaquant, hypothèses et contact sécurisé. Chiffrez les éléments exploitables et les données sensibles, minimisez la collecte, tracez les accès et conservez la chronologie.

Le triage sépare périmètre, doublon ou problème connu, exploitabilité, impact économique, gravité et éligibilité. Une catégorie technique ne détermine pas une perte exécutable. Capital, permissions, concurrence, liquidité, fenêtres d’oracle, limites, pauses, risque de réorganisation, répétabilité et interaction utilisateur modifient le résultat. Le premier message n’est pas nécessairement le premier rapport complet éligible ; la règle de doublon archivée et la preuve d’antériorité prévalent.

Accusé de réception, reproduction, décision de gravité, mesure d’urgence, remédiation finale, divulgation, approbation et paiement sont des états et horloges différents. Des objectifs comme 24 hours ou 72 hours n’ont de sens que s’ils figurent dans le programme ou le plan d’incident. Le silence nuit aux opérations, mais l’expression bug bounty ne crée aucun délai universel.

Une mesure d’urgence peut suspendre une fonction, abaisser une limite, retirer une route du frontend ou modifier la surveillance, mais ce n’est pas la correction finale. Une mise à niveau doit vérifier autorisation, timelock ou pouvoirs d’urgence, implémentation et initialiseur, disposition du stockage, migration et retour arrière. Transformez le PoC en test de régression, examinez chemins et invariants voisins, simulez l’état déployé, vérifiez les reçus et surveillez chaque version affectée.

La divulgation exige canal privé, début d’embargo, fréquence des mises à jour, règles de prolongation et de publication urgente, crédit ou anonymat, conservation ou suppression des preuves. Le paiement exige sa propre conciliation : montant nominal, formule ou discrétion, devise et cours de référence, KYC ou sanctions, documents fiscaux ou retenue, réseau et adresse, frais, approbation, identifiant de transaction et montant reçu.

Suivez ce processus :

  1. Archivez URL, révision, heure, actifs, réseaux, adresses, implémentations, commits, impacts, exclusions, récompenses, protection et politique de divulgation.
  2. Obtenez une autorisation écrite pour l’acteur, le système, l’environnement, la méthode, le débit, les données et les tiers ; arrêtez-vous et demandez si un point est ambigu.
  3. Construisez le plus petit PoC non dommageable dans l’environnement autorisé ; fixez code et état, quantifiez prérequis et impact, puis arrêtez-vous dès que la preuve suffit.
  4. Soumettez par le canal sécurisé avec ID, heures, artefacts chiffrés, empreintes, reproduction, registre d’impact, hypothèses et historique des échanges.
  5. Déterminez périmètre et statut de doublon ou connu ; évaluez séparément exploitabilité, impact, gravité et éligibilité selon les règles archivées.
  6. Suivez séparément atténuation, correctif ou migration, revue de mise à niveau et stockage, régression et invariants, reçus, surveillance et divulgation coordonnée.
  7. Conciliez récompense, devise et cours, KYC, sanctions, fiscalité, réseau, adresse, frais et reçu ; conservez une piste auditable sans données sensibles inutiles.

Exemples

  • Le périmètre est plus étroit qu’une correspondance de noms. Le programme liste 12 assets. Le rapport en cite 9 ; seuls 7 correspondent au réseau et à la version, un autre est un oracle tiers et le dernier un commit non publié. Correspondance : 9 / 12 = 75% ; couverture autorisée : 7 / 12 = 58.33333333%. L’instantané, pas le pourcentage, décide.
  • Impact, gravité et récompense candidate sont distincts. La valeur directe reproductible exposée vaut $8,000,000. Une règle hypothétique archivée verse 10%, avec plancher de $50,000 et plafond de $500,000. Calcul brut : $8,000,000 * 0.10 = $800,000 ; après plafond : $500,000. Une condition de signataire privilégié peut changer le niveau ; ce calcul n’est ni un droit ni une formule universelle.
  • Chaque horloge mesure un état différent. Soumission 2026-08-13 09:00 ; accusé à 11:30 en 2.5 hours ; triage 2026-08-14 16:00 en 31 hours ; limite temporaire à 21:00 en 36 hours ; correctif 2026-08-16 21:00 en 84 hours ; divulgation 2026-08-23 09:00 en 240 hours, soit 10 days. Un accusé rapide n’implique ni remédiation ni paiement rapides.
  • Récompense nominale et règlement sont séparés. $500,000 payés en USDC à $1.002 per USDC donnent $500,000 / $1.002 = 499,001.996008 USDC. Si le projet règle séparément $18 de frais, le chercheur reçoit 499,001.996008 USDC ; s’il les déduit, la valeur reçue est $499,982. Fiscalité et retenues restent des écritures distinctes.

Risques

  • La page change sans instantané daté.
  • Actif, version, réseau, adresse ou implémentation sont hors périmètre.
  • Une mise à niveau du proxy change le code pendant recherche ou remédiation.
  • La clause de protection est prise pour une immunité universelle.
  • Le test atteint un fournisseur, oracle, utilisateur ou tiers exclu.
  • Une activité mainnet ou testnet public enfreint les règles.
  • Le PoC déplace des fonds, interrompt un service ou accède à des données personnelles.
  • L’automatisation dépasse les limites ou devient un déni de service.
  • Ingénierie sociale, phishing, coercition ou extorsion dépassent l’autorisation.
  • Le PoC collecte ou expose plus de matériel exploitable que nécessaire.
  • Un canal non sécurisé divulgue secrets, données ou détails d’exploitation.
  • Empreintes, heures, versions ou état du réseau ne sont pas reproductibles.
  • Doublon, antériorité ou premier rapport éligible manquent de preuve.
  • Le nom de la faille ancre la gravité sans tester prérequis et accessibilité.
  • La valeur théorique exposée est confondue avec perte ou bénéfice réalisable.
  • Plancher, plafond, discrétion, devise ou éligibilité sont mal interprétés.
  • KYC, sanctions, fiscalité, facture ou réseau bloquent le règlement.
  • Silence, horloges ambiguës ou divulgation précoce accroissent le risque.
  • Pause, limite, mise à niveau, stockage ou migration causent un nouveau dommage.
  • Bounty, audit, preuve formelle ou surveillance sont traités comme une garantie.

Idées reçues

  • « Un programme public autorise tout actif et toute méthode connexes. » L’autorisation est limitée par actif, version, impact, environnement et conduite archivés.
  • « La clause de protection garantit l’immunité partout. » C’est une politique conditionnelle qui ne lie pas tous les tiers ni autorités.
  • « Critical ou un pourcentage fixe automatiquement le paiement. » Gravité, éligibilité, règles, plafonds, discrétion et règlement restent distincts.
  • « Le premier message gagne toujours et déplacer des fonds prouve l’impact. » Le premier rapport complet éligible peut compter ; un dommage non autorisé peut disqualifier et engager la responsabilité.
  • « Bounty et audit prouvent l’absence de faille après les tests. » Audits, méthodes formelles, tests, bounties, surveillance et réponse couvrent des versions, hypothèses et défaillances différentes.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...