AI per Code Review — Trovare Bug di Sicurezza e Smell Code senza Impazzire

La tua PR ha 400 righe modificate. La deadline è domani. Il QA ha già approvato i test funzionali. Tutto sembra a posto. Poi un controllo umano distratto lascia passare una SQL injection. Due settimane dopo, il DB è compromesso. Scena vista decine di volte, anche da noi in consulenza esterna.

La code review è il momento in cui si paga il conto della velocità. Più corri, meno vedi. Ed è lì che entrano gli strumenti di intelligenza artificiale. No, non per sostituire il revisore umano, ma per fare quel passaggio di scansione automatica che l’occhio umano (stanco) non fa mai.

Noi, di Meteora Web, usiamo l'AI per la code review da quando Cursor ha iniziato a proporre analisi contestuali. Prima si usava solo SonarQube o PHPStan. Oggi il gioco è cambiato: l’AI non si limita a pattern matching, ma capisce il flusso del codice. Questo è il salto. E in questa guida ti spieghiamo come sfruttarlo per trovare bug di sicurezza e smell code — i due nemici più costosi per un progetto software.

Come funziona l'AI nella code review?

Partiamo da un punto: i tool tradizionali (linter, static analysis) funzionano su regole precodificate. PHPStan sa che `$stmt->query()` è deprecato, ma non capisce che quella variabile arriva da un input utente non sanitizzato. L'AI sì, perché analizza il grafo delle dipendenze del codice e fa inferenze su più file.

Cursor AI, ad esempio, quando selezioni un pezzo di codice e chiedi "Is there any security issue in this function?", non si limita alla funzione. Legge il contesto: come viene chiamata, quali dati riceve, dove finiscono. È la differenza tra un pesce e una rete da pesca.

Altri strumenti: GitHub Copilot Code Review (solo in preview per orGN), SonarCloud con AI-assisted review (beta), CodeRabbit, CodeGPT e persino OpenAI Codex se integrato via API in un pipeline CI. Noi consigliamo Cursor per progetti PHP/Laravel perché è nativo per lo stack e permette di fare review direttamente nell'editor.

Pratico: come attivare la review AI su una PR in Cursor

1. Apri il file modificato in Cursor.
2. Seleziona le sezioni critiche (login, caricamento file, query DB).
3. Chiedi: "Find any security vulnerabilities or code smells in this selection".
4. Leggi le risposte come secondo parere. Non come verità assoluta.

Quali bug di sicurezza riesce a individuare l'AI?

L'AI ha una memoria dell'OWASP Top 10. Sa riconoscere pattern tipici:

• SQL Injection: concatenazione diretta di variabili in query. Esempio in PHP:

// Potenzialmente pericoloso
$query = "SELECT * FROM users WHERE email = '" . $_POST['email'] . "'";

L'AI (se ben configurata) ti dirà: "Use prepared statements or parameterized queries to prevent SQL injection." E magari ti proporrà la correzione con PDO.

• XSS (Cross-Site Scripting): output di variabili non sanitizzate in HTML. L'AI riconosce l'assenza di `htmlspecialchars()` o `strip_tags()`.
• Path Traversal: se usi `file_get_contents($input)` senza validare il percorso, l'AI segnala il rischio.
• Insecure Deserialization: `unserialize($_GET['data'])` è un campanello d’allarme immediato per l’AI.
• Hardcoded Credentials: password o token in chiaro. L'AI li vede anche dentro array associativi.

Un esempio reale da un nostro cliente: avevano un endpoint API che accettava un JSON e lo usava per popolare un modello Eloquent senza `fillable` protetto. L'AI di Cursor ha subito notato che un campo `is_admin` poteva essere passato dall’utente. Mass Assignment = backdoor.

Come usare Cursor AI per il code review di un progetto PHP?

Noi lavoriamo tanto con Laravel. Ecco un flusso concreto che usiamo internamente:

