Letto da una persona, non da uno scanner.
L’analisi statica trova schemi. Non può accorgersi che su un endpoint manca il controllo dei permessi, perché lì non c’è nulla da rilevare.
Leggiamo il vostro codice sorgente cercando specificamente falle di sicurezza: controllo degli accessi, autenticazione, gestione dei dati, segreti. Ci concentriamo dove si concentra il rischio invece di leggere tutto in superficie. Ogni risultato arriva con il punto esatto nel codice e una correzione proposta, così diventa una pull request e non una discussione.
Aggiornato novembre 2026
Le falle più gravi di solito sono qualcosa che manca.
L’analisi statica è brava a trovare schemi pericolosi: una query non sicura, un algoritmo debole. È scarsa nel notare che uno dei quaranta endpoint non controlla mai se l’utente che chiede è il proprietario del record, perché non c’è codice sbagliato da segnalare. Semplicemente non c’è codice.
Una persona che legge con intenzione trova queste falle, e sono sempre la categoria più dannosa. Un’autorizzazione mancante è il modo in cui un cliente finisce per vedere i dati di un altro.
Funziona bene insieme al penetration test, non al suo posto. Il test mostra che cosa è raggiungibile da fuori; la revisione del codice mostra che cosa non va dentro, compresi percorsi che un tester non raggiungerebbe.
Che cosa cerchiamo.
Autorizzazioni mancanti
Endpoint che verificano chi siete ma mai se il record è vostro. Il risultato grave più comune.
Gestione dell’autenticazione
Sessioni, token, recupero password, scadenze. È lì che si concentrano gli errori dannosi.
Segreti nel repository
Chiavi e credenziali salvate nel codice, anche nella cronologia, dove ci si dimentica di guardare.
Gestione degli input
Percorsi di iniezione, deserializzazione non sicura, template che mostrano dati degli utenti.
Dati sensibili nei log
Numeri di carta, token e dati personali scritti in log che molte persone possono leggere. Per il GDPR non è un dettaglio.
Rischio delle dipendenze
Vulnerabilità note, e pacchetti che nessuno mantiene più.
Uso della crittografia
Non gli algoritmi, che di solito vanno bene: come vengono usati, che spesso no.
Una correzione per ogni risultato
File, riga e modifica proposta. Così diventa una pull request e non una discussione.
Revisione del codice o penetration test?
Trovano cose diverse. La maggior parte dei team dovrebbe fare entrambi, e questa di solito costa meno.
| Revisione del codice | Penetration test | |
|---|---|---|
| Punto di vista | Da dentro: legge il sorgente | Da fuori: attacca l’applicazione in funzione |
| Controlli di autorizzazione mancanti | Sì: l’argomento più forte a favore | Solo dove raggiungibili |
| Segreti scritti nel codice | Sì | Raramente |
| Codice pericoloso non raggiungibile | Sì | No: non si raggiunge |
| Errori di configurazione e rilascio | In parte | Sì |
| Dimostra che è sfruttabile | No: mostra la falla | Sì: dimostra l’attacco |
| Serve accesso al sorgente | Sì | No |
Come leggiamo.
Autorizzazione assente su un endpoint. Nessuno scanner la trova, perché non c’è niente da trovare.
Il nostro fondatore è stato CTO di una fintech di pagamenti. Il codice che tocca i soldi lo leggiamo di conseguenza.
File, riga e modifica. Deve diventare una pull request, non una conversazione.
Quando fare una revisione.
Prima di gestire soldi o dati personali
Trovarlo adesso costa meno che dopo una violazione da notificare.
Avete ereditato un codice
Un’acquisizione o un passaggio da un’agenzia. Non potete fidarvi di ciò che non avete letto.
Un test ha trovato qualcosa di preoccupante
Se mancava un controllo di autorizzazione, conviene verificare che gli altri ci siano.
Non fa per voi se non avete nessun test automatico
Se nulla viene verificato in automatico, sistemare prima quello vi farà più bene. Ve lo diciamo.
Come lavoriamo.
Troviamo dove sta il rischio
Autenticazione, pagamenti, dati personali. Leggiamo quelle parti a fondo invece di tutto in superficie.
Facciamo girare gli strumenti in sottofondo
Trovano gli schemi ovvi e lasciano la lettura libera per ciò che gli strumenti non vedono.
Leggiamo con intenzione
Seguendo come si muovono i dati e dove i controlli dovrebbero esserci e non ci sono.
Verifichiamo ogni risultato
Nel codice, con il percorso mostrato. Nessuno deve inseguire un problema teorico.
Ordiniamo per impatto reale
Che cosa permette davvero nella vostra applicazione, non un punteggio di gravità generico.
Diamo una correzione, non una lezione
File, riga, modifica proposta, così il team apre una pull request invece di un dibattito.
Revisione del codice per la sicurezza
6 domande con risposta. Ne avete un’altra? Scriveteci.
La scansione trova schemi pericolosi che esistono nel codice. Non può trovare qualcosa che manca, e un controllo di autorizzazione mancante è esattamente questo: nessun codice sbagliato da segnalare, solo un endpoint che non verifica mai se il record appartiene a chi lo chiede. È la categoria da cui vengono sempre i risultati più gravi, e richiede una persona.
Sette categorie. Quarantacinque servizi.
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.