Sicurezza del vibe coding: i rischi che spedisci, e la checklist per chiuderli

Il vibe coding è sicuro?

No, non di default. Uno studio arXiv del 2026 ha sottoposto ad audit 200 applicazioni costruite in vibe coding e pubblicamente online, e ha trovato almeno una vulnerabilità nel 91,0% di esse, con il 65,8% dei 1.186 problemi registrati classificato Critical o High. Il vibe coding produce software funzionante in modo affidabile e software sicuro solo per caso.

91,0%

delle 200 applicazioni costruite in vibe coding e sottoposte ad audit portava almeno una vulnerabilità (Deng, Fan e Meng, arXiv 2606.23130)

11,8%

delle soluzioni degli agenti erano sicure, contro il 57% funzionalmente corretto (benchmark SusVibes, Carnegie Mellon e partner)

65,8%

delle 1.186 vulnerabilità di quell'audit erano classificate Critical o High

L'audit è Understanding the (In)Security of Vibe-Coded Applications, di Junquan Deng, Zhiyu Fan e Ruijie Meng, pubblicato per la prima volta a giugno 2026 e rivisto a settembre 2026. Gli autori hanno raccolto 9.041 applicazioni open source costruite con agenti diffusi, tra cui Claude Code e Lovable, poi ne hanno esaminate 200 che erano pubblicamente online. Fanno risalire i 1.186 finding a otto modalità di fallimento ricorrenti e a tre limiti degli agenti stessi: memory defects, objective defects e knowledge defects.

La prova sperimentale punta nella stessa direzione. Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, di un team guidato da Carnegie Mellon, ha costruito il benchmark SusVibes a partire da 186 richieste di funzionalità prese da progetti open source reali, dove un essere umano aveva committato un'implementazione vulnerabile. Su 12 configurazioni di agenti largamente usate, il 57% delle soluzioni di SWE-Agent con Claude 4 Sonnet era funzionalmente corretto e l'11,8% era sicuro.

La risposta onesta, quindi, è che il vibe coding è sicuro quanto i controlli attorno a esso, e la maggior parte delle configurazioni non ne ha nessuno che agisca prima che il codice atterri. Il codice dall'aspetto funzionante è precisamente quello che un revisore frettoloso lascia passare. Velocità senza un punto di controllo di sicurezza è il modo in cui spedisci la falla e la funzionalità nello stesso commit.

Cos'è il vibe coding?

Il vibe coding è costruire software facendo prompt a un agente AI in linguaggio naturale anziché scrivere tu stesso il codice. Descrivi il risultato, l'agente genera e modifica i file, e tu iteri facendo di nuovo il prompt. L'autore del codice è il modello, e l'essere umano rivede un output che spesso non riesce a leggere del tutto.

Il termine si è diffuso all'inizio del 2025 per descrivere un workflow in cui uno sviluppatore, o sempre più spesso un non sviluppatore, si appoggia all'agente e accetta ciò che produce finché il risultato si comporta. Strumenti come Claude Code, Cursor, Windsurf, OpenAI Codex e GitHub Copilot lo hanno reso pratico: indicizzano un repository, modificano in tutto l'albero, eseguono comandi e producono funzionalità funzionanti da un paragrafo di intento. Questo è genuinamente potente. È anche dove si apre il divario di sicurezza, perché la velocità che rende attraente il vibe coding è la stessa velocità che seppellisce le falle.

Quali sono i rischi di sicurezza del vibe coding?

I rischi sono i classici della OWASP Top 10, riprodotti più in fretta di quanto la revisione regga. L'audit arXiv del 2026 li trova concentrati in autorizzazione compromessa, injection e fallimenti di autenticazione. Quattro stanno nella CWE Top 25 del 2025: SQL injection al rango 2, autorizzazione mancante al 4, OS command injection al 9, deserializzazione al 15.

Due di queste meritano uno sguardo più da vicino, perché mostrano quanto sia ordinario il codice generato. L'injection per prima. Chiedi "un endpoint di ricerca che filtra gli utenti per nome" e il percorso di minor resistenza è la concatenazione.

# Vulnerable (CWE-89): user input concatenated into SQL
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Fixed: parameterized query, input never becomes code
db.execute("SELECT * FROM users WHERE name = %s", (name,))

L'autorizzazione compromessa è più sottile, perché la versione vulnerabile sembra completa. Restituisce la forma giusta, supera il test che chiede "prendi l'ordine 42", e spedisce.

// Vulnerable (CWE-639 IDOR): any logged-in user reads any order
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Fixed: scope the lookup to the caller who owns it
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findOne({ _id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()
  res.json(order)
})

