Sicurezza vibe coding: testare un’app con agenti AI di pentest

Di Francesco Gruner · Consulenza IT, AI e automazione

Un’app generata in vibe coding parte in due minuti e sembra a posto. Poi la metti online con login, database e magari pagamenti, e ti accorgi che “funziona” e “è sicura” sono due cose diverse. Io ho fatto l’esperimento al contrario: ho generato una piccola app con Claude Code senza chiedere una riga di sicurezza, poi l’ho lasciata attaccare da agenti AI. Non ho chiesto un’app sicura, ho chiesto un MVP.

Qui trovi tutto: i comandi esatti per rifare il test, i prompt, cosa hanno trovato davvero i tre strumenti, cosa hanno sbagliato, e come leggere i loro report senza farti fregare. È la guida completa dietro al video.

Perimetro autorizzato: leggi prima

Usa questi comandi solo su applicazioni tue o su ambienti per cui hai autorizzazione esplicita. Qui il target è locale, 127.0.0.1:3000, in laboratorio. Attenzione anche ai termini di servizio dell’hosting, che spesso vietano questi test. Testare o attaccare sistemi altrui senza consenso è illegale, in Italia e ovunque. Fai i test solo su ciò che ti appartiene.

Il workflow: una catena, non un tool solo

La cosa interessante non è quale strumento sia il migliore. È che sta nascendo una catena: un’AI genera il codice, una lo revisiona sul sorgente, una lo attacca da fuori, una produce il report. Quattro ruoli sullo stesso progetto.

Il messaggio centrale è uno: l’AI accelera triage e remediation, ma ogni finding va verificato a mano. Nessuno di questi sostituisce un vulnerability assessment o un penetration test fatto da chi lo fa di mestiere. Se cerchi solo i tool AI per sviluppare, prima parti dalla guida al vibe coding con oltre 20 strumenti.

1. Creare e avviare l’app con Claude Code

Per rendere i comandi copiabili da chiunque su Windows, usa una variabile basata sul profilo utente invece di percorsi fissi:

$ProjectRoot = Join-Path $HOME "Desktop\video-secure"
New-Item -ItemType Directory -Force -Path $ProjectRoot | Out-Null
Set-Location $ProjectRoot
claude

Il prompt, volutamente vago sulla sicurezza:

Crea una piccola web app in locale che utilizzi SQLite e abbia lo stile di una
chatroom anni 2000.

Voglio registrazione, login e la possibilità di scrivere messaggi.
Deve funzionare subito, essere semplice da avviare e avere un'interfaccia
visivamente riconoscibile.

Scegli tu la tecnologia e il modo migliore per visualizzare la grafica.

L’app generata usa Node.js 24 e node:sqlite. Avviala in una PowerShell separata e lascia la finestra aperta per tutta la durata dei test, poi apri http://127.0.0.1:3000/:

$ProjectRoot = Join-Path $HOME "Desktop\video-secure"
Set-Location $ProjectRoot
& "C:\Program Files\nodejs\node.exe" server.js

2. pentest-ai-agents: il code review dentro Claude Code

Il primo strumento non attacca l’app: legge il codice. È il filtro più economico che puoi mettere, perché gira sul sorgente e sfrutta la tua sessione Claude Code. La versione usata nei test mette a disposizione una cinquantina di agenti specializzati (il numero cambia tra le release). Li installi scaricando lo ZIP del repository, più affidabile di git clone se la rete fa i capricci:

$ProjectRoot = Join-Path $HOME "Desktop\video-secure"
Set-Location $ProjectRoot

Remove-Item .\pentest-ai-agents -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item .\pentest-ai-agents-main -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item .\pentest-ai-agents.zip -Force -ErrorAction SilentlyContinue

Invoke-WebRequest -Uri "https://github.com/0xSteph/pentest-ai-agents/archive/refs/heads/main.zip" -OutFile ".\pentest-ai-agents.zip"
Expand-Archive -Path ".\pentest-ai-agents.zip" -DestinationPath "." -Force
Rename-Item -Path ".\pentest-ai-agents-main" -NewName "pentest-ai-agents"
Remove-Item .\pentest-ai-agents.zip -Force

