Sicurezza del vibe coding: i rischi che spedisci, e come coglierli

Cos'e il vibe coding?

Il vibe coding e costruire software facendo prompt a un agente IA in linguaggio naturale anziche scrivere tu stesso il codice. Descrivi il risultato ("aggiungi un endpoint di checkout che addebita la carta salvata"), l'agente genera e modifica i file, e iteri facendo di nuovo il prompt. Il cambiamento e che l'autore del codice e ora il modello, e l'essere umano e il revisore di un output che spesso non riesce a leggere del tutto.

Il termine si e diffuso all'inizio del 2025 per descrivere un workflow in cui uno sviluppatore, o sempre piu spesso un non sviluppatore, si appoggia all'agente e accetta cio che produce finche 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 funzionalita funzionanti da un paragrafo di intento. Questo e genuinamente potente. E anche dove si apre il divario di sicurezza, perche la velocita che rende attraente il vibe coding e la stessa velocita che seppellisce le falle.

Il vibe coding e sicuro?

Il vibe coding e sicuro per le cose in cui il software e sempre stato sicuro per caso, e insicuro esattamente nelle cose che richiedono un giudizio che un prompt non porta con se. L'agente produce in modo affidabile codice che compila e supera il percorso felice. Non produce in modo affidabile codice che resiste a un attaccante, perche la sicurezza e un'assenza (di un controllo mancante, di un input non sottoposto a escape) che un prompt "fallo funzionare" non chiede mai.

La risposta onesta e che il vibe coding e sicuro quanto i controlli attorno a esso, e la maggior parte delle configurazioni di vibe coding non ne ha nessuno che agisca prima che il codice atterri. Il modello ha imparato da un corpus pubblico pieno di schemi insicuri, quindi li riproduce alla velocita della macchina. I test indipendenti continuano ad atterrare nello stesso punto: una grande quota del codice generato dall'IA non supera i test di sicurezza anche quando e funzionalmente corretto, e il divario tra "funziona" e "e sicuro" e dove vive la violazione.

40%

del codice generato dall'IA era vulnerabile attraverso gli scenari di sicurezza MITRE Top-25 (NYU, Asleep at the Keyboard)

10.5%

delle soluzioni degli agenti di codice IA erano sicure, contro il 61% funzionalmente corretto (Carnegie Mellon SusVibes)

#1

prompt injection, il principale rischio LLM per il 3o anno consecutivo (OWASP LLM01)

La conclusione non e "non fare vibe coding". E che il codice dall'aspetto funzionante e precisamente quello che un revisore frettoloso lascia passare, e che oltre l'80% delle soluzioni IA funzionalmente corrette nel benchmark Carnegie Mellon SusVibes portava comunque una vulnerabilita. Velocita senza un punto di controllo di sicurezza e il modo in cui spedisci la falla e la funzionalita nello stesso commit.

Quali sono i rischi per la sicurezza del vibe coding?

I rischi non sono nuovi tipi di vulnerabilita. Sono i classici della OWASP Top 10, riprodotti piu in fretta di quanto la revisione riesca a tenere il passo, perche il modello scrive lo schema comune e lo schema comune e spesso quello insicuro. Ecco le classi che ricorrono, ciascuna ancorata al suo CWE.

Due di queste meritano uno sguardo piu da vicino, perche 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 e 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 e piu sottile, perche 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 e 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.

Perche il vibe coding produce queste falle?

Perche il prompt ottimizza per il comportamento e il modello ottimizza per lo schema piu comune, e nessuno dei due e la stessa cosa della sicurezza. "Fai funzionare il checkout" e una specifica funzionale. Non contiene alcuna istruzione di validare l'input, limitare l'autorizzazione o parametrizzare una query, quindi l'agente colma il divario con qualunque cosa il suo corpus di addestramento abbia reso statisticamente probabile, che e di frequente la versione insicura.

Ci sono tre ragioni concomitanti. Primo, il problema del corpus: il modello ha imparato da codice pubblico pieno dei classici di OWASP, quindi insicuro per impostazione predefinita e il suo a priori. Secondo, il problema dell'assenza: la sicurezza e di solito un controllo che e presente, e un modello a cui si chiede un risultato positivo non aggiunge un guard negativo che nessuno ha richiesto. Terzo, e piu decisivo, il problema del lettore.

“

La persona che fa il prompt puo dire se la funzionalita funziona. Di solito non puo dire se e sicura. Quel divario, tra l'intento dell'autore e la capacita del revisore, e l'intero problema di sicurezza.

Ecco perche il vibe coding e strutturalmente diverso da uno sviluppatore junior che scrive lo stesso codice. Il junior e abbastanza lento perche la revisione tenga il passo, e il revisore sta leggendo codice scritto da un essere umano a velocita umana. Il vibe coding rimuove entrambi i freni: l'output arriva alla velocita della macchina, e la persona che ne e 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 gia prese anziche un punto di controllo.

Come si fa vibe coding sicuro?

