Claude Code Security Review: controllo e GitHub Action

L'autore del materiale originale racconta la propria esperienza: «Ho appena eseguito security-review sul mio progetto vibe e il team ha trovato diversi problemi reali in 4 minuti, che sono già stati risolti». È lo stesso lavoro che prima richiedeva un'intera giornata a un consulente esterno.

Altri materiali sulla configurazione degli strumenti sono disponibili nella documentazione di Ailoot.

Che cos'è /security-review in Claude Code?#

Il comando funziona in due modalità. In locale: esegui /security-review nel terminale e Claude legge il repository e produce un rapporto. Lato server: lo stesso motore viene installato come GitHub Action e aggiunge automaticamente commenti inline a ogni Pull Request.

A differenza degli scanner SAST classici (Snyk Code, Semgrep, SonarQube), /security-review non si basa su regole fisse. Legge il codice come farebbe un ingegnere in carne e ossa: traccia il flusso dei dati, capisce quale framework usi e dove si trovano i confini di fiducia, e individua vulnerabilità non descritte da una regola.

Questo non significa che /security-review sostituisca un pentest esterno o i test dal vivo in un ambiente di staging. Può automatizzare parte della revisione iniziale, ma qui non viene misurata una frazione di copertura dell’audit. Di seguito spiego come eseguirlo correttamente e cosa Claude troverà nel tuo progetto.

Come si esegue /security-review in 5 passaggi?#

Passaggio 1. Aggiorna Claude Code. Il comando è disponibile a partire dalla versione rilasciata il 20 febbraio 2026.

claude update

Se hai installato Claude Code tramite npm, puoi anche eseguire:

npm install -g @anthropic-ai/claude-code@latest

Verifica che sia comparso /security-review:

claude /help | grep security

Passaggio 2. Apri il progetto e accedi a Claude Code.

cd ~/projects/my-vibe-project
claude

Passaggio 3. Esegui il comando. All'interno di Claude Code, inserisci semplicemente:

/security-review

Claude esegue automaticamente 3 fasi di analisi:

1. Ricerca del contesto del repository - legge la struttura e identifica lo stack, le route e le query al database.
2. Analisi comparativa - confronta lo stato corrente con i modelli di vulnerabilità tipici per questo stack.
3. Valutazione delle vulnerabilità - elenca ogni sospetto con un livello di confidenza su una scala da 1 a 10. Nel rapporto vengono incluse solo le segnalazioni con confidenza ≥ 8.

Passaggio 4. Leggi il rapporto. Il formato dell'output è una tabella Markdown. Per ogni problema, Claude fornisce:

• File e numero di riga (per esempio, src/auth/login.ts:42)
• Gravità (HIGH / MEDIUM / LOW)
• Categoria (sql_injection, xss, auth_bypass, insecure_storage)
• Descrizione - cosa non va
• Scenario di exploit - come potrebbe sfruttarlo un aggressore
• Raccomandazione - come risolverlo

Passaggio 5. Chiedigli di applicare le correzioni. Poi puoi usarlo come un normale agente:

«Applica le correzioni con gravità HIGH del report, una alla volta, con una descrizione della PR.»

Claude aprirà ciascun file e proporrà una modifica; sarai tu a confermarla. In un progetto reale, ho chiuso 5 segnalazioni in 40 minuti invece delle 3 ore previste.

Quali vulnerabilità trova /security-review?#

L'elenco completo degli elementi inclusi per impostazione predefinita nell'analisi è descritto nella documentazione ufficiale di Anthropic:

Inoltre, il comando copre categorie che gli scanner automatici raramente rilevano:

• Command injection - esecuzione di input dell'utente in una shell (child_process.exec(userInput))
• Path traversal - caricamento di un file tramite ../../etc/passwd
• XXE - XML con entità esterne
• Template injection - SSTI in Jinja/Handlebars/EJS
• NoSQL injection - operatori $ne, $gt nelle query MongoDB
• Uso improprio della crittografia - uso di MD5, modalità ECB o IV statico

Claude assegna una gravità a ogni segnalazione. La scala è semplice:

• HIGH - sfruttamento da remoto senza autenticazione, fuga di dati che riguarda tutti gli utenti
• MEDIUM - sfruttamento subordinato a condizioni aggiuntive (è necessaria una sessione / un input specifico)
• LOW - vettore potenziale, al momento non critico, ma che vale la pena correggere

Da sapere: nella configurazione standard, Claude non segnala DoS, rate limiting, esaurimento della memoria, open redirect senza impatto dimostrato, regex injection / ReDoS o falsificazione dei log. È intenzionale, per evitare di sommergerti di rumore. Se queste classi sono rilevanti, estendi le regole (vedi la sezione sul filtraggio dei falsi positivi più avanti).

