> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Bug bounty > Il programma di divulgazione coordinata di Intention per i ricercatori di sicurezza: perimetro, classificazione di gravità, fasce di ricompensa, regole di ingaggio e come inviare una segnalazione. Questa pagina è la porta d'ingresso per i ricercatori di sicurezza. Il programma di divulgazione coordinata di Intention esiste per trovare e correggere le vulnerabilità del protocollo prima che vengano usate contro le persone che ci operano sopra. Vogliamo che ricercatori seri guardino ogni livello del sistema, dal kernel deterministico che esegue gli ordini ai contratti del bridge che detengono il collaterale, e siamo disposti a pagare di conseguenza quando trovano qualcosa di reale. Il programma è in via di formalizzazione. Il quadro, il perimetro, il modello di gravità e il processo di invio descritti in questa pagina sono la struttura di lavoro che entrerà in vigore con il primo rilascio di mainnet sottoposto ad audit. Gli importi specifici delle ricompense sono indicati come preliminari finché il programma non apre ufficialmente, ma la struttura è stabile, e **ogni segnalazione legittima divulgata in modo responsabile nel periodo precedente al lancio sarà riconosciuta secondo il quadro descritto in questa pagina**. Le fasce di ricompensa qui sotto sono preliminari e saranno sostituite dai valori definitivi quando il programma sarà lanciato insieme al primo rilascio sottoposto ad audit. Il perimetro, il modello di gravità e le regole di invio non sono preliminari: sono le regole da seguire oggi.

Perimetro

In perimetro

Tutto ciò che un attore malintenzionato potrebbe usare per rubare fondi degli utenti, sospendere il protocollo, corrompere lo stato definitivo o violare le proprietà da cui dipende l'architettura — [esecuzione](/it/protocol/architecture/kernel) riproducibile, [prezzi certificati nel blocco che li consuma](/it/protocol/architecture/oracle), [rischio che gira atomicamente con il matching](/it/protocol/architecture/clearinghouse) o [cambiamenti di stato riconducibili alla transazione che li ha causati](/it/protocol/architecture/state/model) — è in perimetro per impostazione predefinita. In concreto: * **[IntentionKernel](/it/protocol/architecture/kernel)** — semantica di esecuzione, insieme di istruzioni a mondo chiuso, disciplina di sequenziamento, determinismo a livello di byte. Qualsiasi cosa che permetta all'esecuzione di un validatore di divergere da quella di un altro, o a una transazione di produrre un effetto non previsto dalla specifica del protocollo. * **[IntentionBFT](/it/protocol/architecture/intention-bft)** — safety e liveness del consenso, elezione del leader, impegni sul sequenziamento canonico, aggregazione delle firme e il percorso di migrazione post-quantistica. * **[Oracolo e quorum sui prezzi](/it/protocol/architecture/oracle)** — invio delle osservazioni, scarto degli outlier basato sulla MAD, l'involucro del prezzo certificato, e qualsiasi percorso che permetta a una transazione di leggere un prezzo non consolidato nello stesso evento di consenso. * **[Bridge cross-chain](/it/protocol/architecture/bridge)** — il flusso di deposito e prelievo attestato dai validatori, i contratti on-chain del bridge sulle catene di destinazione supportate, il processo di firma a soglia e di gestione delle chiavi, e i controlli operativi che li circondano. * **Motore di negoziazione** — matching, calcolo del prezzo mark, cascate di liquidazioni, fondo assicurativo, ADL, regolamento del funding e la pipeline di rischio nativa del protocollo. * **Interfacce API pubbliche** — endpoint REST e WebSocket, autenticazione, firma, rate limit e qualsiasi percorso di codice raggiungibile da internet. * **Software del validatore** — il binario del nodo, la gestione delle chiavi, il trasporto peer-to-peer e qualsiasi strumento operativo che un validatore esegue in produzione.

Fuori perimetro

Le categorie seguenti sono escluse esplicitamente dal programma di bounty. Le segnalazioni contro questi bersagli riceveranno riscontro ma non danno diritto a una ricompensa. * Attacchi denial-of-service volumetrici contro l'infrastruttura dei validatori o gli endpoint RPC pubblici. La difesa da questi sta nella mitigazione operativa al bordo della rete, non nelle patch al protocollo. * Problemi in software, dipendenze o servizi di terze parti che Intention non controlla. * Segnalazioni che dipendono dall'accesso fisico all'hardware dei validatori, dall'ingegneria sociale contro dipendenti di Intention Labs o da attacchi alla catena di fornitura degli strumenti che il team usa internamente. * Self-XSS, content spoofing senza impatto di sicurezza, header di sicurezza mancanti e altri problemi a basso impatto contro il sito di marketing o questo sito di documentazione. * Bug in software formalmente dismesso e non più in esecuzione su alcun validatore né in alcun servizio di produzione. * Attacchi teorici che richiedono precondizioni improbabili (per esempio la compromissione del 51% dello stake onesto) senza un percorso concreto per innescarle.