Vibe coding sicuro significa mettere un controllo di sicurezza dove il codice viene effettivamente scritto, che e il prompt, non la pull request. Mantieni la velocita e aggiungi un livello che modella cio che l'agente scrive prima che lo scriva, piu la solita validazione indipendente dietro di esso. I principi qui sotto sono cio che separa "facciamo vibe coding" da "facciamo vibe coding in sicurezza".

1. Da all'agente le regole al momento del prompt. Il modello non puo seguire uno standard che non vede mai. Carica i tuoi requisiti di sicurezza (parametrizza le query, limita ogni lookup al chiamante, non inserire mai inline un segreto) nel contesto dell'agente prima di ogni modifica, cosi lo schema sicuro e l'impostazione predefinita a cui ricorre, non un ripensamento che uno scanner segnala dopo.

2. Tieni i segreti completamente fuori portata. Nessuna credenziale in chiaro nel workspace che l'agente puo leggere. Usa un vault, inietta a runtime e aggiungi regole deny per i file .env e gli store di credenziali cosi che l'agente non possa inserire inline (CWE-798) cio che non puo vedere. Ruota qualsiasi cosa compaia mai in una trascrizione.

3. Tratta ogni endpoint generato come non autorizzato finche non e dimostrato il contrario. L'abitudine di revisione piu preziosa per il codice scritto in vibe coding e verificare che ogni percorso che restituisce dati si limiti al chiamante. L'autorizzazione (CWE-862, CWE-639) e la falla che l'agente omette piu di frequente e quella che nessun test coglie.

4. Valida l'input come requisito vincolante, non come optional. Richiedi limiti, tipi e allowlist su ogni handler generato. CWE-20 e a monte di injection e deserializzazione, quindi chiuderlo chiude diverse classi in una volta.

5. Mantieni un essere umano nel ciclo, e un gate SAST dietro di lui. Indirizza il codice generato attraverso la revisione con scrutinio extra su auth, query e validazione, e fai fallire la build sui risultati ad alta severita. I test funzionali superano un endpoint vulnerabile ma funzionante; solo un controllo consapevole della sicurezza non lo fa.

6. Vigila esplicitamente sulle falle di logica di business. Gli scanner non colgono uno sconto a quantita negativa o un coupon cumulato. Estrai le convenzioni che il tuo stesso codice gia codifica (il denaro e Decimal128, i rimborsi passano per requireOwner) e imponile mentre l'agente scrive. Approfondiamo questo in falle di logica di business nel codice generato dall'IA.

Lo schema attraverso tutti e sei e lo stesso: smetti di affidarti a un controllo che arriva dopo che il codice e su disco, e spostalo al momento in cui il codice viene scritto.

Dove la scansione e carente: l'imposizione agent-time

Ripercorri le classi di rischio ed emerge una singola debolezza nell'approccio standard. SAST, gli scanner di segreti e la code review agiscono tutti su codice che esiste gia. Si raggruppano attorno alla pull request, perche e li che l'AppSec ha sempre vissuto. Ma la PR e stata un punto di controllo solo perche un essere umano la leggeva, e al ritmo del vibe coding nessuno la legge piu dall'inizio alla fine. Lo scanner diventa uno storico, che documenta le falle dopo che l'agente le ha spedite ed e andato oltre.

Il luogo dove imporre una regola e il prompt, prima che la riga insicura venga scritta. Qualunque regola tu voglia che l'agente segua deve essere nelle sue mani nel momento in cui scrive, non in attesa in uno strumento che arriva quando il codice e gia su disco.

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

Quali strumenti colgono le vulnerabilita del vibe coding?

Hai bisogno di due tipi di controllo, e la maggior parte dei team ne ha solo uno. Il tipo familiare e il rilevamento: SAST per injection e crittografia debole, software composition analysis per le dipendenze vulnerabili e secret scanning per le credenziali nella history. Questi sono necessari, e appartengono alla CI su ogni pull request. Sono anche reattivi, e alla velocita del vibe coding arrivano dopo che la falla e stata spedita.

Il tipo che manca alla maggior parte delle configurazioni e la prevenzione nel punto di scrittura: un livello che vive nel loop dell'agente e modella il codice mentre viene scritto. E questo il divario che VibeDefend colma. E 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, cosi la versione sicura del codice e la prima versione. Per il quadro completo di come questo si colloca su ogni agente di codice IA, vedi il nostro pilastro sulla sicurezza degli agenti di codice IA.

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