La differenza tra le due versioni è una clausola. Un revisore che legge 5.000 righe al giorno non vede la clausola mancante; vede un endpoint che restituisce un ordine e va oltre. Lo stesso schema si ripete in ogni linguaggio che l'agente scrive, ed è il tema del nostro sguardo più ampio su quanto sia sicuro il codice generato dall'AI.

Una classe di rischio non viene dal codice. Un agente legge file, documentazione delle dipendenze e descrizioni di tool, e ognuna di queste può portare istruzioni rivolte a lui anziché a te. La prompt injection è LLM01, la prima voce della OWASP Top 10 for LLM Applications 2025, ed è il motivo per cui il passo 10 della checklist qui sotto chiede cosa l'agente ha eseguito, non solo cosa ha scritto.

Perché il vibe coding produce queste falle?

Perché il prompt ottimizza per il comportamento e il modello per lo schema più comune, e nessuno dei due coincide con la sicurezza. Una richiesta di far funzionare il checkout non contiene alcuna istruzione di validare l'input, limitare l'autorizzazione o parametrizzare una query, quindi l'agente colma il vuoto con ciò che il suo corpus ha reso statisticamente probabile.

Due meccanismi si sommano. Il problema del corpus: il modello ha imparato da codice pubblico pieno dei classici di OWASP, quindi insicuro per impostazione predefinita è il suo a priori. Il problema dell'assenza: la sicurezza è di solito un controllo che è presente, e un modello a cui si chiede un risultato positivo non aggiunge un guard negativo che nessuno ha richiesto. Dirgli di stare attento non risolve né l'uno né l'altro. Il team di SusVibes ha testato esattamente questo, arricchendo la richiesta funzionale con indizi sulla vulnerabilità, e ha riportato che la strategia non mitigava i problemi di sicurezza.

Un terzo meccanismo decide l'esito, e sta dalla parte umana.

“

La persona che fa il prompt può dire se la funzionalità funziona. Di solito non può dire se è sicura. Quel divario, tra l'intento dell'autore e la capacità del revisore, è l'intero problema di sicurezza.

Ecco perché il vibe coding è strutturalmente diverso da uno sviluppatore junior che scrive lo stesso codice. Il junior è abbastanza lento perché la revisione tenga il passo, e il revisore sta leggendo codice scritto da un essere umano a velocità umana. Il vibe coding rimuove entrambi i freni: l'output arriva alla velocità della macchina, e la persona che ne è responsabile spesso non ha l'alfabetizzazione di sicurezza per valutarlo. La pull request, il posto dove l'AppSec ha sempre vissuto, diventa una trascrizione di decisioni già prese anziché un punto di controllo.

Cosa mettere in una checklist di sicurezza per il vibe coding?

Dieci passi, ordinati per resa oraria. I primi chiudono le classi che gli agenti omettono più spesso secondo l'audit arXiv del 2026: autorizzazione compromessa, injection e fallimenti di autenticazione. Gli altri sono i guardrail che impediscono al prompt successivo di riaprirle. Eseguili in ordine su qualsiasi repository che un agente abbia toccato.

1. Ruota ogni credenziale che l'agente può aver letto, poi scansiona la history. Una chiave hardcoded è sfruttabile senza trovare un bug, ed è per questo che viene per prima. CWE-798 sopravvive nella history git e in ogni fork molto dopo che hai cancellato la riga, quindi la rotazione viene prima della cancellazione, non dopo.

2. Limita al chiamante ogni endpoint che restituisce dati. Apri ogni handler generato e verifica che il lookup filtri sull'utente autenticato, non solo su un id preso dalla URL. CWE-862 e CWE-639 sono al rango 4 e al rango 24 della CWE Top 25 del 2025, e sono le falle che l'agente omette con più regolarità, perché nessun test funzionale le richiede.

3. Parametrizza ogni query e ogni chiamata di shell. Fai un grep dei file generati cercando interpolazione di stringhe dentro una query o un comando. CWE-89 è al rango 2 della CWE Top 25 e CWE-78 al rango 9, ed entrambi si chiudono con una modifica meccanica.

4. Valida ogni corpo di richiesta contro uno schema, al bordo. Limiti, tipi, allowlist, rifiuto in caso di fallimento. CWE-20 sta a monte di injection e deserializzazione, quindi chiuderlo chiude diverse classi in una volta, ed è il passo più economico da automatizzare di questa lista.

5. Sostituisci ogni deserializzatore che gira su byte non attendibili. pickle, yaml.load e i deserializzatori nativi di oggetti trasformano un blob memorizzato in esecuzione di codice remoto. CWE-502 è al rango 15 della CWE Top 25, e il sostituto sicuro è di solito un parser tipizzato che hai già.

