Vai al contenuto
Financial Context Wiki

Come funzionano i programmi di bug bounty crypto

Un bug bounty crypto è un processo versionato di disclosure e ricompensa, nel quale ambito, autorizzazione, prove, gravità, rimedio, disclosure e pagamento vanno verificati separatamente.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Un bug bounty crypto è un processo versionato con cui un progetto invita a segnalare privatamente determinate vulnerabilità e può premiare i report conformi alle regole vigenti. Non coincide con una vulnerability disclosure policy, che può offrire un canale e condizioni di autorizzazione senza promettere un pagamento. Nessuno dei due certifica la sicurezza, assicura il sistema o crea un rapporto di lavoro.

Fa fede una copia datata del programma, non il nome del progetto o la pagina odierna. Vanno registrati URL, revisione e ora; chain, contratti, implementazioni proxy, repository, commit e release esatti; impatti ammessi; sistemi e metodi esclusi; tabella e massimale; regole di invio e disclosure; safe harbor; condizioni di identità, sanzioni, fisco e pagamento. L’ambito è l’intersezione tra asset, versione, chain, impatto e metodo autorizzato.

Il safe harbor esprime come l’organizzazione intende trattare una ricerca in buona fede conforme alle regole. Non amplia l’ambito, non vincola terzi o autorità, non prevale su altre giurisdizioni e non giustifica violazioni della privacy, interruzioni, estorsioni o movimenti di fondi non autorizzati. In caso di dubbio, occorre chiedere sul canale ufficiale prima di testare.

Servono quattro registri distinti: autorizzazione e prove; sfruttabilità tecnica e impatto economico; mitigazione, rimedio e disclosure; ricompensa, conformità e pagamento. L’etichetta critical non determina da sola la ricompensa, l’approvazione non è una ricevuta e un singolo unit test superato non prova che il deployment sia sicuro.

Come funziona

I test devono rispettare le regole archiviate. Un PoC minimo procede normalmente da analisi statica e test unitari o property-based a un fork locale o altro ambiente espressamente autorizzato. Mainnet, testnet pubblica, denial-of-service, social engineering, sistemi terzi o dati personali possono essere vietati. Non si spostano né trattengono fondi reali per dimostrare l’impatto e un bounty ordinario non autorizza un salvataggio durante un attacco.

Un report utile fissa chain, indirizzo, implementazione, commit, blocco di stato e snapshot del programma. Indica prerequisiti, riproduzione, risultato atteso e reale, sequenza di transazioni o calldata, hash degli artefatti, percorso tecnico, limite realistico dell’impatto, capitale e privilegi dell’attaccante, ipotesi e contatto sicuro. Materiale sfruttabile e dati sensibili vanno cifrati, minimizzati e tracciati cronologicamente.

Il triage separa ambito, duplicato o problema noto, sfruttabilità, impatto economico, gravità e idoneità alla ricompensa. Una classe tecnica non determina la perdita eseguibile. Capitale, permessi, concorrenza, liquidità, finestre oracle, limiti, pause, reorg, ripetibilità e interazione utente possono cambiare l’esito. Il primo messaggio non è necessariamente il primo report completo idoneo: valgono la regola sui duplicati salvata e le prove di conoscenza pregressa.

Ricezione, riproduzione, decisione di gravità, mitigazione urgente, rimedio finale, disclosure, approvazione e pagamento sono stati e orologi diversi. Obiettivi come 24 hours o 72 hours valgono solo se definiti dal programma o dal piano d’incidente. Il silenzio è dannoso, ma non esiste un termine universale implicito nel bug bounty.

Una misura urgente può sospendere una funzione, ridurre un limite, rimuovere una rotta frontend o cambiare il monitoraggio, ma non è il rimedio finale. Un upgrade deve verificare autorizzazione, timelock o poteri d’emergenza, implementazione e initializer, storage layout, migrazione e rollback. Il PoC diventa un test di regressione; vanno verificati percorsi adiacenti, invarianti, stato distribuito, ricevute e versioni su ogni chain.

La disclosure richiede canale privato, inizio embargo, cadenza degli aggiornamenti, proroga e pubblicazione urgente, credito o anonimato, conservazione o cancellazione delle prove. Il pagamento richiede una riconciliazione propria: importo nominale, formula o discrezionalità, valuta e cambio, KYC o sanzioni, documenti fiscali o ritenuta, chain e indirizzo, commissioni, approvazione, ID della transazione e importo ricevuto.

