Sicurezza in Blockchain0x.
I pagamenti degli agenti muovono denaro reale. Le scelte architettoniche che proteggono i fondi dei clienti, la postura di audit attuale e come contattarci se trovi qualcosa di sbagliato.
Cosa puoi aspettarti da questa pagina.
Siamo un'azienda in fase iniziale che sta rilasciando infrastrutture a cui i clienti affideranno l'autorizzazione ai pagamenti. La fiducia si costruisce su ciò che puoi verificare, non su ciò che ti viene detto. Questa pagina documenta quattro aspetti che clienti e ricercatori di sicurezza possono verificare o su cui possono chiamarci a rispondere: le garanzie architetturali che restano valide anche se sbagliamo su tutto il resto, lo stato attuale della nostra postura di audit (incluso ciò che non abbiamo ancora fatto), l'ambito della nostra policy di divulgazione delle vulnerabilità e ciò che riceve esattamente chi segnala un problema (riconoscimento, non denaro), e il canale di contatto per una divulgazione responsabile.
What this page is not: a marketing surface designed to look maximally serious about security. We did not invent security certifications we do not hold, did not list "compliance" with frameworks we have not audited against, and did not put trust badges on the page that we did not earn. When we have a SOC 2 attestation or a third-party penetration test report, those will be referenced here with the auditing firm, the date, and the scope. Until then, this page says so plainly.
Quattro proprietà che si mantengono per costruzione.
Le garanzie di seguito sono architettoniche - sono proprietà di come il sistema è costruito, non di come viene operato. La sicurezza operativa può venire meno (una chiave trapelata, un deploy mal configurato); le garanzie architettoniche non dipendono dal fatto che le operazioni quotidiane siano perfette. Queste sono le parti della storia di sicurezza su cui puoi contare anche nella peggiore settimana di operazioni.
Non-custodial a livello di piattaforma
Blockchain0x non detiene fondi dei clienti. I portafogli sono di proprietà dell'agente (o del fornitore di custodia sottostante a cui il cliente si è connesso, come Circle Programmable Wallets o Coinbase Smart Wallet). Il servizio Blockchain0x gestisce la superficie di sviluppo sopra quei portafogli - API, dashboard, identità, politica di spesa - e non ha mai autorità di firma sui saldi.
Politica di spesa applicata lato server, non nell'agente
I limiti giornalieri, i tetti per pagamento, le liste di autorizzazione delle controparti e le finestre temporali sono valutati dall'API del wallet Blockchain0x su ogni intento di pagamento prima della liquidazione. Il runtime dell'agente non può accedere allo storage delle politiche; un agente che riceve un'iniezione di prompt non può comunque aumentare i propri limiti.
Conferma di pagamento con ricevuta validata
Le ricevute di pagamento fornite dall'API vengono convalidate lato server rispetto alla transazione di emissione prima di confermarle. Un client non può falsificare una ricevuta localmente e presentarla come prova di pagamento; il passaggio di convalida della ricevuta è lo stesso modello di fiducia utilizzato dalle firme webhook di Stripe.
Firme del webhook, non segreti condivisi negli URL
Ogni evento webhook che emettiamo è firmato con HMAC-SHA256 sul corpo grezzo utilizzando un segreto di firma per inquilino. Il segreto di firma non viene mai inviato nell'URL o nella stringa di query. I clienti verificano le firme al ricevimento; forniamo implementazioni di riferimento nella documentazione.
Dove siamo oggi, onestamente.
The table below is the current state of external audits, third-party reviews, and certifications. We update this page when any line changes - dates are real, scopes are real, and "planned" means scheduled with a firm, not aspirational.
Test di penetrazione di terze parti
Pianificato per il Q4 2026Il primo test di penetrazione esterno è programmato per la seconda metà dell'anno. Ambito: web app, API pubbliche, superficie webhook, autenticazione dashboard. Il riepilogo completo del rapporto sarà pubblicato qui al termine.
SOC 2 Tipo I
Pianificato per il 2027Non siamo auditati SOC 2 oggi. La finestra di tempo onesta prevista per un'attestazione di Tipo I è la prima metà del 2027; il Tipo II segue dopo un periodo di osservazione di 6-12 mesi.
Audit di smart contract
Eredità da upstreamOggi non gestiamo smart contract proprietari. Le primitive on-chain sono Circle Programmable Wallets, Coinbase Smart Wallet e i contratti sottostanti Base / USDC, tutti corredati da propri report di audit indipendenti forniti dai team emittenti. Se e quando rilasceremo i nostri contratti (funzionalità di account abstraction), verranno sottoposti ad audit prima del deployment su mainnet.
Revisione annuale della sicurezza interna
In corsoRotazione segreta trimestrale, revisione della scansione delle dipendenze e audit dei controlli di accesso. La checklist di indurimento pre-lancio è documentata nella nostra [guida per proteggere il tuo portafoglio agente](/learn/guides/secure-your-agent-wallet) per i clienti; la versione interna la rispecchia.
Non gestiamo un bug bounty a pagamento.
Per essere completamente chiari: Blockchain0x non ha alcun programma bug bounty e non paga denaro, crypto-asset, crediti, swag o qualsiasi altra compensazione per vulnerabilità segnalate. Non ci sono livelli di gravità, non ci sono range di payout e non c'è alcuna negoziazione su questo - chiunque ti dica il contrario non ci sta citando. Preferiamo dirlo chiaramente piuttosto che lasciare che un ricercatore passi un weekend sui nostri sistemi aspettandosi un assegno che non esiste.
Quello che gestiamo è un processo di divulgazione coordinata non retribuito. Le segnalazioni vengono inviate alla nostra email di security e lette da una persona. Confermiamo ogni segnalazione via email e, per le vulnerabilità che confermiamo come valide, offriamo un certificato di divulgazione responsabile e, se lo desideri, il tuo nome o handle nel nostro elenco pubblico dei ringraziamenti. Questo è tutto ciò che offriamo oggi. Se dovesse cambiare, cambierà anche questa pagina.
In ambito
- Autenticazione e gestione delle sessioni nella dashboard o nell'API.
- Escalation dei privilegi tra workspace o agenti nello stesso account.
- Server-side request forgery, command injection o remote code execution nell'API.
- Bypass della firma del webhook o bypass della validazione della ricevuta.
- Bypass della policy di spesa che consente a un agente di spostare denaro al di fuori dei limiti configurati o della allowlist.
- Esposizione significativa di dati (transazioni di altri tenant, segreti, log di audit).
Fuori portata
- Self-XSS o attacchi che richiedono alla vittima di digitare o incollare input malevoli nella propria console.
- Segnalazioni che dipendono dal social engineering di personale o contractor.
- Le segnalazioni relative ai servizi di terze parti con cui Blockchain0x si integra (Coinbase, Circle, ecc) - devono essere indirizzate al programma della terza parte.
- Risultati contro endpoint di test (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia).
- Header di sicurezza mancanti senza un impatto dimostrato.
- Questioni teoriche senza una proof-of-concept funzionante.
| Cosa riceve chi segnala | Dettagli |
|---|---|
| Conferma via email | Ogni segnalazione riceve una risposta da una persona di [email protected], indipendentemente dal fatto che la segnalazione risulti valida o meno, oltre all'esito del triage non appena disponibile. |
| Certificato di divulgazione responsabile | Per vulnerabilità confermate, riproducibili e in ambito: un certificato firmato con il tuo nome (o handle), la classe del problema e la data di divulgazione. Rilasciato dopo il deploy della correzione. |
| Riconoscimento pubblico | Con il tuo permesso, il tuo nome o handle verrà aggiunto all'elenco dei riconoscimenti pubblicato in questa pagina una volta risolto il problema. Se preferisci, puoi restare anonimo - basta che ce lo dica. Subordinato alle condizioni di riservatezza riportate di seguito. |
| Ricompensa monetaria | Nessuna. Non paghiamo per vulnerabilità segnalate, a qualsiasi livello di gravità, e l'invio di un report non dà alcun diritto a un pagamento. |
Le valutazioni di validità sono effettuate dal responsabile engineering in conversazione con il founder e sono definitive. Il riconoscimento è riservato a segnalazioni confermate e riproducibili, rientranti nell'ambito; quando lo stesso problema viene segnalato più di una volta, il credito va al primo segnalatore. Non richiediamo un NDA per inviare una segnalazione e le condizioni riportate di seguito sono gli unici vincoli.
Condizioni legate al riconoscimento
Il certificato di divulgazione responsabile e il riconoscimento pubblico sono entrambi subordinati al fatto che tu mantenga riservato il report. Non pubblicare la vulnerabilità, il report o alcun suo dettaglio - passaggi di riproduzione, codice proof-of-concept, screenshot, endpoint interessati o la nostra corrispondenza in merito - in nessun mezzo. Ciò include post sul blog, articoli, post testuali o con immagini su qualsiasi social network o forum, video, audio, podcast, interventi a conferenze, newsletter, gruppi di chat e derivati generati dall'AI di quanto sopra. Se vuoi pubblicare dopo il rilascio della correzione, chiedicelo prima e di solito concorderemo per iscritto una data e un livello di dettaglio. Pubblicare senza tale accordo scritto comporta la perdita del certificato e del riconoscimento, e ci riserviamo ogni altro rimedio a nostra disposizione.
Separatamente, e senza eccezioni: qualsiasi tentativo di estorcere denaro o di ricattarci in qualsiasi forma - chiedere un pagamento per trattenere, ritardare o eliminare un report, minacciare la pubblicazione o la vendita di una scoperta a meno che non paghiamo, oppure farci pressione con una scadenza accompagnata da una minaccia - non è ricerca di sicurezza. Non pagheremo. Tali tentativi saranno trattati rigorosamente secondo la legge applicabile, inclusa la segnalazione alle forze dell'ordine e la piena collaborazione con eventuali indagini o procedimenti conseguenti. I ricercatori in buona fede non hanno nulla da temere; questo paragrafo non è rivolto a voi.
Ringraziamenti pubblici
I ricercatori che hanno segnalato una vulnerabilità confermata e hanno chiesto di essere citati sono elencati qui, dal più recente al più vecchio, una volta rilasciata la correzione. Non c'è ancora nessuno in elenco - se sei il primo, lo indicheremo qui con il tuo nome o handle e il mese della segnalazione. La presenza in questo elenco è soggetta alle condizioni di riservatezza indicate sopra.
Come segnalare un problema di sicurezza.
Invia un'email a [email protected] con: una descrizione del problema, una riproduzione passo passo, l'URL o endpoint interessato, l'impatto osservato e il nome o handle che desideri sul certificato e nell'elenco dei ringraziamenti (è sufficiente un handle; non è richiesto il nome reale e puoi chiedere di restare anonimo). Sono graditi i report cifrati - la nostra chiave PGP è disponibile su richiesta.
Ci impegniamo a confermare la ricezione del tuo report entro due giorni lavorativi, a esaminarlo entro cinque e a rilasciare una correzione o una decisione di accettazione del rischio entro trenta giorni per le segnalazioni confermate (o prima per i problemi critici). Non minacciamo azioni legali contro la ricerca di sicurezza condotta in buona fede e conforme alle norme di divulgazione responsabile - esponendo i dati solo quanto necessario per dimostrare il problema, senza esfiltrare dati dei clienti, senza eseguire test invasivi che impattino gli utenti in produzione e senza pubblicare la scoperta prima di aver concordato per iscritto quando e come potrà essere pubblicata.
Per questioni non di sicurezza (supporto generale, fatturazione, partnership), utilizza /contact. L'email di sicurezza è monitorata solo per le segnalazioni di sicurezza.
Cosa diciamo se qualcosa va storto.
Gli incidenti di produzione che influenzano i fondi dei clienti, i dati dei clienti o la disponibilità dell'API di pagamento ricevono un post-mortem pubblico entro trenta giorni dalla risoluzione, indipendentemente dalla gravità. Gli incidenti più piccoli (prestazioni degradate, interruzioni parziali della regione) vengono comunicati tramite aggiornamenti di stato ai clienti interessati ma non ricevono necessariamente un post-mortem.
Non incolpiamo i clienti nei post-mortem. Non incolpiamo i fornitori di terze parti se la causa principale era nostra. Indichiamo le cause principali in modo chiaro, elenchiamo cosa stiamo cambiando come risultato e manteniamo il post-mortem disponibile indefinitamente. L'aspettativa che i clienti dovrebbero avere è che ti diremo cosa è successo prima che tu debba chiedere.
Contatto sicurezza
Segnalazioni di vulnerabilità: [email protected]. Chiave PGP su richiesta. Le segnalazioni vengono confermate, non retribuite.