Classificazione di gravità

Le segnalazioni sono valutate su una scala a quattro livelli. Il livello è determinato dalla combinazione di **impatto** (che cosa può ottenere un attaccante) e **probabilità** (quanto è realistico lo scenario d'attacco, incluse precondizioni e risorse necessarie). Il valore a rischio è il fattore d'impatto dominante per ogni segnalazione che tocca fondi degli utenti. | Livello | Che cosa significa | Esempi rappresentativi | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Critica** | Furto diretto, perdita permanente o conio non autorizzato di fondi degli utenti; violazione della safety del consenso; falsificazione dell'oracolo che può essere resa persistente. | Un percorso attraverso il kernel che permette a una transazione di accreditare un conto senza averlo pagato. Un difetto nell'aggregazione delle firme che permette a `$f$` validatori di consolidare un blocco. Un prelievo dal bridge che conia token sulla catena di destinazione senza un corrispondente lock di fondi. | | **Alta** | Perdita limitata a un sottoinsieme di utenti o a un mercato specifico; arresto della liveness del consenso; attacchi di griefing al bridge; liquidazione forzata mirata. | Un percorso del motore di liquidazione che può essere innescato contro una posizione specifica senza una reale violazione del margine. Una macchina a stati del bridge che si può incastrare al punto da fermare l'elaborazione dei prelievi per una catena. Escalation di privilegi contro il software del validatore, al di sotto della compromissione del consenso. | | **Media** | Nessuna perdita diretta di fondi, ma una violazione significativa delle garanzie di protocollo o dell'integrità operativa. | Lettura non autorizzata di stato che dovrebbe essere privato. Un aggiramento del rate limit che alza in modo rilevante il costo di far girare la catena. Un modo per far emettere allo [stream di esecuzione](/it/help/glossary) eventi incoerenti con lo stato definitivo. | | **Bassa** | Problemi a impatto limitato, senza percorso verso una perdita di fondi o un'interruzione del consenso. | Divulgazione di informazioni senza impatto. Risposte d'errore incoerenti sull'API pubblica. Problemi operativi minori senza percorso di exploit. | La gravità è decisa dal team di sicurezza di Intention insieme a chi ha segnalato. Il team motiverà per iscritto il livello assegnato a ogni segnalazione, e chi segnala può contestarlo portando nuove prove.

Fasce di ricompensa

Tutte le ricompense del programma sono pagate in **USDC** su un indirizzo di wallet indicato da chi segnala. Non è coinvolto alcun token nativo. | Livello | Fascia di ricompensa preliminare | | ------- | ------------------------------------ | | Critica | `TBD — high five to six figures` | | Alta | `TBD — mid four to low five figures` | | Media | `TBD — low four figures` | | Bassa | `TBD — symbolic / swag` | Le fasce sono segnaposto finché il programma non apre. La matrice definitiva sarà pubblicata in questa pagina quando uscirà il primo rilascio sottoposto ad audit. Alcune regole valgono per ogni pagamento: * **Un bounty per ogni vulnerabilità distinta.** Se la stessa causa radice produce più segnalazioni, il team le accorpa in un unico riconoscimento alla gravità più alta applicabile. * **Vince chi segnala per primo.** Le segnalazioni duplicate di un problema già in triage ricevono riscontro ma non ricompensa. * **Nessuna ricompensa per problemi già noti.** Le segnalazioni che coincidono con voci già presenti nel backlog interno del team di sicurezza, o già coperte da un audit pubblicato, non danno diritto a ricompensa. Quando succede, il team condivide il riferimento pertinente. * **La ricompensa dipende dalla collaborazione.** La divulgazione pubblica prima della correzione, un exploit che vada oltre un proof of concept minimo, o qualsiasi danno agli utenti fanno decadere la ricompensa.

Regole di ingaggio

I ricercatori che partecipano al programma accettano i vincoli seguenti. Esistono per proteggere gli utenti, per proteggere gli altri ricercatori e per mantenere il programma sostenibile per Intention. * **Niente test in produzione con fondi reali degli utenti.** Usa la testnet pubblica (quando sarà attiva) o un fork privato. Se una segnalazione è riproducibile solo in produzione, contatta prima `contact@intention.xyz` e non eseguire il proof of concept finché il team di sicurezza non ha dato riscontro alla richiesta. * **Niente ingegneria sociale.** Non prendere di mira dipendenti, collaboratori, validatori o partner di Intention Labs con phishing, pretexting o altri attacchi sociali. * **Niente attacchi volumetrici.** Nessun denial-of-service per saturazione del traffico, nessun attacco di esaurimento delle risorse contro infrastrutture condivise. * **Solo un proof of concept minimo.** Dimostra l'impatto con l'azione più piccola possibile. Non esfiltrare dati degli utenti, non spostare fondi oltre l'importo necessario a provare il problema, e non mantenere accesso al sistema dopo aver completato il proof of concept. * **Niente divulgazione pubblica prima della correzione.** La divulgazione coordinata è la regola di base. Una volta distribuita la correzione, il team di sicurezza concorderà con te i tempi della divulgazione pubblica. * **Rispetta la legge applicabile.** Le clausole di safe harbor qui sotto valgono per la ricerca condotta in buona fede secondo queste regole. Le attività che violano le norme sui reati informatici in una qualsiasi giurisdizione rilevante non sono protette.

Come inviare una segnalazione

Una segnalazione completa contiene: una descrizione scritta e chiara della vulnerabilità, il componente e la versione interessati, la riproduzione passo per passo, un proof of concept minimo (codice o hash di transazione), l'impatto che ritieni abbia il problema, ed eventuali proposte di correzione. Più la segnalazione è chiara, più veloce è il triage. Manda la segnalazione via email a `contact@intention.xyz` con **Security** nell'oggetto. Una chiave PGP per gli invii cifrati sarà pubblicata al lancio del programma; fino ad allora manda la prima email in chiaro e il team sposterà i dettagli sensibili su un canale cifrato al primo scambio. Non pubblicare alcuna parte della segnalazione prima che il team abbia dato riscontro. Il team di sicurezza dà riscontro a ogni invio entro due giorni lavorativi. Il riscontro conferma la ricezione, chiede le informazioni eventualmente mancanti e assegna un responsabile del triage. Se dopo 72 ore non hai ricevuto riscontro, invia di nuovo. Le segnalazioni convalidate passano alla correzione. Il team di sicurezza lavora con i responsabili tecnici competenti per rilasciare una correzione, e aggiorna chi ha segnalato con cadenza regolare. Il team può chiedere chiarimenti o ulteriori passi di riproduzione; le risposte arrivano di norma entro un giorno lavorativo. Una volta distribuita la correzione e reso il problema non più sfruttabile, la ricompensa viene pagata in USDC all'indirizzo fornito da chi ha segnalato. Chi ha segnalato viene citato nel post-mortem e in ogni divulgazione successiva, previa sua autorizzazione. I post-mortem completi vengono pubblicati quando farlo non espone gli utenti a un rischio residuo. ## Safe harbor La ricerca di sicurezza condotta in buona fede nel rispetto delle regole qui sopra non sarà perseguita legalmente da Intention Labs. L'impegno di safe harbor copre i ricercatori che: * Restano dentro il perimetro e le regole di ingaggio di questa pagina * Non accedono, non modificano e non distruggono dati degli utenti oltre lo stretto necessario a dimostrare l'impatto * Segnalano in privato e rispettano i tempi della divulgazione coordinata * Non sfruttano le segnalazioni per profitto personale né per qualsiasi scopo estraneo al programma di bounty Le attività che escono da queste regole — per esempio esfiltrare i saldi degli utenti, tenere in ostaggio una segnalazione a scopo di riscatto, o rendere tutto pubblico prima della correzione — non sono coperte dal safe harbor e possono portare ad azioni legali a prescindere dalla validità della segnalazione. Il testo legale specifico accompagnerà il lancio formale del programma e sarà collegato da questa pagina. Il programma di bounty non è ancora formalmente aperto. Segnala comunque tutto ciò che trovi. Ogni segnalazione legittima divulgata in modo responsabile nel periodo precedente al lancio sarà riconosciuta secondo il quadro descritto in questa pagina, e chi segnala sarà pagato secondo la stessa matrice quando il programma partirà.

Contatti

**Email:** `contact@intention.xyz`. Metti **Security** nell'oggetto per una segnalazione di vulnerabilità; tutto il resto — richieste di assistenza, stampa, partnership o domande sul programma che non siano segnalazioni — va allo stesso indirizzo, senza. Grazie per il tempo che dedichi a guardarci dentro. Il protocollo è migliore grazie a ogni ricercatore onesto che lo legge.