6. Porta gli store di credenziali fuori dalla portata dell'agente. Nessuna credenziale in chiaro nel workspace che può leggere. Usa un vault, inietta a runtime e aggiungi regole deny per i file .env, così l'agente non può inserire inline ciò che non vede. Ruota qualsiasi cosa sia mai comparsa in una trascrizione.

7. Scrivi le tue regole di sicurezza dove l'agente le legge a ogni modifica. Il Secure Software Development Framework del NIST (SP 800-218, versione 1.1) mette la documentazione dei requisiti di sicurezza nel suo gruppo Prepare the Organization, prima che esista una riga di codice. La sezione successiva spiega cosa devono dire quelle regole.

8. Metti un gate SAST in CI e fai fallire la build sull'alta severità. I test funzionali lasciano passare un endpoint vulnerabile ma funzionante; solo un controllo consapevole della sicurezza non lo fa. Questo è rilevamento, non prevenzione, ed è per questo che sta qui e non in cima.

9. Scrivi un test di abuso per ogni percorso del denaro e per ogni percorso di proprietà. Una quantità negativa, poi l'id di qualcun altro. Le falle di logica di business non hanno una firma da abbinare, quindi un test che codifica la regola è l'unica difesa meccanica. Approfondiamo in falle di logica di business nel codice generato dall'AI.

10. Rivedi cosa l'agente ha eseguito, non solo cosa ha scritto. Tieni i comandi che ha lanciato in un log che puoi rileggere. Chiamate di shell distruttive e accessi ad hoc a un database attivo non compaiono mai in un diff, quindi una code review da sola non li farà emergere.

I passi da 1 a 5 sono remediation che finisci in un pomeriggio su un repository piccolo. I passi da 6 a 10 sono ciò che impedisce alle stesse classi di tornare al prompt successivo.

Cosa deve dire un prompt di sicurezza per il vibe coding?

Deve enunciare le regole come vincoli che l'agente verifica prima di scrivere, non come un auspicio. Nomina l'interfaccia di query, l'helper di autorizzazione e lo schema di input che la tua codebase già usa, e digli di rifiutare la modifica se non riesce a soddisfarli. Le regole che vivono fuori dal contesto dell'agente non si applicano.

La forma utile è specifica e meccanica. Un'istruzione vaga ("scrivi codice sicuro") non dà al modello niente contro cui verificare. Le interfacce nominate sì.

# Regole di sicurezza per questo repository

- Ogni lettura da database passa per `db.query(sql, params)`. Mai interpolare un
  valore dentro l'SQL. Se non puoi parametrizzarlo, fermati e dillo.
- Ogni handler che restituisce un record filtra su `req.user.id`. Un id preso
  dalla URL non basta mai da solo.
- Ogni corpo di richiesta è parsato dal suo schema zod prima dell'uso. Rifiuta
  in caso di fallimento.
- Mai scrivere una credenziale dentro un file. Leggila dall'ambiente.
- Il denaro è Decimal128. Le quantità sono interi strettamente maggiori di zero.

Dove metti quel file conta più di cosa c'è scritto dentro. Nello studio controllato di CybeDefend del 24 agosto 2026, che ha fatto girare 30 ticket di sviluppo in triplice copia per 90 run autonome e 93 scansioni di sicurezza indipendenti, il braccio che teneva queste regole in un file mantenuto a mano nel repository ha registrato in media 2,27 scostamenti dalla regola per ticket portatore di regola. Il braccio senza alcuno strumento ne ha registrati 2,28. Scrivere le regole e non fare altro non ha cambiato quasi niente. Il braccio che riceveva le stesse regole iniettate nel momento della modifica si è fermato a 0,28.

Lo stesso studio è onesto sul limite. Su un ticket la regola pertinente è stata servita tredici volte e l'agente ha comunque smontato i propri guardrail sotto la pressione del compito. L'iniezione delle regole informa, non impone, ed è per questo che la checklist qui sopra tiene un gate in CI e un essere umano dietro.

Uno scanner SAST coglie le vulnerabilità del vibe coding?

In parte. Uno scanner SAST coglie una fetta significativa, in particolare injection e crittografia debole, e appartiene alla CI su ogni pull request. Ciò che gli sfugge è la logica di business: una quantità negativa che accredita il carrello è sintatticamente perfetta e non ha una firma da abbinare. E agisce dopo che il codice è stato scritto.

