--- title: "Come funzionano i programmi di bug bounty crypto" description: "Un bug bounty crypto è un processo versionato di disclosure e ricompensa, nel quale ambito, autorizzazione, prove, gravità, rimedio, disclosure e pagamento vanno verificati separatamente." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Come funzionano i programmi di bug bounty crypto > 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 - [Audit di smart contract](/it/crypto/contract-audit/) - [Smart contract](/it/crypto/smart-contract/) - [Attacco di reentrancy](/it/crypto/reentrancy-attack/) ## Fonti - [Immunefi Rules](https://immunefi.com/rules/) - Immunefi (consultato: 2026-08-13) - [Immunefi Vulnerability Severity Classification System v2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/) - Immunefi (consultato: 2026-08-13) - [Binding Operational Directive 20-01](https://www.cisa.gov/sites/default/files/bod-20-01.pdf) - Cybersecurity and Infrastructure Security Agency (consultato: 2026-08-13) - [Department of Justice Announces New Policy for Charging Cases under the Computer Fraud and Abuse Act](https://www.justice.gov/archives/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act) - U.S. Department of Justice (consultato: 2026-08-13) - [Safe Harbor Overview & FAQ](https://docs.hackerone.com/en/articles/8494502-safe-harbor-overview-faq) - HackerOne (consultato: 2026-08-13) - [Bug Bounty Program](https://ethereum.org/bug-bounty/) - ethereum.org (consultato: 2026-08-13) - [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs (consultato: 2026-08-13) - [Secure Software Development Framework (SSDF) Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final) - National Institute of Standards and Technology (consultato: 2026-08-13) Source: https://wiki.fcontext.com/it/crypto/bug-bounty/index.mdx