💬 NLP

Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks

Questo studio introduce il benchmark SUSHIBES per valutare la sicurezza del "vibe coding" e rivela che, sebbene gli agenti LLM possano generare codice funzionalmente corretto, producono implementazioni insicure nella stragrande maggioranza dei casi, evidenziando gravi rischi per l'adozione di questa pratica in contesti sensibili.

Autori originali: Songwen Zhao, Danqing Wang, Kexun Zhang, Jiaxuan Luo, Zhuo Li, Lei Li

Pubblicato 2026-02-18

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Songwen Zhao, Danqing Wang, Kexun Zhang, Jiaxuan Luo, Zhuo Li, Lei Li

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

🕵️‍♂️ Il "Vibe Coding": Quando l'AI scrive codice e noi ci fidiamo ciecamente

Immagina di avere un assistente personale super intelligente (un'Intelligenza Artificiale) che sa programmare. Tu gli dici semplicemente: "Ehi, crea una funzione per proteggere le password degli utenti" o "Aggiungi un pulsante per resettare la password". L'AI, senza che tu debba scrivere una singola riga di codice, ti restituisce il lavoro finito.

Questo nuovo modo di lavorare si chiama "Vibe Coding" (codifica basata sul "vibe" o sull'intuizione). È diventato molto popolare perché è velocissimo e sembra magico. Ma la domanda cruciale che gli autori di questo studio si pongono è: "È sicuro? O stiamo costruendo castelli di sabbia su fondamenta di cemento armato?"

🏗️ Il Laboratorio di Prova: SUSVIBES

Per rispondere a questa domanda, i ricercatori dell'Università Carnegie Mellon hanno creato un campo di addestramento chiamato SUSVIBES.

Immagina SUSVIBES come un gioco di ruolo per hacker e difensori:

Hanno preso 200 progetti reali di software (come quelli che usiamo ogni giorno).
Hanno preso delle falle di sicurezza reali che gli umani avevano già corretto in passato.
Hanno "resettato" il tempo, cancellando la correzione e lasciando il codice vulnerabile.
Hanno dato a diverse AI (i "programmatori robot") il compito di riscrivere quella parte di codice per aggiungere una nuova funzione, senza dirgli esplicitamente: "Attenzione, qui c'è una falla di sicurezza!".

È come dare a un architetto AI la pianta di una casa che ha un cancello rotto e chiedergli: "Aggiungi una nuova porta d'ingresso". Se l'AI è brava, aggiungerà la porta. Ma se è distratta, potrebbe lasciare il cancello rotto aperto o, peggio, costruire la nuova porta su una fondamenta già crollata.

📉 I Risultati: Bravi a fare, pessimi a proteggere

I risultati sono stati preoccupanti, quasi come scoprire che il tuo nuovo guardiano del castello dorme con gli occhi aperti.

Funzionalità: Le AI sono molto brave. Circa il 60% delle volte, riescono a scrivere il codice che funziona perfettamente. La porta d'ingresso si apre, il pulsante funziona, il software non si blocca.
Sicurezza: Qui la situazione è disastrosa. Di tutte le soluzioni che funzionano, l'80% è piena di buchi di sicurezza.

L'analogia della torta:
Immagina che le AI siano dei pasticciere geniali. Se chiedi loro di fare una torta, ne fanno una deliziosa che sa di fragola (funziona!). Ma se chiedi loro di usare ingredienti sicuri, il 60% delle volte usano veleno al posto dello zucchero. Tu assaggi la torta, ti piace (funziona!), ma poi ti ammali (è insicura).

🔍 Perché succede?

I ricercatori hanno scoperto che le AI hanno un cortocircuito mentale:

Si concentrano sul "fare": Sono addestrate a completare il compito (aggiungere la funzione).
Ignorano il "proteggere": Non pensano automaticamente a come un cattivo potrebbe usare quella funzione per fare danni.

Hanno provato a dire alle AI: "Ehi, fai attenzione alla sicurezza!" o "Ricorda che qui c'è il rischio X". Risultato? Niente di buono.
Quando si spinge l'AI a pensare troppo alla sicurezza, spesso smette di capire il compito principale e il codice smette di funzionare. È come se un vigile del fuoco, preoccupato di non bruciare il tappeto, decidesse di non spegnere l'incendio per non fare danni all'arredamento.

💡 Cosa significa per noi?

Questo studio ci dà un avvertimento importante:

Non possiamo fidarci ciecamente del codice scritto dalle AI, specialmente in cose delicate come password, dati bancari o sistemi di sicurezza.
Anche se l'AI sembra perfetta e il codice funziona, potrebbe nascondere trappole invisibili che un hacker può sfruttare facilmente.
Il "Vibe Coding" è potente, ma non è ancora maturo per essere usato da solo in ambienti critici. Serve sempre un essere umano esperto a fare il "controllo di qualità" e a dire: "Aspetta, questa porta è aperta per tutti!".

In sintesi

Le AI sono diventate bravissimi artigiani, ma sono ancora pessimi guardiani. Finché non impareranno a bilanciare la creatività con la paranoia necessaria per la sicurezza, dovremo stare molto attenti a cosa lasciamo loro costruire.

1. Il Problema: La Sicurezza del "Vibe Coding"

Il paper affronta un nuovo paradigma di programmazione chiamato "Vibe Coding", in cui gli ingegneri software affidano a agenti basati su Large Language Models (LLM) il compito di completare attività di codifica complesse con minima supervisione umana. Sebbene questo approccio stia guadagnando popolarità (con il 75% dei rispondenti che lo utilizza), sorge una domanda critica: il codice generato da questi agenti è sicuro per la produzione?

Attualmente, esistono benchmark per valutare la sicurezza del codice generato dall'IA, ma sono inadeguati per il "Vibe Coding" perché:

Si concentrano su singoli file o funzioni, mentre il Vibe Coding coinvolge interi repository con strutture complesse.
Valutano modelli che generano codice in un singolo turno, mentre gli agenti operano in cicli multi-turno con interazione ambientale.
Non tengono conto dell'interazione con l'ambiente di esecuzione e del feedback ricevuto.

Il rischio è che gli agenti producano codice funzionalmente corretto ma contenente vulnerabilità critiche (es. chiavi API in chiaro, vulnerabilità di autenticazione), che potrebbero essere sfruttate da malintenzionati.

2. Metodologia: Il Benchmark SUSVIBES

Per colmare questo gap, gli autori hanno proposto SUSVIBES, un benchmark specifico per valutare i rischi di sicurezza degli agenti di coding in scenari realistici.

Costruzione del Benchmark

SUSVIBES è stato costruito attraverso una pipeline automatizzata che estrae task da repository open-source reali contenenti fix di vulnerabilità storiche. Il processo include tre fasi:

Mining di Commit di Fix: Identificazione di commit che hanno risolto vulnerabilità note in progetti Python.
Preparazione dell'Ambiente: Reversione del repository allo stato precedente al fix (vulnerabile) e raccolta dei test funzionali e di sicurezza scritti dagli umani.
Mascheratura e Generazione del Task: Utilizzo di un agente (SWE-Agent) per "mascherare" (rimuovere) l'implementazione della funzione vulnerabile, creando un task che richiede di reimplementare quella funzionalità partendo da zero. Vengono generati:
- Una descrizione del task (stile issue GitHub).
- Un ambiente di esecuzione Dockerizzato.
- Due set di test: Test Funzionali ( $T_{func}$ ) e Test di Sicurezza ( $T_{secure}$ ).

Caratteristiche di SUSVIBES

200 Task reali derivati da 108 progetti diversi.
Copertura di 77 tipi di CWE (Common Weakness Enumeration), molto più ampia rispetto ai benchmark esistenti.
Contesto a livello di repository (media di 162.000 righe di codice), richiedendo modifiche su più file (media di 172 righe per task).
Valutazione dinamica tramite esecuzione dei test in un ambiente isolato.

3. Contributi Chiave

Pipeline di Curation Automatica: Un metodo scalabile per trasformare fix di vulnerabilità reali in task di ingegneria software valutabili.
SUSVIBES: Il primo benchmark repository-level focalizzato sulla sicurezza del "Vibe Coding", che supera i limiti dei precedenti (come BaxBench o CWEval) in termini di complessità del contesto e varietà di vulnerabilità.
Valutazione Estesa: Sperimentazione su 3 framework di agenti (SWE-Agent, OpenHands, Claude Code) e 3 modelli LLM all'avanguardia (Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro).
Analisi delle Strategie di Mitigazione: Valutazione di prompt di sicurezza (guida generica, auto-selezione CWE, oracle CWE) per vedere se possono migliorare i risultati.

4. Risultati Sperimentali

I risultati rivelano un divario preoccupante tra correttezza funzionale e sicurezza:

Scarsa Sicurezza: Anche se gli agenti risolvono con successo una parte significativa dei task funzionalmente (es. SWE-Agent con Claude 4 Sonnet raggiunge il 61% di successo funzionale), la stragrande maggioranza di queste soluzioni è insicura.
- Solo il 10.5% delle soluzioni funzionalmente corrette è anche sicuro.
- Circa l'80-85% delle soluzioni che passano i test funzionali fallisce i test di sicurezza.
Dipendenza dal Modello e dal Framework:
- Claude 4 Sonnet è il modello più performante funzionalmente, ma non garantisce sicurezza.
- Gemini 2.5 Pro mostra una sicurezza leggermente migliore rispetto ad altri modelli, ma il divario funzionale-sicurezza rimane ampio.
- Gli agenti OpenHands tendono a essere leggermente più sicuri di SWE-Agent nello stesso contesto.
Analisi per CWE: I modelli e i framework mostrano "punti ciechi" diversi; ciò che un modello evita, un altro potrebbe introdurre. Non esiste un agente che sia robusto contro tutte le categorie di vulnerabilità.
Fallimento delle Mitigazioni Semplici: L'aggiunta di prompt di sicurezza (guida generica, richiesta di identificare i CWE, o fornire il CWE corretto come "oracle") non risolve il problema.
- Anzi, queste strategie spesso riducono la correttezza funzionale (di circa 7-8 punti percentuali) perché l'agente si concentra eccessivamente sulla sicurezza trascurando la logica di business.
- Il numero totale di soluzioni sia corrette che sicure diminuisce quando si usano queste mitigazioni.

5. Significato e Implicazioni

Il paper conclude che l'adozione diffusa del "Vibe Coding" in contesti sensibili alla sicurezza (autenticazione, gestione dati, infrastruttura) è attualmente rischiosa.

Divario Critico: Esiste un divario fondamentale tra la capacità degli agenti di scrivere codice che "funziona" e la capacità di scrivere codice "sicuro".
Insufficienza dei Prompt: Le strategie attuali basate sulla sola istruzione (prompting) non sono sufficienti a colmare questo divario. Gli agenti tendono a sacrificare la funzionalità quando spinti a essere sicuri, o a ignorare la sicurezza quando focalizzati sulla funzionalità.
Necessità di Nuovi Approcci: È necessario sviluppare strategie di mitigazione più sofisticate, che vadano oltre il prompting, come l'integrazione di strumenti di analisi statica, fuzzing, o reward modeling specifico per la sicurezza durante l'addestramento.
Avvertenza per l'Industria: Le organizzazioni non dovrebbero affidarsi ciecamente al codice generato da agenti senza rigorosi processi di revisione della sicurezza, specialmente quando gli utenti finali potrebbero non avere le competenze per rilevare le vulnerabilità introdotte.

In sintesi, SUSVIBES dimostra che, allo stato attuale, il "Vibe Coding" produce codice che è spesso funzionalmente valido ma strutturalmente vulnerabile, rappresentando una minaccia significativa per la sicurezza del software se adottato senza precauzioni.