Quel secondo limite è quello strutturale. SAST, gli scanner di segreti e la code review leggono tutti codice che esiste già, e si raggruppano attorno alla pull request perché è lì che l'AppSec ha sempre vissuto. Ma la PR è stata un punto di controllo solo perché un essere umano la leggeva, e al ritmo del vibe coding nessuno la legge dall'inizio alla fine. Lo scanner diventa uno storico: documenta le falle dopo che l'agente le ha spedite ed è andato oltre.

Leggi la colonna di destra come l'obiettivo. La scansione non è sbagliata, è in ritardo. L'imposizione agent-time non sostituisce lo scanner, la revisione o il gate in CI. Mette un controllo davanti a tutti loro, così la riga insicura viene riscritta prima ancora di essere suggerita, anziché colta tre fasi più tardi da uno strumento che legge un diff che nessuno ha avuto tempo di leggere.

Cosa cercare in uno strumento di sicurezza per il vibe coding?

Due capacità, e la maggior parte degli strumenti ne ha una sola. Il rilevamento trova schemi noti in codice che esiste già. La prevenzione modella il codice mentre l'agente lo scrive, caricando le tue regole nel suo contesto prima di ogni modifica. Chiedi a un fornitore quando agisce il suo controllo: alla velocità dell'agente è tutta la questione.

La metà del rilevamento è un mercato risolto. SAST, software composition analysis e secret scanning sono maturi, e i fornitori affermati di quello spazio, tra cui Snyk, Checkmarx e Semgrep, lo fanno bene. Hanno in comune il momento in cui agiscono: in CI, su un diff, dopo che l'agente è andato oltre. La guida secure by design della CISA, Shifting the Balance of Cybersecurity Risk, pubblicata con 17 partner internazionali, imposta il criterio in modo diverso e migliore: un fornitore dovrebbe farsi carico dei risultati di sicurezza del cliente, anziché consegnargli una lista da smaltire.

È questo il divario che VibeDefend colma. È una CLI npm gratuita che si installa in circa cinque secondi e collega Claude Code, Cursor, Windsurf, OpenAI Codex e GitHub Copilot a quattro livelli di governance che girano dentro il loop dell'agente, così la versione sicura del codice è la prima versione. Per il quadro completo su ogni agente di codice AI, vedi il nostro pilastro sulla sicurezza degli agenti di codice AI.

npx -y @cybedefend/vibedefend@latest installScegli EU o US, conferma il tuo agenteInserisci .cybedefend/config.json nel repoIl prossimo prompt è governato