Procedura:

  1. Salvare URL, revisione, ora, asset, chain, indirizzi, implementazioni, commit, impatti, esclusioni, premi, safe harbor e policy di disclosure.
  2. Ottenere autorizzazione scritta per soggetto, sistema, ambiente, metodo, frequenza, dati e confine con terzi; fermarsi e chiedere se qualcosa è ambiguo.
  3. Creare il PoC non dannoso più piccolo nell’ambiente ammesso; fissare codice e stato, quantificare prerequisiti e impatto e fermarsi quando la prova basta.
  4. Inviare sul canale sicuro con ID, orari, artefatti cifrati, hash, riproduzione, registro d’impatto, ipotesi e cronologia dei contatti.
  5. Determinare ambito e stato di duplicato o noto; valutare separatamente sfruttabilità, impatto, gravità e idoneità secondo le regole salvate.
  6. Tracciare separatamente mitigazione, patch o migrazione, verifica upgrade e storage, regressioni e invarianti, ricevute, monitoraggio e disclosure coordinata.
  7. Riconciliare premio, valuta e cambio, KYC, sanzioni, fisco, chain, indirizzo, commissioni e ricevuta; conservare una traccia verificabile senza dati superflui.

Esempi

  • L’ambito è più stretto della corrispondenza dei nomi. Il programma elenca 12 assets; il report ne cita 9, ma solo 7 coincidono con chain e versione, mentre uno è un oracle terzo e uno un commit non rilasciato. Corrispondenza: 9 / 12 = 75%; copertura autorizzata: 7 / 12 = 58.33333333%. Decide lo snapshot, non la percentuale.
  • Impatto, gravità e premio candidato sono distinti. Valore diretto riproducibile: $8,000,000. Una regola ipotetica paga 10%, con minimo $50,000 e massimo $500,000. Calcolo lordo: $8,000,000 * 0.10 = $800,000; dopo il cap: $500,000. Un requisito di firma privilegiata può cambiare livello; non è un diritto né una formula universale.
  • Ogni orologio misura uno stato. Invio 2026-08-13 09:00; conferma 11:30 in 2.5 hours; triage 2026-08-14 16:00 in 31 hours; limite temporaneo 21:00 in 36 hours; patch 2026-08-16 21:00 in 84 hours; disclosure 2026-08-23 09:00 in 240 hours, cioè 10 days. Conferma rapida non significa rimedio o pagamento rapido.
  • Premio nominale e regolamento sono separati. $500,000 pagati in USDC a $1.002 per USDC danno $500,000 / $1.002 = 499,001.996008 USDC. Se il progetto paga separatamente $18 di rete, il ricercatore riceve 499,001.996008 USDC; se li deduce, il valore ricevuto è $499,982. Imposte e ritenute restano voci separate.

Rischi

  • La pagina cambia senza snapshot datato.
  • Asset, versione, chain, indirizzo o implementazione sono fuori ambito.
  • Un upgrade proxy modifica il codice durante ricerca o rimedio.
  • Il safe harbor è scambiato per immunità universale.
  • Il test raggiunge fornitori, oracle, utenti o terzi esclusi.
  • Mainnet o testnet pubblica violano le regole dell’ambiente.
  • Il PoC muove fondi, interrompe servizi o accede a dati personali.
  • L’automazione supera i limiti o diventa denial-of-service.
  • Social engineering, phishing, coercizione o estorsione eccedono l’autorizzazione.
  • Il PoC raccoglie o espone materiale sfruttabile non necessario.
  • Un canale insicuro perde segreti, dati o dettagli dell’exploit.
  • Hash, orari, versioni o stato della chain non sono riproducibili.
  • Mancano prove su duplicato, conoscenza pregressa o primo report idoneo.
  • Il nome della vulnerabilità condiziona la gravità senza verificarne la portata.
  • Valore teorico è confuso con perdita realizzabile o profitto dell’attaccante.
  • Minimo, massimo, discrezione, valuta o idoneità sono interpretati male.
  • KYC, sanzioni, fisco, fattura o chain di pagamento bloccano il regolamento.
  • Silenzio, orologi ambigui o disclosure precoce aumentano il rischio.
  • Pausa, limite, upgrade, storage o migrazione causano nuovo danno.
  • Bounty, audit, prova formale o monitoraggio sono trattati come garanzia.

Errori comuni

  • «Un programma pubblico autorizza ogni asset e metodo correlato». L’autorizzazione è limitata da asset, versione, impatto, ambiente e condotta salvati.
  • «Il safe harbor garantisce immunità ovunque». È una policy condizionata e non vincola ogni terzo o autorità.
  • «Critical o una percentuale fissano il pagamento». Gravità, idoneità, regole, cap, discrezione e regolamento sono distinti.
  • «Il primo messaggio vince sempre e spostare fondi prova l’impatto». Può contare il primo report completo idoneo; un danno non autorizzato può squalificare e creare responsabilità.
  • «Bounty e audit provano l’assenza di bug dopo i test». Audit, metodi formali, test, bounty, monitoraggio e risposta coprono versioni, ipotesi e guasti diversi.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...