# Claude Code Security Review: controllo e GitHub Action > Come verificare la sicurezza di un progetto vibe con /security-review in Claude Code. Passaggi di configurazione, un modello di GitHub Action, 6 tipi di vulnerabilità e limiti dichiarati con trasparenza. Source: https://ailoot.ai/blog/it/claude-code-security-review/ Canonical: https://ailoot.ai/blog/it/claude-code-security-review/ Language: it Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-3f71c027c5f10aa35831eae6a0da7edfd6f8504ea6ad6acde40c856274ef87b4 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](https://ailoot.ai/docs/).
[Guide Ailoot](https://ailoot.ai/docs/)
## Che cos'è /security-review in Claude Code?
Punti salienti `/security-review` è un comando integrato in Claude Code che esegue un'analisi di sicurezza dell'intero progetto o delle modifiche correnti direttamente dal terminale. Anthropic lo ha lanciato il 20 febbraio 2026 nell'ambito di Claude Code Security e lo ha reso disponibile a tutti gli utenti Pro, Max e API Console. La richiesta viene pagata usando il normale saldo API di Claude.
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.

Claude Code Security legge e analizza il codice come farebbe un ricercatore di sicurezza umano: capisce come interagiscono i componenti, segue il percorso dei dati nell'applicazione e individua vulnerabilità complesse che gli strumenti basati su regole non rilevano.

— Anthropic, https://www.anthropic.com/news/claude-code-security
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?
Punti salienti Aggiorna Claude Code all'ultima versione, apri il progetto in un terminale, esegui `/security-review`, attendi il rapporto (da 1 a 5 minuti per un progetto medio), leggi i giudizi di gravità e chiedi a Claude di applicare le correzioni. Il comando funziona con qualsiasi stack: Next.js, Django, FastAPI, Rails, Go, Rust. Non richiede una configurazione speciale.
**Passaggio 1. Aggiorna Claude Code.** Il comando è disponibile a partire dalla versione rilasciata il 20 febbraio 2026. ```bash claude update ``` Se hai installato Claude Code tramite npm, puoi anche eseguire: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Verifica che sia comparso `/security-review`: ```bash claude /help | grep security ``` **Passaggio 2. Apri il progetto e accedi a Claude Code.** ```bash 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.
[Guide Ailoot](https://ailoot.ai/docs/)
## Quali vulnerabilità trova /security-review?
Punti salienti Claude individua 6 classi: SQL injection e injection in generale, XSS, problemi di autenticazione e autorizzazione, fughe di dati sensibili, lacune nelle dipendenze di terze parti e segreti hardcoded nel codice. Il comando può anche analizzare la logica di autenticazione distribuita su più file, cosa che gli scanner basati su regole non riescono a fare.
L'elenco completo degli elementi inclusi per impostazione predefinita nell'analisi è descritto nella [documentazione ufficiale di Anthropic](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Categoria | Cosa cerca | |----|----| | **SQL injection** | Concatenazione diretta di stringhe nelle query SQL, chiamate ORM non sicure (`raw()` senza parametri), Prisma `$queryRawUnsafe` | | **XSS** | Rendering con `dangerouslySetInnerHTML` senza sanificazione, sistemi di template senza escaping automatico, `innerHTML` alimentato da input dell'utente | | **Difetti di autenticazione** | Token riutilizzabili, controlli dei permessi mancanti nelle route API, JWT senza data di scadenza, session fixation | | **Gestione non sicura dei dati** | Validazione solo lato client, risposte con campi aggiuntivi (over-fetching), open redirect | | **Vulnerabilità delle dipendenze** | Versioni vulnerabili di pacchetti npm/pip/cargo, verificate tramite `npm audit` ed equivalenti | | **Segreti** | Chiavi API hardcoded, token in `.env.example`, password nel codice | 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?
Punti salienti Anthropic ha pubblicato l'action ufficiale `anthropics/claude-code-security-review@main`. Si collega con un singolo file workflow e aggiunge automaticamente commenti inline a ogni Pull Request con le vulnerabilità rilevate. Configura `CLAUDE_API_KEY` e i permessi del workflow. L’Action ufficiale avverte di non essere protetta contro la prompt injection e di dover esaminare PR attendibili: controlla accessi di collaboratori e workflow prima dell’attivazione.
**Passaggio 1. Ottieni una chiave API.** Vai su [console.anthropic.com](https://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`: ```yaml 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à?
Punti salienti L'action ha 9 input che puoi usare per configurarne il comportamento nel tuo progetto. I principali: `exclude-directories` (per esempio, `tests/,fixtures/`), `false-positive-filtering-instructions` (percorso a un file md con le tue regole del tipo «questo non è una vulnerabilità perché...»), e `custom-security-scan-instructions` per ulteriori controlli specifici del dominio.
Tabella completa degli input della GitHub Action ([fonte: README del repository](https://github.com/anthropics/claude-code-security-review)): | Input | Valore predefinito | Funzione | |----|----|----| | `claude-api-key` | \- | Chiave API Anthropic. Obbligatoria. | | `comment-pr` | `true` | Indica se pubblicare commenti inline nella PR | | `upload-results` | `true` | Indica se salvare il risultato come artifact per 90 giorni | | `exclude-directories` | \- | Elenco separato da virgole: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Modello da usare | | `claudecode-timeout` | `20` | Timeout in minuti | | `run-every-commit` | `false` | Esegui a ogni push, non solo nelle PR | | `false-positive-filtering-instructions` | \- | Percorso a un file md con le tue regole | | `custom-security-scan-instructions` | \- | Percorso a un file md con controlli aggiuntivi | **Esempio di configurazione del filtro dei falsi positivi.** Crea il file `.claude/security/false-positives.md`: ```markdown # 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: ```yaml - 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: ```markdown # 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»](https://ailoot.ai/blog/it/claude-md-template/) e [«Second Brain in Claude Code»](https://ailoot.ai/blog/it/claude-code-second-brain/). ## Cosa non rileva Claude e perché: limiti dichiarati con trasparenza?
Punti salienti Una revisione del codice non esercita da sola l’applicazione attiva né verifica l’ambiente distribuito. Può segnalare potenziali race condition, difetti aziendali o configurazioni sospette presenti nel codice; per confermare comportamento e rischi residui servono prove in staging ed esame del deployment effettivo.
Anthropic elenca chiaramente cosa è disattivato per impostazione predefinita e perché ([fonte: README del repository](https://github.com/anthropics/claude-code-security-review)): - **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
Punti salienti Ho eseguito `/security-review` sul mio progetto TypeScript con Next.js, Prisma, PostgreSQL e Redis. In 4 minuti, il comando ha svolto un audit iniziale, restituito diverse segnalazioni ben documentate di varia gravità e, alla fine, ho completato le correzioni operative in un'ora e mezza. È stato più economico e veloce di qualsiasi pentest esterno.
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?
Punti salienti Prima di commit significativi esegui `/security-review` nella sessione del progetto, leggi i risultati, correggi i problemi confermati e ripeti i test pertinenti. È una procedura di revisione, non un divieto tecnico di 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»](https://ailoot.ai/blog/it/claude-code-hooks/). Un'alternativa che usa le [routine](https://ailoot.ai/blog/it/claude-code-routines/) 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](https://ailoot.ai/blog/it/mcp-servers-claude-code/), 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
Punti salienti 5 domande frequenti: quanto costa, con quale frequenza eseguirlo, con quali stack funziona, cosa fare se Claude ha già trovato questa vulnerabilità e se puoi eseguirlo solo su file specifici. Risposte brevi e senza fronzoli.
**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
### Fonti - [Anthropic - annuncio del lancio di Claude Code Security](https://www.anthropic.com/news/claude-code-security) - annuncio ufficiale del 20 febbraio 2026 - [Anthropic Help Center - Automated Security Reviews in Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - istruzioni ufficiali per eseguirlo - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - sorgente della GitHub Action con il README completo - [Claude Code Docs - Code Review](https://code.claude.com/docs/en/code-review) - documentazione generale di Anthropic - [Anthropic Help Center - Use Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - prodotti correlati - [Port - Ingest Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integrazione dei risultati in un portale per sviluppatori interno - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - cronologia delle release del comando
Altri materiali sono disponibili nella [documentazione di Ailoot](https://ailoot.ai/docs/).
[Guide Ailoot](https://ailoot.ai/docs/)
[Vai ad Ailoot](https://ailoot.ai/)
## Domande frequenti ### Un rapporto security-review senza problemi dimostra che l’applicazione sia sicura? No. È una revisione iniziale del codice con possibili falsi negativi e filtri. Verifica le correzioni, prova ruoli e concorrenza in staging ed esamina la configurazione realmente distribuita. ### La GitHub Action mostrata blocca automaticamente commit o merge? Il workflow non dimostra tale garanzia: pubblica risultati sulle PR. Esaminali e prova i problemi confermati. L’articolo non offre un hook locale verificato che impedisca i commit. ## Ailoot · L’azienda e il suo portafoglio di progetti Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI. L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese. Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.