Come fare una revisione di sicurezza del codice che scrive il tuo agente di coding IA

Gli agenti di coding IA sono veloci, e questa velocità è un'arma a doppio taglio. Genereranno volentieri una funzionalità funzionante in pochi minuti — e con altrettanta prontezza costruiranno una query SQL per concatenazione di stringhe, registreranno un segreto nei log o salteranno un controllo di autorizzazione. Il codice gira, i test passano e la vulnerabilità va in produzione. La revisione di sicurezza non è opzionale quando a digitare è un agente; è la parte di cui tu rimani comunque responsabile.

Ecco un flusso di lavoro pratico e indipendente dagli strumenti per revisionare il codice generato dall'IA prima che arrivi in produzione.

Sapere cosa cercare

La maggior parte delle vulnerabilità del mondo reale si raggruppa in una manciata di schemi. Quando tu (o uno strumento) revisioni l'output dell'agente, cerca prima questi:

• Injection — input SQL, shell o template costruiti concatenando stringhe anziché usare query parametrizzate.
• Cross-site scripting (XSS) — input dell'utente reso in HTML senza escaping.
• Autenticazione/autorizzazione difettosa — endpoint che verificano chi sei ma non se ne hai il permesso; controlli di proprietà mancanti sui record.
• Gestione insicura dei dati — segreti nel codice, credenziali nei log, dati sensibili nei messaggi di errore.
• Dipendenze vulnerabili — un pacchetto aggiunto dall'agente che presenta CVE note.

Queste corrispondono da vicino alla OWASP Top 10, e sono esattamente le categorie che, secondo Anthropic, la sua revisione di sicurezza automatizzata cerca. Tenere a mente questo breve elenco rende la revisione manuale molto più efficace.

Usa l'agente per revisionare sé stesso — in un contesto nuovo

Lo stesso modello che ha scritto il codice può revisionarlo, ma non nello stesso respiro. Un agente che ha appena passato 20 turni a far funzionare una funzionalità è predisposto a difenderla. Avvia una nuova sessione e affidagli un solo compito: trovare i difetti.

Un prompt che funziona bene:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

La clausola "concrete exploit scenario" è la parte importante. Costringe il modello a dimostrare che il problema è reale invece di elencare vaghe formule di rito come "considera di validare l'input".

Ricorri agli strumenti integrati

Se usi Claude Code, esiste un comando dedicato /security-review che analizza le tue modifiche alla ricerca di schemi di vulnerabilità comuni e, quando approvi, applica direttamente le correzioni. È disponibile sui piani a pagamento Pro e Max e sugli account API a consumo.

Per una copertura continua, Anthropic pubblica anche una GitHub Action open source che gira a ogni pull request e posta commenti inline esattamente sulle righe che la preoccupano. Inserirla in un repository ha più o meno questo aspetto:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

Ora ogni PR — che l'abbia aperta un umano o un agente — riceve un passaggio di sicurezza prima che qualcuno prema merge. Cursor, Copilot e altri assistenti offrono integrazioni di revisione comparabili; il principio è lo stesso indipendentemente dallo strumento.

Non saltare i controlli deterministici

La revisione con IA è una potente aggiunta, non un sostituto della noiosa strumentazione che non si stanca mai:

• Scansione delle dipendenze — npm audit, pip-audit o Dependabot intercettano i pacchetti con vulnerabilità note che un LLM non riconoscerebbe dal nome.
• Scansione dei segreti — strumenti come gitleaks o la push protection di GitHub impediscono a una chiave trapelata di finire mai nella cronologia.
• Analisi statica (SAST) — i linter e strumenti come Semgrep applicano le regole in modo coerente su tutta la base di codice.

Usa l'IA per ragionare su logica e contesto — "un utente autenticato può leggere qui i record di un altro utente?" — e usa gli scanner deterministici per le cose meccaniche e rilevabili per pattern. Coprono a vicenda i rispettivi punti ciechi.

Un esempio concreto

Supponiamo che il tuo agente generi questo endpoint:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

Un passaggio di sicurezza dovrebbe segnalare due problemi: la query è una SQL injection pronta a manifestarsi (invoice_id interpolato), e non c'è alcun controllo che la fattura appartenga davvero a user — qualsiasi account loggato può leggere qualsiasi fattura indovinando gli ID. La correzione è una query parametrizzata più un filtro di proprietà:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

L'injection è il genere di cosa che uno scanner intercetta. Il controllo di autorizzazione mancante è il genere di cosa che richiede qualcuno — o un revisore IA con il prompt giusto — che capisca a cosa serve il codice. È questa la divisione da tenere a mente.

La conclusione

Tratta ogni diff prodotto dal tuo agente come non attendibile finché non è stato revisionato — lo stesso standard che applicheresti alla prima pull request di un nuovo membro del team. Combina una revisione IA in contesto nuovo, un controllo automatizzato delle PR e scanner deterministici, e otterrai gran parte della velocità dello sviluppo assistito dall'IA senza ereditarne le peggiori abitudini.