New-Item -ItemType Directory -Force -Path .\.claude\agents | Out-Null
New-Item -ItemType Directory -Force -Path .\.claude\commands | Out-Null
Copy-Item .\pentest-ai-agents\agents\* .\.claude\agents\ -Recurse -Force
Copy-Item .\pentest-ai-agents\commands\* .\.claude\commands\ -Recurse -Force
(Get-ChildItem .\.claude\agents -File).Count

Riavvia Claude Code, fai riconoscere gli agenti senza toccare nulla, poi lancia la review. Nota la parte finale del prompt: chiedo di segnalare i possibili falsi positivi e di usare solo il target locale.

Questa è una revisione autorizzata della mia applicazione locale.

Analizza il progetto e scegli gli agenti più adatti tra quelli in .claude/agents.
Usa code-auditor e, se utile, web-hunter o api-security.

Cerca autenticazione, sessioni, autorizzazione, IDOR, SQL injection, XSS,
CSRF, path traversal, secret hardcoded, validazione input, rate limiting,
export e configurazioni pericolose.

Non modificare il codice. Per ogni finding indica gravità, file o endpoint,
prova, impatto, possibile falso positivo e correzione. Se esegui test dinamici,
usa solo http://127.0.0.1:3000/ e azioni non distruttive. Crea SECURITY_REVIEW.md.

Nel test, i tre agenti coordinati da Claude hanno chiuso in circa 13-14 minuti con un report HTML pulito: due rischi alti, quattro medi, tredici controlli. Tra le cose vere, l’assenza di rate limiting (confermata con 15 login falliti di fila) e un carico applicativo che bloccava l’event loop. Buon primo filtro, tutto senza uscire dall’editor.

3. PentAGI: il pentest agentico con la GUI

Qui si sale di livello: PentAGI ha un’interfaccia web con flow, task, terminale e un ambiente Docker che tira su Kali Linux con gli strumenti veri. Non lanciare comandi globali di pulizia Docker mentre PentAGI è attivo, o ti spegni i container sotto i piedi.

$ProjectRoot = Join-Path $HOME "Desktop\video-secure"
Set-Location $ProjectRoot
New-Item -ItemType Directory -Force -Path .\pentagi | Out-Null
cd .\pentagi

curl.exe -L -o .env.example https://raw.githubusercontent.com/vxcontrol/pentagi/master/.env.example
curl.exe -L -o docker-compose.yml https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose.yml
Copy-Item .env.example .env -Force
notepad .env

Nel file .env metti la chiave del provider. Non condividerla, e ruotala subito se compare per sbaglio in log o screenshot:

OPEN_AI_KEY=INCOLLA_LA_TUA_CHIAVE

Fai il pull dell’immagine Kali prima di avviare: pesa una ventina di GB e, se non l’hai già scaricata, il primo flow sembra bloccato con il terminale “disconnected”.

docker pull vxcontrol/kali-linux
docker compose up -d
docker compose ps

Apri https://localhost:8443. Credenziali di default, se non le hai cambiate: admin@pentagi.com / admin (cambia subito la password). Poi crea un flow con questo prompt, blindato sullo scope. Da container usa host.docker.internal, non 127.0.0.1: dentro Docker il localhost è il container stesso, non la tua macchina.

Test autorizzato sulla mia applicazione locale (chatroom Node.js 24 con SQLite).

Target esclusivo: http://host.docker.internal:3000/  Testa solo la porta 3000.
Endpoint reali: POST /api/register, POST /api/login, POST /api/logout,
GET /api/me, GET /api/messages, POST /api/messages.

Esegui ricognizione e test web sicuri su autenticazione, sessioni,
autorizzazione, header, rate limiting, SQL injection, CSRF e XSS.
Non scansionare altre porte. Non eseguire DoS, Slowloris, brute force,
shell o privilege escalation. Non classificare una risposta 404 come
vulnerabilita'. Conferma un finding solo con richiesta, risposta e impatto
riproducibili. Salva evidenze e report finale nel flow.

È la parte più bella da vedere: crea il piano, divide in task, apre Kali, e se un tool non c’è se lo installa nel container e va avanti. Onestà però: nel mio test non è andata come speravo. L’app è andata offline per un attimo, alcune cose non le ha completate, e ha segnato come vulnerabilità dei 404 che non erano nulla. Un flow è costato circa 5 dollari e 8 milioni di token in un’ora. Spettacolare da mostrare, ma le sue severità vanno prese con le pinze.

4. PentestGPT: l’assessment da terminale