// Controller che ci hanno passato
public function store(Request $request) {
    $validated = $request->validate([
        'name' => 'required|string',
        'email' => 'required|email'
    ]);
    $user = User::create($request->all()); // attenzione: mass assignment
    return redirect('/users');
}

Seleziona la riga `User::create($request->all())` e chiedi a Cursor: "Is this safe? Any mass assignment issue?". Probabilmente risponderà: "Yes, using `$request->all()` exposes all request parameters. Use `$request->only(...)` or set `$fillable` in the model."

Per i code smells, puoi chiedere: "Find code smells like long functions, duplicate code, or missing error handling". L'AI ti restituirà un elenco con le righe e una breve spiegazione.

Smell code: cosa cerca l'AI che spesso sfugge all'occhio umano?

I code smell sono problemi di manutenibilità, non di funzionamento. Non rompono nulla oggi, ma rendono il codice fragile domani. L'AI cerca:

• Lunghezza eccessiva di funzioni/metodi (oltre 20 righe di solito è un campanello).
• Duplicazione di logica (stessa sequenza di operazioni in più punti).
• Error handling assente o generico (try-catch vuoto o solo `return null`).
• Naming poco espressivo (`$data`, `$tmp`, `$arr`).
• Commenti che spiegano il cosa, non il perché (se il codice è autoesplicativo i commenti sono inutili).
• Parametri booleani in funzioni (`function process($input, $flag)`) – spesso indicano che la funzione fa due cose diverse.

# Esempio di smell: funzione con flag booleano
def create_order(user, items, apply_discount):
    # ... se apply_discount è True fa una cosa, altrimenti un'altra
    pass

Chiedi all'AI: "Refactor this to remove the boolean trap" – ti proporrà di suddividere in due funzioni.

Limiti dell'AI nella code review: quando serve ancora un umano?

L'AI non capisce il contesto di business. Un loop che sembra inefficiente potrebbe essere leggibile e voluto. Un passaggio di dati crittografati potrebbe essere gestito altrove. Inoltre, l'AI tende a essere conservativa: segnala falsi positivi su codice che è ok ma scritto in modo non convenzionale.

Noi la usiamo come secondo paio di occhi, non come approval automatico. La sequenza è: 1) revisione umana veloce 2) passata AI per sicurezza e smell 3) revisione umana mirata sulle segnalazioni. Questo tripla filtro riduce i falsi negativi quasi a zero.

Per la sicurezza, l'AI non sostituisce un penetration test. Ma è un ottimo primo screening che blocca l'80% dei bug banali prima che arrivino in produzione. Lo vediamo ogni giorno sui nostri progetti.

Risorsa esterna utile: la guida ufficiale OWASP per la prevenzione delle SQL injection (OWASP SQL Injection Prevention).

Cosa fare adesso: integrare l'AI nel tuo workflow di revisione

1. Scegli un tool: se usi Cursor, sfrutta la chat integrata per le PR. Altrimenti prova GitHub Copilot Code Review (se disponibile) o CodeRabbit.
2. Definisci una checklist: prima di ogni merge, fai almeno una domanda all'AI su sicurezza e una su smell. Non serve chiedere a ogni commit.
3. Non fidarti ciecamente: ogni risposta dell'AI va verificata. L'errore tipico è accettare un refactoring senza capire se cambia la semantica.
4. Allenati: più usi l'AI, meglio capisci il suo stile di segnalazione. Impara a riconoscere i falsi positivi e a ignorarli.
5. Automazione (avanzato): integra un script in GitHub Actions che, a ogni PR, invia il diff a un modello AI (es. GPT-4 via API) e pubblica un commento con le segnalazioni. Noi abbiamo un esempio su Laravel – contattaci se vuoi il codice.

L'AI per code review non è una bacchetta magica, ma un acceleratore. Usala bene e il tuo team rilascerà codice più solido, più sicuro e più manutenibile. E soprattutto, dormirai sonni più tranquilli.

— Il team di Meteora Web (da Sciacca, con la nostra guida completa su Cursor AI).