Una società di sviluppo Web3 non è semplicemente un team che scrive codice Solidity o collega un wallet a un frontend. I fornitori più solidi riuniscono in un unico processo, di cui rispondono direttamente, ingegneria di protocollo, sicurezza degli smart contract, progettazione dell’infrastruttura, indicizzazione dei dati, attenzione alla compliance e consegna del prodotto. Questa distinzione conta perché le falle a livello di integrazione – e non solo nel codice dei contratti – hanno causato perdite per centinaia di milioni di dollari.
L’exploit del bridge Ronin del marzo 2022 ha portato al furto di circa 625 milioni di dollari dopo che gli attaccanti hanno compromesso le credenziali dei validatori. L’exploit del bridge Wormhole del febbraio 2022 ha causato perdite per circa 320 milioni di dollari a causa di una falla nella verifica. Questi incidenti dimostrano perché i servizi di sviluppo Web3 devono occuparsi di gestione delle chiavi, validazione dei messaggi, monitoraggio, controlli sul deployment e governance operativa, oltre che delle funzionalità applicative.
Questa guida spiega come valutare una società di consulenza Web3, che cosa dovrebbe includere lo sviluppo Web3 su misura, come confrontare i modelli di delivery e perché la creazione di dashboard per il Web3 richiede un’architettura dei dati dedicata, non una semplice raccolta di grafici di frontend.
Che cosa offre concretamente una società di sviluppo Web3?
Una società di sviluppo Web3 offre ingegneria end-to-end per applicazioni decentralizzate, infrastrutture blockchain, sistemi di smart contract, piattaforme dati e strumenti operativi. La sua responsabilità va dall’analisi tecnica iniziale e dall’architettura fino a deployment, monitoraggio, test di sicurezza, aggiornamenti e documentazione. Il fornitore migliore risponde del comportamento del sistema lungo l’intero stack, non solo della consegna di codice sorgente isolato.
In pratica, un incarico serio copre di norma diversi livelli collegati:
- Architettura di prodotto e di protocollo: definizione dei percorsi utente, delle ipotesi di fiducia, dei flussi economici, dei permessi e dei requisiti di aggiornamento.
- Ingegneria degli smart contract: implementazione della logica di token, staking, lending, governance, marketplace, bridge o tesoreria.
- Frontend e integrazione dei wallet: supporto a flussi di firma, cambio di chain, simulazione delle transazioni, gestione degli errori e, dove opportuno, account abstraction.
- Backend e indicizzazione: realizzazione di pipeline di eventi, API, servizi di analytics, sistemi di notifica e processi di riconciliazione.
- Infrastruttura: gestione di provider RPC, nodi di archivio, relayer, custodia delle chiavi, ambienti di deployment, osservabilità e disaster recovery.
- Assurance di sicurezza: threat modeling, code review, test, penetration test e preparazione alla risposta agli incidenti.
- Coordinamento normativo e operativo: raccordo tra progettazione tecnica e classificazione dei token, licenze, protezione dei dati e requisiti di accesso al mercato.
L’espressione servizi di sviluppo Web3 va quindi intesa come un’ampia categoria di delivery, non come un sinonimo di “programmazione di smart contract”. Una piattaforma di staking può comprendere contratti, un’applicazione web, oracoli di prezzo, un motore di calcolo delle ricompense, un subgraph, un wallet multifirma di tesoreria e diversi ruoli operativi privilegiati. Un difetto in uno qualsiasi di questi componenti può compromettere il prodotto.
In Soken la nostra metodologia parte dalla mappatura di asset, perimetri di fiducia, azioni privilegiate, dipendenze esterne e stati di errore prima che le decisioni di implementazione diventino definitive. Questo fa spesso emergere rischi che una revisione limitata al codice non coglierebbe, come un relayer non sicuro, una gestione incoerente dei decimali tra servizi diversi o un ruolo di amministratore in grado di aggirare una restrizione economica.
Deliverable tipici
| Area di delivery | Output tipici | Rischio principale in caso di omissione |
|---|---|---|
| Analisi iniziale | Requisiti, modello delle minacce, registro delle decisioni architetturali | Costruire il modello di fiducia sbagliato |
| Livello di protocollo | Contratti, interfacce, script di deployment, test | Errori di logica o di permessi |
| Livello applicativo | Interfaccia web/mobile, flussi wallet, UX delle transazioni | Errori di firma e perdite per gli utenti |
| Livello dati | Indexer, API, analytics, riconciliazione | Saldi errati o reportistica non aggiornata |
| Infrastruttura | CI/CD, accesso ai nodi, secret, monitoraggio | Incidenti non rilevati o irrecuperabili |
| Assurance | Remediation dei rilievi di audit, penetration test, runbook | Rilascio senza evidenze di controllo |
Un fornitore dovrebbe anche spiegare che cosa non realizzerà. Ad esempio, un servizio di oracoli, un sistema di custodia, una rete di validatori di un bridge o un componente per i pagamenti in valuta fiat possono richiedere fornitori specializzati e attività di assurance separate. Confini chiari sono segno di maturità ingegneristica, non di capacità limitate.
Come dovrebbero scegliere i founder tra una società di consulenza Web3 e un team interno?
I founder dovrebbero scegliere una società di consulenza Web3 quando hanno bisogno di competenze blockchain specialistiche, di un percorso di delivery accelerato, di una supervisione indipendente sulla sicurezza o di un accesso temporaneo a competenze di protocollo, infrastruttura e compliance. Un team interno è di norma preferibile per la ownership del prodotto nel lungo periodo e per iterare rapidamente, ma reclutare specialisti e consolidare processi di ingegneria sicuri richiede tempo.
La decisione dovrebbe basarsi sul rischio, sulla maturità del prodotto e sulle competenze necessarie in ciascuna fase.
| Requisito | Società di consulenza Web3 | Team interno | Modello ibrido |
|---|---|---|---|
| Architettura iniziale | Accesso rapido agli specialisti | Più lento durante le assunzioni | La consulenza guida, il team affianca |
| Contesto di prodotto | Richiede un’analisi iniziale strutturata | Solida conoscenza interna | Ownership condivisa |
| Competenza sugli smart contract | Profonda capacità specialistica | Dipende dal recruiting | Revisione esterna più delivery interna |
| Indipendenza della sicurezza | Più facile ottenere una revisione separata | Potenziale conflitto di interessi | Assurance esterna indipendente |
| Manutenzione a lungo termine | Può richiedere un contratto di retainer | Ownership più solida | Ownership interna con supporto specialistico |
| Profilo di costo | Tariffa giornaliera più alta, tempi di avvio più brevi | Costi fissi più elevati | Bilanciato |
| Flessibilità nelle assunzioni | Immediata | Limitata dal recruiting | Assunzioni mirate nel tempo |
Un errore comune è presumere che esternalizzare lo sviluppo trasferisca la responsabilità. Non è così. Il titolare del progetto resta responsabile di approvare il modello di fiducia, controllare le chiavi di produzione, validare le dipendenze di terze parti e assicurarsi che le ipotesi di business siano codificate con precisione.
Un modello pratico consiste nel ripartire la responsabilità in tre fasi:
- Architettura e definizione del rischio: ricorrere a specialisti esterni per mettere alla prova le ipotesi e documentare i perimetri di sicurezza.
- Sviluppo e validazione: combinare la competenza di protocollo della società di consulenza con la ownership interna del prodotto.
- Transizione operativa: richiedere runbook, trasferimento delle conoscenze sul deployment, presa in carico del monitoraggio e un periodo definito di supporto post-lancio.
Nella nostra esperienza in Soken, gli incarichi più solidi si basano su una matrice delle responsabilità messa per iscritto. La matrice indica chi può eseguire il deployment dei contratti, chi approva gli aggiornamenti, chi controlla le operazioni di tesoreria, chi risponde agli alert e chi può mettere in pausa una funzionalità colpita. Senza questa matrice, i team scoprono spesso nel corso di un incidente che più persone davano per scontato che fosse qualcun altro a monitorare il sistema.
Il processo di selezione della società di consulenza dovrebbe includere domande tecniche, anziché basarsi soltanto sul portfolio:
- Quali chain, virtual machine, sistemi di indicizzazione e standard di wallet supporta il team?
- Come vengono governati i contratti aggiornabili?
- Come vengono testati le chiamate esterne, le dipendenze dagli oracoli e i ruoli privilegiati?
- Quali evidenze vengono fornite sulla riproducibilità del deployment?
- Chi detiene codice sorgente, account dell’infrastruttura, documentazione e credenziali operative?
- Che cosa succede se il progetto cambia chain o modifica la tokenomics?
- Quali attività di test e di sicurezza sono incluse nello statement of work?
Una buona società di sviluppo di dApp parlerà di stati di errore delle transazioni, riorganizzazioni della chain, gestione del nonce, stima del gas e incompatibilità tra wallet, non soltanto di design dell’interfaccia utente.
Che cosa dovrebbe includere lo sviluppo Web3 su misura?
Lo sviluppo Web3 su misura dovrebbe includere un’architettura documentata, un modello delle minacce, componenti di protocollo testati, servizi dati resilienti, controlli di deployment sicuri, un’infrastruttura di produzione osservabile e un piano di passaggio di consegne. La personalizzazione ha valore quando il prodotto ha requisiti economici o operativi peculiari, ma il codice scritto ad hoc andrebbe introdotto solo dove crea un valore di prodotto misurabile o riduce un rischio noto.
Il termine “su misura” viene spesso usato a sproposito. Cambiare il marchio a un template esistente non è necessariamente sviluppo su misura, mentre adattare un componente open source collaudato può essere la scelta ingegneristica più sicura. La domanda rilevante è se ciascun componente sia adatto alle ipotesi di fiducia e ai vincoli operativi del progetto.
Componenti fondamentali di una soluzione su misura
1. Progettazione del protocollo e del modello economico
Il team dovrebbe documentare le variazioni dell’offerta, i flussi delle commissioni, le regole sul collaterale, le condizioni di liquidazione, l’emissione delle ricompense, l’autorità di pausa e i poteri di aggiornamento. Ogni variabile economica richiede un responsabile, una regola di validazione e una risposta ai valori anomali.
2. Confini tra contratti e applicazione
I contratti dovrebbero far rispettare le invarianti critiche, anziché affidarsi al frontend per impedire azioni non valide. L’applicazione dovrebbe offrire anteprime chiare delle transazioni, la simulazione dove disponibile e messaggi di errore comprensibili. I servizi di backend non devono trasformarsi silenziosamente in autorità centralizzate, a meno che quel ruolo non sia progettato e dichiarato in modo esplicito.
3. Architettura dei dati e dell’indicizzazione
I dati blockchain sono strutturati in sola aggiunta, asincroni e soggetti a riorganizzazione. Un indexer deve gestire eventi duplicati, transazioni andate in revert, riorganizzazioni della chain, dati storici mancanti e incoerenze tra provider. I saldi mostrati in una dashboard dovrebbero poter essere riconciliati con lo stato on-chain di riferimento.
4. Gestione del deployment e degli aggiornamenti
Il deployment in produzione dovrebbe avvalersi di script versionati, approvazione multifirma, separazione degli ambienti, tracciamento deterministico degli artefatti e un piano di rollback o di pausa. I contratti aggiornabili richiedono più di un proxy di aggiornamento: richiedono controlli di governance, la validazione dello storage layout e un processo per comunicare le modifiche.
5. Test e assurance
I test dovrebbero combinare unit test, test di invarianti, test di integrazione, test su fork, fuzzing, analisi statica, revisione manuale ed esercitazioni operative. Il Secure Software Development Framework del NIST, SP 800-218, offre un utile riferimento di processo, mentre le linee guida OWASP aiutano a strutturare l’analisi dei rischi di applicazioni e API.
Nota di sicurezza: la difesa più efficace contro un costoso incidente Web3 non è un singolo audit. È una catena di controlli – threat modeling, test di invarianti, deployment secondo il principio del privilegio minimo, monitoraggio ed esercitazioni sugli incidenti – che impedisce a un’ipotesi trascurata di trasformarsi in una perdita in produzione.
Un esame degli incidenti storici mostra perché questo approccio a più livelli è importante. Euler Finance ha perso circa 197 milioni di dollari nel marzo 2023 dopo un attacco che ha coinvolto la logica di donazione e di liquidazione. L’evento non è stato un semplice problema di frontend: ha riguardato l’interazione tra la contabilità del protocollo, i flussi di token e le transizioni di stato controllate dall’attaccante. Nell’agosto 2021 Poly Network ha subito un exploit inizialmente stimato in circa 611 milioni di dollari, che ha coinvolto la logica dei messaggi cross-chain e dell’esecuzione privilegiata.
Per i team che realizzano prodotti regolamentati o rivolti al mercato, l’architettura tecnica dovrebbe essere coordinata anche con l’analisi legale. I diritti connessi ai token, gli accordi di custodia, le affermazioni di marketing, le strutture di governance e la provenienza geografica dei clienti possono incidere sui requisiti di implementazione. I servizi legali crypto di Soken possono supportare pareri legali, attività di classificazione dei token e documentazione di compliance in parallelo al processo di delivery tecnica.
I servizi di sviluppo e sicurezza Web3 di Soken combinano architettura, delivery applicativa, revisione degli smart contract, penetration test e assurance dell’infrastruttura. Il perimetro adeguato dipende dal fatto che il progetto abbia bisogno di una nuova dApp, della remediation di un protocollo, della creazione di una dashboard o di un programma di ingegneria più ampio.
Come funziona la creazione di dashboard per il Web3?
La creazione di dashboard per il Web3 richiede una pipeline di dati verificabile, che converta eventi on-chain asincroni in informazioni tempestive, riconciliate e coerenti con i permessi di accesso. Una dashboard di produzione dovrebbe distinguere lo stato confermato da quello in attesa, esporre la provenienza dei dati, gestire le riorganizzazioni e impedire agli utenti di trattare un indice incompleto come un’informazione finanziaria autorevole.
Una dashboard per un protocollo DeFi è più vicina a un sistema di controllo operativo che a una tradizionale pagina di analytics. Può mostrare il total value locked, i rapporti di collateralizzazione, le emissioni di ricompense, i saldi di tesoreria, le proposte di governance, le prestazioni dei validatori, le code di liquidazione o i messaggi cross-chain. Ogni metrica ha una fonte, una frequenza di aggiornamento, un livello di confidenza e una modalità di guasto differenti.
Architettura consigliata per la dashboard
-
Fonti di dati blockchain
Utilizzare endpoint RPC affidabili, l’accesso a nodi di archivio dove le query storiche lo richiedono e listener di eventi per i contratti rilevanti. I saldi critici dovrebbero essere verificati tramite letture dirette dai contratti o tramite una fonte mantenuta in modo indipendente. -
Acquisizione e normalizzazione
Convertire gli eventi grezzi in un modello interno coerente. Tenere conto dei decimali dei token, degli aggiornamenti dei contratti, degli identificativi di chain, degli indirizzi proxy e delle modifiche allo schema degli eventi. -
Livello di riconciliazione
Confrontare lo stato indicizzato con lo stato on-chain a intervalli programmati. Segnalare le discrepanze, anziché sovrascriverle in silenzio. -
API e controlli di accesso
Separare le analytics pubbliche dai dati operativi privilegiati. Applicare autenticazione, autorizzazione, rate limit, log di audit e protezioni contro injection e condizioni di denial of service. -
Frontend e alerting
Mostrare timestamp, numeri di blocco, stato di conferma ed etichette della fonte. Gli alert critici dovrebbero raggiungere un operatore responsabile attraverso più di un canale.
Tipologie di dashboard e relative priorità di progettazione
| Tipo di dashboard | Metriche chiave | Controlli critici |
|---|---|---|
| Protocollo DeFi | TVL, utilizzo, collaterale, attività di liquidazione | Freschezza dei dati degli oracoli e riconciliazione |
| Tesoreria | Saldi degli asset, trasferimenti, approvazioni, vesting | Audit trail delle operazioni multifirma |
| Governance | Proposte, quorum, potere di voto, stato di esecuzione | Coerenza tra snapshot ed esecuzione |
| Operatività dei bridge | Messaggi, validatori, conferme, ritardi | Protezione dal replay e alert sulle anomalie |
| Marketplace NFT | Listing, vendite, royalty, proprietà | Ordinamento degli eventi e integrità dei metadati |
| Flotta di validatori o nodi | Uptime, compiti mancati, stato dei peer | Escalation degli alert e ridondanza |
Una dashboard non dovrebbe mai suggerire certezza là dove i dati sottostanti sono provvisori. Ad esempio, una transazione inclusa in un blocco può essere in seguito interessata da una riorganizzazione, mentre un messaggio cross-chain può essere stato emesso su una rete ma non ancora finalizzato su un’altra. Etichette come “in attesa”, “confermato”, “finalizzato” e “riconciliato” sono controlli operativi, non dettagli estetici.
L’approccio di Soken alla creazione di dashboard per il Web3 parte da un dizionario delle metriche: ogni valore visualizzato ha una definizione, una fonte, un metodo di calcolo, un intervallo di aggiornamento, una tolleranza attesa e un responsabile. In questo modo si evitano le controversie in cui i team di prodotto, finanza e ingegneria usano lo stesso termine – per esempio “saldo di tesoreria” – con significati diversi.
Definito il modello dei dati, il passo successivo è una revisione indipendente di applicazione, contratti, API e infrastruttura. I team possono usare Security X-Ray di Soken per una valutazione di sicurezza preliminare prima di commissionare una revisione più approfondita.
Raccomandazione principale: se il vostro prodotto dipende da interazioni con i contratti, flussi di lavoro privilegiati o dati blockchain, affidatevi ai servizi di sviluppo Web3, audit e penetration test di Soken per validare l’architettura e i controlli di delivery prima del lancio in produzione. I rischi appena descritti – gestione delle riorganizzazioni, accessi privilegiati, riconciliazione e governance del deployment – sono esattamente i punti in cui una valutazione tecnica integrata offre più valore di una revisione limitata al solo frontend.
Quali controlli di sicurezza dovrebbe dimostrare una società di sviluppo Web3?
Una società di sviluppo Web3 dovrebbe dimostrare la propria sicurezza attraverso le evidenze: modelli delle minacce, risultati dei test, progettazione del controllo degli accessi, deployment riproducibili, gestione delle dipendenze, piani di monitoraggio, runbook per gli incidenti e revisione indipendente. Le dichiarazioni di esperienza non sostituiscono gli artefatti che mostrano come il fornitore identifica, mitiga e verifica i rischi lungo l’intero ciclo di delivery.
Il pacchetto minimo di evidenze dovrebbe includere:
- Modello delle minacce: asset, attaccanti, perimetri di fiducia, casi di abuso e rischi residui accettati.
- Inventario dei permessi: owner, operatori, pauser, amministratori degli aggiornamenti, relayer, oracoli e ruoli di emergenza.
- Registro dei test: copertura con unit test, test di integrazione, fuzzing, test di invarianti, test su fork, test dei percorsi negativi e test di regressione.
- Registro delle dipendenze: librerie di contratti, API, provider RPC, indexer, bridge, oracoli e servizi cloud.
- Controlli di deployment: separazione degli ambienti, approvazione multifirma, gestione dei secret, hash degli artefatti e registri delle modifiche.
- Piano di monitoraggio: eventi e soglie per prelievi anomali, cambi di ruolo, deviazioni degli oracoli, transazioni fallite e interruzioni di servizio.
- Risposta agli incidenti: contatti, livelli di escalation, autorità di pausa, conservazione delle prove, comunicazioni agli utenti e decisioni di ripristino.
La gestione degli accessi merita un’attenzione particolare. Le chiavi di deployment di produzione non dovrebbero risiedere sul laptop di un singolo sviluppatore e i permessi amministrativi dovrebbero essere limitati per ruolo e per ambito. La compromissione delle chiavi dei validatori nell’incidente Ronin dimostra come la sicurezza operativa possa vanificare un design di protocollo per il resto sofisticato.
Un fornitore dovrebbe anche spiegare come gestisce le modalità di guasto più comuni e specifiche del Web3:
- Riorganizzazioni della chain e differenze di finalità
- Attacchi di replay tra reti diverse
- Chain ID e domain separator errati
- Abuso delle approvazioni dei token
- Dati degli oracoli obsoleti o manipolati
- Collisioni di storage nei proxy
- Disallineamenti di precisione e di decimali
- Denial of service tramite input ad alto consumo di gas
- Chiamate esterne fallite ed esecuzione parziale
- Indisponibilità delle dipendenze e rate limit
Nella nostra pratica di audit trattiamo la “pausa” come un meccanismo di sicurezza governato con attenzione, non come una soluzione universale. Una pausa che non può essere attivata rapidamente è inefficace; una pausa che può essere attivata da un singolo account non protetto crea un rischio distinto di centralizzazione e di compromissione.
I progetti possono inoltre consultare i report di audit pubblicati di Soken per capire come i rilievi vengono strutturati, ordinati per priorità e collegati alla remediation. La qualità di un audit si valuta meglio esaminando la metodologia e la profondità tecnica, non contando le pagine di un report.
Come possono i team gestire delivery, compliance e operatività a lungo termine?
I team possono gestire in modo efficace la delivery Web3 trattando il lancio come una transizione controllata verso l’operatività, non come la fine dello sviluppo. Prima che asset o utenti siano esposti ai contratti di produzione, il progetto dovrebbe avere responsabili designati, criteri di rilascio misurabili, ipotesi legali documentate, copertura di monitoraggio, procedure di aggiornamento e un calendario di revisioni post-lancio.
Una sequenza di delivery pratica è la seguente:
-
Definire il perimetro del prodotto
Individuare che cosa è on-chain, off-chain, custodial, permissionless, permissioned o dipendente da una terza parte. -
Registrare le decisioni architetturali
Documentare la scelta della chain, l’uso dei bridge, l’aggiornabilità, il design degli oracoli, l’indicizzazione, il supporto ai wallet e la conservazione dei dati. -
Realizzare il più piccolo incremento sicuro
Limitare le funzionalità iniziali e l’esposizione degli asset. Evitare di lanciare combinazioni non testate di governance, leva, messaggistica cross-chain e liquidità automatizzata. -
Validare in ottica avversariale
Testare input non validi, token malevoli, prezzi manipolati, ruoli compromessi, dati obsoleti, chiamate RPC fallite e condizioni impreviste della chain. -
Rilasciare attraverso gate
Richiedere code review, completamento dei test, approvazione del deployment, prontezza del monitoraggio e conferma dei contatti per gli incidenti. -
Operare e rivalutare
Riesaminare dopo il lancio alert, attività privilegiate, modifiche alle dipendenze, segnalazioni degli utenti e ipotesi economiche.
La compliance dovrebbe essere collegata all’architettura del prodotto fin dalle prime fasi. La giurisdizione di un progetto, la tipologia di clientela, il modello di custodia, i diritti connessi ai token, i controlli sulle sanzioni e l’approccio di marketing possono incidere su onboarding, restrizioni di accesso, monitoraggio delle transazioni e tenuta dei registri. La Crypto Map di Soken può aiutare i team a confrontare i contesti normativi durante le discussioni sulla scelta della giurisdizione e sulla pianificazione dei mercati.
Anche la manutenzione a lungo termine richiede chiarezza contrattuale. Lo statement of work dovrebbe specificare i tempi di risposta alle vulnerabilità, le chain supportate, gli aggiornamenti delle dipendenze, la disponibilità in caso di emergenza, la titolarità della proprietà intellettuale, gli standard di documentazione e la procedura per modificare il perimetro. Un preventivo iniziale basso può rivelarsi costoso se ogni problema in produzione viene trattato come un nuovo progetto.
Il Soken Hub offre un punto di riferimento centrale per esplorare ricerche e linee guida correlate su ingegneria, sicurezza e aspetti normativi del Web3. Per i progetti tecnicamente complessi è utile organizzare questi materiali in un registro interno delle decisioni, così che i futuri sviluppatori capiscano perché sono stati scelti una determinata chain, un modello di proxy, un oracolo o una pipeline di dati.
Come si valuta una società di sviluppo di dApp prima di firmare?
Una società di sviluppo di dApp andrebbe valutata attraverso l’analisi tecnica iniziale, le evidenze di progetti comparabili già consegnati, la metodologia di sicurezza, le condizioni di titolarità e la prontezza operativa. Il processo di selezione più solido combina un esercizio di architettura per iscritto con l’esame di deliverable di esempio, anziché affidarsi a un pitch deck, a un prototipo visivo o a un elenco di chain supportate.
Utilizzate questa checklist di valutazione:
Capacità tecnica
- La società sa spiegare l’intero ciclo di vita di una transazione?
- Comprende gli errori dei wallet, i conflitti di nonce, la stima del gas e la finalità della chain?
- Sa progettare indicizzazione e riconciliazione, e non soltanto schermate di frontend?
- Testa i ruoli privilegiati e le invarianti economiche?
- È in grado di gestire il sistema dopo il deployment?
Maturità in materia di sicurezza
- Il threat modeling è previsto prima della scrittura del codice?
- I rilievi di audit vengono seguiti fino alla remediation e al retest?
- Le dipendenze e i servizi di terze parti sono documentati?
- Le chiavi di produzione sono isolate e governate?
- La risposta agli incidenti fa parte del piano di lancio?
Condizioni commerciali e di titolarità
- Chi detiene il repository, gli script di deployment, gli account dell’infrastruttura e la documentazione?
- Le licenze open source e i componenti di terze parti vengono dichiarati?
- Quale periodo di supporto è incluso?
- Quali livelli di servizio si applicano alle vulnerabilità critiche?
- Come vengono quotate le migrazioni di chain e le modifiche al protocollo?
Qualità del prodotto e della comunicazione
- Il fornitore metterà in discussione le ipotesi di prodotto non sicure?
- Le milestone sono legate a criteri di accettazione verificabili?
- Agli stakeholder non tecnici vengono fornite spiegazioni chiare dei rischi?
- Il team distingue un prototipo da un sistema pronto per la produzione?
Un utile esercizio finale consiste nel chiedere al potenziale fornitore di individuare cinque modi in cui il prodotto proposto potrebbe fallire e di ordinarli per probabilità e impatto. Un team maturo affronterà scenari scomodi – come l’indisponibilità di un oracolo, un operatore compromesso, decimali dei token errati, dati della dashboard non aggiornati o un aggiornamento fallito – senza considerare queste domande un ostacolo alla vendita.
Una società di consulenza Web3 andrebbe giudicata dalla qualità delle sue decisioni in condizioni di incertezza. Framework, librerie e chain cambiano, ma un’analisi disciplinata delle minacce, un deployment controllato, dati verificabili e un’operatività con responsabilità chiare restano indicatori duraturi della qualità della delivery.
Il passo successivo più affidabile è preparare, prima di scegliere un fornitore, un documento di una pagina con il perimetro del sistema e la matrice delle responsabilità. Includete contratti, wallet, API, dashboard, terze parti, ruoli privilegiati e utenti previsti; quindi chiedete a ciascun candidato di individuare i percorsi di guasto a più alto impatto.
Il modello di delivery tecnica di Soken collega lo sviluppo Web3 su misura con l’assurance di sicurezza e la prontezza operativa, offrendo ai team un unico percorso strutturato dall’architettura fino al supporto in produzione.