Meno scenografico di PentAGI, ma con una reportistica più solida. Gira in Docker con rete e volumi separati, quindi può stare acceso insieme a PentAGI senza conflitti, a patto di usare un progetto Compose isolato.

$ProjectRoot = Join-Path $HOME "Desktop\video-secure"
Set-Location $ProjectRoot

Invoke-WebRequest -Uri "https://github.com/GreyDGL/PentestGPT/archive/refs/heads/main.zip" -OutFile ".\PentestGPT.zip"
Expand-Archive -Path ".\PentestGPT.zip" -DestinationPath "." -Force
Rename-Item -Path ".\PentestGPT-main" -NewName "PentestGPT"
Remove-Item .\PentestGPT.zip -Force

cd .\PentestGPT
New-Item -ItemType Directory -Force -Path .\workspace | Out-Null
docker compose -p pentestgpt-video build pentestgpt
docker compose -p pentestgpt-video run --rm pentestgpt /bin/bash

Dentro il container fai il login e lancia lo scan. Attenzione: --mode pentest indica la modalità, --model il modello, non confonderli con un -m.

claude login

pentestgpt \
  -t http://host.docker.internal:3000/ \
  --mode pentest \
  --model claude-sonnet-4-5-20250929 \
  --no-telemetry \
  -i "Authorized local test of my Node.js chatroom. Test only HTTP port 3000. Endpoints: /api/register, /api/login, /api/logout, /api/me, /api/messages. Safe reconnaissance; validate authentication, sessions, authorization, rate limiting, security headers, SQL injection, CSRF and stored XSS. Do not scan other ports. No DoS, brute force, shell or privilege escalation. Never classify HTTP 404 as a vulnerability. Confirm a finding only with a reproducible request and response. Save evidence and a concise final report in /workspace."

Uscito dal container, i report sono nella cartella PentestGPT\workspace. Nel test è stato più veloce di PentAGI, costato circa 3 dollari, e ha prodotto findings quasi identici a quelli degli agenti in Claude Code: chiaro nel contenuto, meno curato nella forma.

Cosa hanno trovato davvero (e cosa hanno sbagliato)

Ed è qui il punto che separa chi copia i report da chi li sa leggere. I finding che reggono alla verifica su questa app sono concreti ma banali: l’accesso ai messaggi senza autenticazione dove dovevano essere riservati, l’assenza di rate limiting sul login, gli header di sicurezza mancanti.

Poi c’è la parte che i tool hanno sbagliato, ed è quella che insegna di più. PentAGI ha segnato come vulnerabilità delle risposte 404 che non erano niente, e più di uno scanner ha gonfiato le severità. Una CSV/formula injection marcata “critica con RCE” è, nella realtà, un rischio lato client che scatta solo se un admin apre l’export in Excel: non è il server che esegue codice. La ricognizione, in generale, sovrastima quasi sempre. Solo il test riproducibile conferma se un buco è un buco.

I tool più spinti (bonus red-team)

Oltre ai tre principali, ne esistono di più ambiziosi, orientati al red team. Li cito perché meritano, ma sono più sperimentali e li terrei fuori da una prima prova.

PentestAgent ha una TUI con modalità crew multi-agente, dove più agenti lavorano in parallelo: idea forte, ma va tenuto stretto nello scope. Strix è uno scanner agentico headless, interessante per la CI/CD in ottica DevSecOps, ma su Windows è stato fragile. Decepticon è il più vicino a un framework red-team completo: genera Rules of Engagement, OPPLAN, mappa su MITRE ATT&CK. La cosa più bella l’ha fatta in un test: aveva ipotizzato un IDOR critico, poi col controllo cross-user reale l’ha smentito da solo e declassato il finding. Pianifica, sbaglia, valida, si corregge. Racconto potente, esecuzione ancora acerba.

Esistono anche agenti più spinti orientati al red team, come HexStrike AI, Shannon o CAI: sono dual-use, collegano gli LLM a decine di strumenti offensivi reali e vanno usati solo in ambienti isolati e autorizzati. Ne parlo in un pezzo dedicato.

Tabella di confronto

Validare i risultati (la regola d’oro)

Un finding è credibile solo quando contiene endpoint reale, metodo corretto, richiesta, risposta, impatto osservato, e distingue tra vulnerabilità dimostrata e semplice ipotesi. La regola d’oro: una risposta 404 Not Found non dimostra SSTI, XSS o SQL injection. Un file non vuoto o un checksum dimostrano solo che il file esiste, non che l’attacco funziona. CSRF, XSS e i punteggi CVSS vanno verificati a mano prima di scriverli in un report.