Come si configura una GitHub Action per la revisione automatica?#

Passaggio 1. Ottieni una chiave API. Vai su console.anthropic.com, crea una chiave API e copiala.

Passaggio 2. Inserisci la chiave nei segreti del repository. In GitHub: Settings → Secrets and variables → Actions → New repository secret. Assegna il nome CLAUDE_API_KEY; come valore, inserisci la tua chiave.

Passaggio 3. Crea un file workflow. Salvalo come .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Passaggio 4. Unisci il branch in main. L'action partirà automaticamente con la PR successiva.

Cosa fa l'action:

• Si avvia a ogni Pull Request aperta / sincronizzata.
• Prende le differenze tra il branch della PR e main.
• Esegue lo stesso motore di /security-review in locale.
• Pubblica commenti inline direttamente sulle righe di codice con un sospetto.
• Duplica il rapporto completo nel Job Summary.

Dettagli importanti in permissions:

• pull-requests: write - per pubblicare commenti inline.
• contents: read - per leggere il codice. Nessun permesso write. L'action non modifica il codice; si limita a segnalare i problemi.

Questi permessi sono sufficienti per un repository privato. Per un repository pubblico, puoi specificare anche actions: read se usi workflow riutilizzabili.

Come si filtrano i falsi positivi e si modifica la sensibilità?#

Tabella completa degli input della GitHub Action (fonte: README del repository):

Esempio di configurazione del filtro dei falsi positivi. Crea il file .claude/security/false-positives.md:

# Regole di filtraggio dei falsi positivi per il nostro progetto

- Qualsiasi `dangerouslySetInnerHTML` all'interno di `src/lib/email/layout.ts` è sicuro -
  l'HTML è assemblato da template attendibili e passa attraverso `sanitize-html`
  al momento della scrittura nel database, non del rendering.
- Non segnalare chiavi API di test hardcoded in `__tests__/fixtures/*.ts`.
  Tutte le chiavi iniziano con `sk-test-fake-`.
- La concatenazione SQL in `src/lib/admin/migrations.ts` è accettabile - il file viene eseguito
  solo come root e i dati di input provengono dalle variabili d'ambiente.

Collegalo nel workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

Le istruzioni personalizzate per la scansione di sicurezza sono simili. Crea un file con le regole critiche specifiche del tuo progetto:

# Controlli aggiuntivi per il nostro progetto

- Qualsiasi endpoint sotto `/api/admin/*` deve verificare il ruolo di amministratore
  tramite un wrapper condiviso. Senza questo wrapper, la gravità è HIGH.
- Tutti i webhook YooKassa / CloudPayments devono verificare la firma prima di
  analizzare il body. Senza questo controllo, la gravità è HIGH.
- I token dei magic link devono poter essere usati una sola volta (segnati come usati dopo
  la prima richiesta valida). I token riutilizzabili hanno gravità MEDIUM.

Non si tratta più di un preset Anthropic: stai trasferendo le tue competenze sul progetto nelle regole che Claude applica ogni volta. Questa è l'essenza di «metodologia sopra il modello».

Per saperne di più sulla metodologia del contesto per Claude, consulta le guide «Come configurare CLAUDE.md» e «Second Brain in Claude Code».

Cosa non rileva Claude e perché: limiti dichiarati con trasparenza?#

Anthropic elenca chiaramente cosa è disattivato per impostazione predefinita e perché (fonte: README del repository):

• Denial of Service - troppo rumore, impatto quasi sempre basso.
• Problemi di rate limiting - vengono gestiti a livello infrastrutturale, non nel codice.
• Esaurimento di memoria / CPU - stesso motivo.
• Validazione generica dell'input senza impatto dimostrato - validare ogni campo crea una valanga di falsi positivi.
• Open redirect - spesso è un comportamento previsto.

Cosa la sola revisione del codice non può verificare completamente senza prove runtime o del deployment:

• Configurazione del server di produzione. Intestazioni NGINX, policy CORS, impostazioni TLS, porte di ascolto. Questi aspetti vanno controllati manualmente in un ambiente di staging.
• Race condition. Per esempio, doppia spesa durante richieste di rimborso simultanee. L’analisi statica può indicare schemi sospetti, ma il comportamento concorrente richiede comunque prove.
• Difetti nella logica aziendale dei pagamenti. Se il totale dell'ordine viene calcolato lato client e inviato semplicemente al provider di pagamento, la gravità è HIGH, ma Claude non sempre riconosce questo schema senza un contesto esplicito sul funzionamento previsto dei pagamenti.
• IDOR a livello di database. Se la query SELECT * FROM orders WHERE id = $1 non verifica WHERE user_id = $session.userId, Claude spesso se ne accorge. Ma se il controllo è implementato tramite middleware ORM e Claude non riesce a vedere l'intero flusso dei dati, potrebbe non rilevarlo.
• Resistenza al social engineering / phishing. Non ha nulla a che fare con il codice.