I quattro livelli coprono le modalità di fallimento che questa guida ha nominato. Business Rules sono le convenzioni estratte dal tuo stesso repo (il denaro è Decimal128, l'autorizzazione passa per requireOwner), caricate nell'agente prima di ogni modifica così che le falle di logica di business non vengano mai scritte. Security Rules portano la OWASP Top 10 e le famiglie di regole di conformità che attivi dentro il codice mentre viene scritto, così injection, validazione mancante e autorizzazione compromessa incontrano una regola al momento della scrittura anziché una casella da spuntare al momento dell'audit. Action Guard intercetta le chiamate distruttive prima che partano: nello studio di agosto ha verificato 1.769 comandi di shell e ne ha rifiutati 17, di cui 1 era un tentativo reale di raggiungere una credenziale salvata, 3 erano applicazioni corrette della policy e 13 falsi positivi, costati un turno ciascuno. Live Findings collega l'agente alla piattaforma di CybeDefend, con SAST dotato di reachability, SCA, segreti, IaC e CI/CD in esecuzione continua, così l'agente smista e corregge anche le vulnerabilità che hai già. Nulla del tuo codice attraversa la rete: le decisioni avvengono localmente accanto all'agente, e al backend arrivano solo metadati di governance strutturati (la regola che è scattata, il percorso del file, la severità, un timestamp). Le regioni EU e US sono fisicamente separate e scegli la tua al momento dell'installazione.

Misurato sugli stessi 30 ticket, il livello ha lasciato 0,033 nuovi finding di analisi statica per task contro 0,10 senza alcuno strumento, e ognuno di quei finding è stato corretto dentro il task che lo aveva introdotto. Con quel numero viaggia un limite onesto: lo studio ha misurato codebase partite pulite, quindi descrive il mantenimento a zero, non il riassorbimento di un backlog che hai già.

Domande frequenti

Il vibe coding è sicuro?

Non di default. Un audit arXiv del 2026 su 200 applicazioni costruite in vibe coding e pubblicamente online ha trovato almeno una vulnerabilità nel 91,0% di esse, e il benchmark SusVibes ha rilevato che solo l'11,8% delle soluzioni degli agenti era sicuro, contro il 57% funzionalmente corretto. Il vibe coding diventa sicuro da fare quando aggiungi un controllo che agisce al momento della scrittura, dai all'agente le tue regole di sicurezza nel suo contesto, mantieni un essere umano nel ciclo e proteggi le pull request con un gate SAST. Senza questi, spedisce la OWASP Top 10 alla velocità della macchina.

Quali sono le vulnerabilità più comuni del vibe coding?

Le classi ricorrenti sono segreti hardcoded (CWE-798), autorizzazione compromessa e IDOR (CWE-862, CWE-639), injection (CWE-89 per SQL, CWE-78 per i comandi), validazione dell'input mancante (CWE-20), deserializzazione non sicura (CWE-502) e falle di logica di business. L'audit arXiv del 2026 ha trovato i suoi 1.186 finding concentrati in autorizzazione compromessa, injection e fallimenti di autenticazione. Nessuna di queste è nuova: sono i classici di OWASP, riprodotti più in fretta di quanto la revisione regga.

Perché il codice generato dall'AI ha così tante falle di sicurezza?

Due meccanismi si sommano e un terzo decide. Il modello ha imparato da un corpus pubblico pieno di schemi insicuri, quindi insicuro per impostazione predefinita è il suo a priori. La sicurezza è di solito un guard che è presente, e un modello a cui si chiede un risultato positivo non aggiunge un controllo negativo che nessuno ha richiesto. Poi la persona che fa il prompt può dire se la funzionalità funziona ma spesso non può dire se è sicura, quindi la falla supera la revisione. Aggiungere indizi sulla vulnerabilità alla richiesta non ha risolto nulla nei test di SusVibes.

Un non sviluppatore può fare vibe coding in sicurezza?

Solo con un controllo che non dipenda dal fatto che la persona legga le implicazioni di sicurezza, perché è esattamente l'abilità che a un non sviluppatore manca. Uno scanner che produce finding da smistare presume che il lettore sappia interpretarli. Un livello agent-time che carica le regole nell'agente e riscrive la riga insicura prima che atterri rimuove quella dipendenza: lo schema sicuro diventa l'impostazione predefinita a cui l'agente ricorre, quindi la sicurezza non poggia sulla capacità di chi fa il prompt di individuare un controllo di autorizzazione mancante.

Si può usare il vibe coding per un'applicazione in produzione?

Non senza i controlli della checklist qui sopra. L'audit arXiv del 2026 ha guardato proprio ad applicazioni pubblicamente online, non a progetti giocattolo, e il 91,0% delle 200 esaminate portava almeno una vulnerabilità, con circa due terzi dei finding classificati Critical o High. La produzione alza la posta esattamente sulle classi che l'agente omette: un endpoint non limitato al chiamante espone record di clienti veri, e una chiave hardcoded in un repo pubblico è sfruttabile dal momento in cui viene pushata.

Uno scanner SAST coglie le vulnerabilità del vibe coding?

Coglie una fetta significativa, in particolare injection e crittografia debole, e appartiene alla CI su ogni pull request. Ciò che in gran parte gli sfugge è la logica di business, perché uno sconto a quantità negativa o un rimborso che salta il controllo di proprietà è sintatticamente perfetto e semanticamente sbagliato, senza firma da abbinare. È anche reattivo: agisce dopo che il codice è scritto, il che alla velocità del vibe coding significa dopo che la falla è stata spedita. Abbina il rilevamento in CI alla prevenzione al momento della scrittura.

Qual è il controllo più efficace per un vibe coding sicuro?

Spostare il punto di controllo di sicurezza dalla pull request al prompt. Il rilevamento che gira dopo che il codice esiste sta sempre leggendo la storia al ritmo dell'agente, perché nessuno rivede migliaia di righe generate dall'inizio alla fine. Nello studio controllato di CybeDefend, le regole tenute in un file del repository hanno lasciato 2,27 scostamenti per ticket portatore di regola contro 2,28 senza alcuno strumento, mentre le stesse regole iniettate nel momento della modifica ne hanno lasciati 0,28. Tutto il resto è difesa in profondità dietro a quello.

Da dove inizio a mettere in sicurezza un progetto già costruito in vibe coding?

Parti dai passi da 1 a 3 della checklist qui sopra: ruota ogni credenziale che l'agente può aver letto e scansiona la history per trovarne altre, poi controlla ogni endpoint che restituisce dati cercando un'autorizzazione limitata al chiamante, poi chiudi i punti di injection. Aggiungi alla CI un gate SAST che fallisce sull'alta severità, e metti davanti un livello agent-time così che il nuovo codice sia governato mentre viene scritto. Smetti prima di aggiungere falle, poi smaltisci il backlog che i primi prompt hanno lasciato indietro.