Problemi comuni

Git restituisce getaddrinfo. Usa il download ZIP via Invoke-WebRequest, come nei comandi sopra.

L’app va offline durante i test. Rilancia il server nella sua PowerShell con & "C:\Program Files\nodejs\node.exe" server.js e ripeti il flow.

PentestGPT mostra exec: -- invalid option. Entra prima nella shell del container con docker compose -p pentestgpt-video run --rm pentestgpt /bin/bash, poi lancia pentestgpt.

“Il modello non esiste”. Non usare -m pentest: -m è il modello, la modalità è --mode pentest.

Non perdere i container mentre lavori. Non lanciare docker system prune e non fermare i container di PentAGI o pgvector finché ti servono. PentestGPT gira nel progetto Compose isolato pentestgpt-video, così i due tool restano separati.

Conclusione

Il vibe coding ti dà l’MVP in due minuti, ma la superficie d’attacco te la lascia tutta lì. Claude Code ti aiuta a capire il sorgente, PentestGPT esegue un assessment da terminale, PentAGI dà l’orchestrazione più visuale: tre acceleratori per triage e remediation, non tre sostituti di un pentest professionale. La differenza tra un test AI utile e un report da buttare è tutta nella validazione: l’AI intuisce, ma solo la prova riproducibile conferma. Fatti sempre questo primo filtro se pubblichi codice generato dall’AI, e dove non arrivi affidati a chi la sicurezza la fa di mestiere. Lo stesso principio di combinare gli strumenti vale per Claude Code, di cui ho parlato nella guida a Claude Code con Ollama.

Un’app creata con l’AI è insicura per definizione?

No. Il problema non è che l’AI scriva codice bucato, è che lascia scoperte le protezioni che non hai chiesto: rate limiting, header di sicurezza, controlli di accesso. Chiedi un MVP e ottieni un MVP, non un hardening. Per questo va testata prima di andare in produzione.

Serve Kali Linux installato sul PC?

No. PentAGI tira su Kali dentro un container Docker in automatico. Ti serve solo Docker attivo e il pull dell’immagine vxcontrol/kali-linux fatto prima di avviare, perché pesa una ventina di GB.

Questi strumenti trovano tutte le vulnerabilità?

No, e a volte ne inventano. Nei test hanno gonfiato severità e segnalato falsi positivi, come marcare un 404 come vulnerabilità. Sono un primo filtro per il triage: ogni finding va confermato con richiesta e risposta riproducibili prima di considerarlo reale.

Quanto costa fare questi test?

I progetti sono open source, ma PentAGI e PentestGPT consumano token API a pagamento. In un test un flow di PentAGI è costato circa 5 dollari e PentestGPT circa 3. pentest-ai-agents sfrutta la tua sessione Claude Code, quindi è il più economico da provare.

Sostituiscono un pentest professionale?

No. Accelerano ricognizione, code review e reportistica, ma nessuno sostituisce un pentester senior. Sono un ottimo primo filtro; dove non arrivi, o se l’app gestisce dati sensibili, serve un assessment fatto da persone competenti con strumenti validati.

Posso usarli su un sito già online?

Solo se è tuo o hai autorizzazione esplicita, e attenzione ai termini di servizio dell’hosting che spesso vietano questi test. Testare piattaforme altrui senza consenso è illegale. Meglio sempre in locale.

Repository ufficiali degli strumenti usati nella guida e nei test pratici su applicazione locale.

GitHub

pentest-ai-agents

Repository ufficiale dei sub-agenti di security per Claude Code: struttura dei file, installazione e scope.

Apri fonte

GitHub

PentAGI

Piattaforma web di pentest agentico: docker-compose, configurazione LLM e requisiti dell’immagine Kali.

Apri fonte

GitHub

PentestGPT

Tool CLI per vulnerability assessment in Docker: build, modalità di scan e formato dei report.

Apri fonte

Nuovo su Google

Aggiungi francescogruner.it come fonte preferita

Se leggi spesso i miei articoli su AI, automazione e tecnologia, ora puoi dire a Google che vuoi vedere più spesso i contenuti di francescogruner.it tra le notizie.