Usa /security-review come revisione statica iniziale. Prosegui con test dinamici in staging, verifiche di ruoli e permessi, SAST pertinente e configurazione effettivamente distribuita. Qui non è stabilita una percentuale di copertura misurata.

Decidi ambito e frequenza della valutazione esterna secondo rischi e cambiamenti del sistema. Né un comando né un audit esterno periodico dimostrano sicurezza coperta al 100%.

Come ha eseguito una revisione di sicurezza l'autore del materiale originale su un progetto vibe#

Cosa è emerso. Un quadro tipico per un progetto vibe medio nella fase «funziona in produzione, ma non è stato revisionato»: vari sospetti sul flusso di autenticazione, sulla logica di elaborazione dei webhook dell'integrazione di pagamento, sulla gestione del caricamento dei file e un paio di note specifiche sulla gestione dell'HTML al momento del rendering. Non descrivo pubblicamente i dettagli; alcuni suggerimenti sono già stati applicati, altri sono ancora in PR. Nel progetto riferito la scansione iniziale è stata utile e rapida; non dimostra una percentuale di audit o un tempo generale di completamento.

Cosa ho scartato come falso positivo:

• Segnalazioni di DoS tramite regex nella validazione dell'input: il carico reale non ricade su quelle regex.
• Una segnalazione relativa a una chiave API hardcoded: era una chiave di test con il prefisso esplicito fake- nei fixture.

Quanto tempo ci è voluto. L'esecuzione in sé ha richiesto 4 minuti. Esaminare il rapporto ha richiesto 25 minuti. Applicare le correzioni ha richiesto circa un'ora con i test. Totale: circa un'ora e mezza da «iniziato» a «tutto in main». Un pentest esterno sullo stesso perimetro richiede una settimana di calendario e costa decine di volte di più.

Conclusione principale. /security-review non sostituisce un pentest esterno. Può trovare problemi utili nel codice, come nella scansione di quattro minuti riferita dall’autore. Esamina e prova le correzioni, poi verifica separatamente comportamento e configurazione distribuiti: la scansione non elimina il rischio di sicurezza del progetto.

Come si integra /security-review nella routine pre-commit?#

L’hook precedente con git_commit, --severity HIGH e --fail-on-find non è una ricetta funzionante documentata e non va usato come barriera di sicurezza. Non è fornito un hook locale verificato che blocchi i commit. La GitHub Action ufficiale sopra pubblica risultati automatici sulle PR: i commenti non dimostrano il blocco di commit o merge.

Una spiegazione completa degli hook si trova nella guida «Hook in Claude Code».

Un'alternativa che usa le routine consiste nel creare una routine pre-deploy-check che esegua /security-review + npm run build + npm run test con un solo comando. Altri materiali sono disponibili nella documentazione di Ailoot.

Se usi server MCP, puoi integrare i risultati di /security-review con un sistema di gestione degli incidenti (Sentry, Linear, Notion), in modo che ogni segnalazione HIGH diventi automaticamente un ticket.

FAQ su /security-review#

Quanto costa una singola esecuzione? Dipende dalle dimensioni del progetto. Nel mio caso, con 30K righe, un'esecuzione usa circa $0.30-0.50 di saldo API. Un grande repository aziendale con un milione di righe costa fino a $5-8 per esecuzione. È decine di volte più economico di qualsiasi abbonamento a uno scanner SaaS.

Con quale frequenza dovrei eseguirlo in locale? Come minimo, prima di ogni release in produzione. Valutalo anche prima di commit e PR significativi. Qui non è fornito un hook verificato che blocchi automaticamente i commit.

Con quali stack funziona? Con qualsiasi stack che Claude riesca a leggere. Secondo le osservazioni dell'autore, sono già stati verificati: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. La qualità è inferiore con linguaggi molto esotici (Erlang, Elixir, Clojure), ma qualche problema lo troverà.

Cosa devo fare se Claude segnala sempre la stessa «vulnerabilità», anche se in realtà non lo è? Aggiungila a false-positive-filtering-instructions spiegando «perché è sicura». Claude smetterà di segnalarla nelle esecuzioni future.

Posso eseguirlo solo su file specifici? In locale sì: esegui semplicemente /security-review src/lib/auth/*.ts. Nella GitHub Action viene controllata solo la differenza corrente della PR, che di solito corrisponde a «file specifici».

Fonti#

Altri materiali sono disponibili nella documentazione di Ailoot.