I quattro livelli gestiscono le modalita di fallimento che questa guida ha nominato. Regole di business sono le convenzioni estratte dal tuo stesso repo (il denaro e Decimal128, l'autorizzazione passa per requireOwner), caricate nell'agente prima di ogni modifica cosi che le falle di logica di business non vengano mai scritte. Regole di sicurezza portano OWASP Top 10, SOC 2, GDPR e ISO 27001 dentro il codice mentre viene scritto, cosi injection, validazione mancante e autorizzazione compromessa incontrano una regola al momento della scrittura anziche una casella da spuntare al momento dell'audit. Action Guard intercetta le chiamate distruttive (un sudo rm -rf, una lettura grezza di una variabile d'ambiente che sembra un segreto, un psql ad hoc contro un host di produzione) prima che partano, avvisando o bloccando per regola con ogni intercettazione nell'audit trail. Live Findings collega l'agente all'intera piattaforma AppSec di CybeDefend, i suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) in esecuzione continua, cosi l'agente non si limita a scrivere codice sicuro, smista e corregge le vulnerabilita che hai gia. In modo cruciale, nulla del tuo codice attraversa la rete: le decisioni avvengono localmente accanto all'agente, e solo metadati di governance strutturati (la regola che e scattata, il percorso del file, la severita, un timestamp) raggiungono il backend. I tenant EU e US sono fisicamente separati, e scegli la regione al momento dell'installazione, cosi il controllo sta cosi vicino al codice senza diventare a sua volta un rischio di esfiltrazione dei dati.

Domande frequenti

Il vibe coding e sicuro?

Il vibe coding e sicuro per produrre software funzionante e inaffidabile nel produrre software sicuro, perche un prompt "fallo funzionare" non chiede mai il controllo di sicurezza mancante. I test indipendenti continuano a rilevare che una grande quota del codice generato dall'IA non supera i test di sicurezza anche quando e funzionalmente corretto. 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 SAST. Senza questi, il vibe coding spedisce la OWASP Top 10 alla velocita della macchina.

Quali sono le vulnerabilita piu 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. Nessuna e nuova. Sono i classici di OWASP, riprodotti piu in fretta di quanto la revisione riesca a tenere il passo, perche il modello scrive lo schema piu comune e lo schema piu comune e di frequente quello insicuro.

Perche il codice generato dall'IA ha cosi tante falle di sicurezza?

Tre ragioni concorrono. Il modello ha imparato da un corpus pubblico pieno di schemi insicuri, quindi insicuro per impostazione predefinita e il suo a priori. La sicurezza e di solito un guard che e presente, e un modello a cui si chiede un risultato positivo non aggiunge un controllo negativo che nessuno ha richiesto. E la persona che fa il prompt puo dire se la funzionalita funziona ma spesso non puo dire se e sicura, quindi la falla supera la revisione. Il risultato e codice dall'aspetto funzionante che spedisce la vulnerabilita insieme alla funzionalita.

Un non sviluppatore puo fare vibe coding in sicurezza?

Solo con un controllo che non dipenda dal fatto che la persona legga le implicazioni di sicurezza, perche e esattamente l'abilita che a un non sviluppatore manca. Un linter o uno scanner che produce risultati 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 e l'impostazione predefinita a cui l'agente ricorre, quindi la sicurezza non poggia sulla capacita di chi fa il prompt di individuare un controllo di autorizzazione mancante.

In cosa il vibe coding e diverso dall'usare un autocompletamento come il vecchio Copilot?

Il vecchio autocompletamento suggeriva un blocco di codice che un essere umano sceglieva di accettare; il raggio d'azione era un singolo snippet che lo sviluppatore doveva comunque incollare. Il vibe coding lascia che l'agente compia azioni: modifica in tutto l'albero, esegue comandi e spedisce funzionalita funzionanti da un paragrafo di intento, a un volume che nessun revisore puo leggere. Il modello di sicurezza deve passare dalla revisione di una bozza che un essere umano accetta al vincolo e alla modellazione di cio che un agente scrive in primo luogo.

Uno scanner SAST coglie le vulnerabilita del vibe coding?

Uno scanner SAST coglie una fetta significativa di esse, in particolare injection e crittografia debole, e appartiene alla CI su ogni pull request. Cio che in gran parte si perde sono le falle di logica di business, perche uno sconto a quantita negativa o un rimborso che salta il controllo di proprieta e sintatticamente perfetto e semanticamente sbagliato, senza firma da abbinare. E anche reattivo: agisce dopo che il codice e scritto, il che alla velocita del vibe coding significa dopo che la falla e stata spedita. Abbina il rilevamento in CI alla prevenzione al momento della scrittura.

Qual e il singolo controllo piu 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, perche nessuno rivede migliaia di righe generate dall'inizio alla fine. Un livello che carica le tue regole di sicurezza e di business nell'agente prima di ogni modifica, e riscrive la riga insicura prima che atterri, previene la falla anziche trovarla dopo. Tutto il resto (SAST, revisione, gate in CI) e difesa in profondita dietro di esso.

Da dove inizio a proteggere un progetto esistente costruito in vibe coding?

Inizia chiudendo le due classi che l'agente omette di piu: scansiona la history per segreti hardcoded e ruota qualsiasi cosa esposta, poi controlla ogni endpoint che restituisce dati per un controllo di autorizzazione limitato al chiamante. Aggiungi un gate SAST alla CI che fallisce sui risultati ad alta severita, e metti davanti un livello agent-time come VibeDefend cosi che il nuovo codice sia governato mentre viene scritto. L'obiettivo e smettere prima di aggiungere falle, poi smaltire il backlog che i primi prompt hanno lasciato indietro.