Scanner DeFi in Python e AI: dove finiscono le tue chiavi API

Un tutorial mostra uno scanner DeFi che chiama API esterne, ma non dice dove finiscono le tue chiavi

Su Dev.to è comparso un articolo tecnico, Building a DeFi Yield Scanner with Python and AI, che spiega come costruire uno strumento per analizzare i rendimenti nella finanza decentralizzata. Il pezzo mostra codice reale: chiamate requests verso aggregatori come DeFiLlama e Dune Analytics, pulizia dei dati con pandas e, testualmente, l'invio di quei dati a un modello "via un'API" per generare sintesi dei fattori di rischio.

È un pattern onesto e diffuso: leggi dati da un servizio, li normalizzi, li passi a un LLM tramite chiamata remota. Ma c'è un dettaglio che nessun tutorial di questo tipo affronta davvero, perché non è il suo scopo: dove vivono le credenziali che permettono quelle chiamate. La chiave dell'API dell'LLM, il token di Dune, l'eventuale endpoint a pagamento. Il tutorial ti insegna a far funzionare la logica. Non ti dice cosa succede quando quel codice diventa un repository pubblico o un'app pubblicata.

Cosa significa se il tuo codice l'ha scritto Cursor

Quando chiedi a Cursor di costruire uno scanner come quello, ottieni codice che funziona subito. Il modello genera la funzione fetch_yield_data, aggiunge la chiamata all'LLM, magari inserisce persino la chiave API direttamente nel file per farti vedere che "gira". Il problema non è che Cursor sbagli: è che l'obiettivo dell'assistente è farti arrivare a un risultato eseguibile, non a un risultato pubblicabile in sicurezza.

Così finisci con scenari ricorrenti. Una chiave API scritta in chiaro dentro un .py, poi committata. Un file .env che c'è in locale ma manca in .gitignore, quindi entra nella cronologia Git. Un endpoint a consumo esposto sul frontend perché la chiamata all'LLM avviene lato client. In tutti questi casi il codice funziona perfettamente in demo e resta una miniera per chiunque legga il tuo repository o intercetti le richieste dal browser.

Il fatto che il codice giri non ti dice se le tue credenziali sono al sicuro. Sono due domande diverse, e l'assistente AI risponde solo alla prima.

Perché ora ti serve un audit

Un segreto esposto non lancia errori. Non rallenta l'app. Non produce un warning nella console. Semplicemente resta lì, valido, finché qualcuno non lo trova. E quando lo trova, il conto lo paghi tu: chiamate all'LLM addebitate sul tuo credito, token di servizi a pagamento consumati da altri, dati letti da API che credevi private.

Qui serve un verdetto, non una sensazione. VibeInspect è un audit on-demand: carichi lo ZIP del repository, il codice viene analizzato da specialisti AI e ricevi un PDF con un giudizio chiaro. Niente server permanenti; il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non è un linter e non corregge il codice al posto tuo. Ti dice in che stato è davvero il tuo repository.

Per un progetto come lo scanner DeFi, le evidenze che contano sono precise. Dove compaiono stringhe che assomigliano a chiavi API. Quali file con segreti sono tracciati da Git invece di essere ignorati. Se una chiamata a un servizio esterno che richiede autenticazione avviene in un punto raggiungibile dal client. Se la cronologia contiene un .env committato mesi fa e mai rimosso davvero. Con il piano Diagnostic ottieni file, riga ed evidenza per ciascun punto: non un allarme generico, ma la coordinata esatta da correggere.

Cosa un linter non vede

Un linter è bravissimo a dirti che una variabile non è usata, che manca uno spazio, che una funzione è troppo lunga. Guarda la forma del codice, non il suo significato rispetto alla sicurezza. Una chiave API in chiaro è, per un linter, una normalissima stringa assegnata a una variabile: sintatticamente ineccepibile.

Allo stesso modo, il linter non sa che il tuo .env è finito nella cronologia Git, perché non legge la cronologia. Non capisce che quella chiamata all'LLM è esposta lato client, perché non ragiona sull'architettura del flusso di dati. Non distingue un token di test da una credenziale di produzione reale. Vede token, non rischio.

È proprio in questo spazio che un audit lavora. Non ti segnala uno stile discutibile: ti dice se, pubblicando quel codice, stai regalando l'accesso a servizi che paghi. Sono due livelli diversi di verifica, e nessuno dei due sostituisce l'altro.

Cosa fare questa settimana

Parti da tre controlli concreti sul tuo scanner o su qualsiasi progetto che chiami API esterne.

Primo: cerca nel codice ogni stringa che somigli a una chiave o a un token e verifica che nessuna sia scritta in chiaro. Devono stare in variabili d'ambiente, mai nei file sorgente.

Secondo: controlla che .env e ogni file con segreti siano davvero in .gitignore e non risultino tracciati da Git. Se un segreto è già finito nella cronologia, consideralo compromesso e ruotalo: rimuoverlo dall'ultimo commit non basta.

Terzo: assicurati che ogni chiamata a un servizio autenticato avvenga lato server, mai in codice che finisce nel browser.

Se non hai la certezza di cosa contenga davvero il tuo repository, un audit Diagnostic ti dà file, riga ed evidenza in un PDF. Carica lo ZIP e ottieni il verdetto prima che sia una chiave esposta a dirti in che stato era il tuo codice.