13. Il codice che non puoi leggere: vibe coding e sicurezza informatica · Dave Slane | Studio
Skip links

13. Il codice che non puoi leggere: vibe coding e sicurezza informatica

Tempo di Lettura: 5 minuti

L’app funzionava. Era quello il problema. Moltbook era (è) una piattaforma social per reti di agenti AI, costruita in pochi giorni con strumenti di vibe coding. Dall’esterno: funzionale, elegante, distribuita agli utenti. I fondatori erano soddisfatti. I ricercatori di Wiz, però, si sono presi la briga di guardare dentro. Quello che hanno trovato erano 1,5 milioni di token di autenticazione API accessibili a chiunque, oltre 35.000 indirizzi email esposti, e 4.060 messaggi privati leggibili senza credenziali, senza exploit, senza alcuno sforzo tecnico particolare. Bastava sapere dove guardare. Nessuno aveva sabotato niente. Nessun hacker sofisticato. Il codice faceva esattamente quello che gli era stato chiesto di fare. Semplicemente, non era stato chiesto nel modo giusto. Questo è il Sottosopra del vibe coding e della sicurezza aziendale: le vulnerabilità non appaiono come errori. Appaiono come funzionalità.

Cos’è il vibe coding (e perché probabilmente lo state già usando)

Il termine è stato coniato da Andrej Karpathy, ex responsabile dell’AI di Tesla, nel febbraio 2025. La definizione originale era quasi una provocazione: descrivere un’applicazione in linguaggio naturale e lasciare che un agente AI la costruisca. Dimentica il codice. Affidati alle vibrazioni.

Strumenti come Cursor, Lovable, Bolt, Windsurf e Base44 hanno trasformato quella provocazione in una pratica quotidiana. Oggi, in migliaia di uffici italiani, qualcuno con una conoscenza elementare di informatica costruisce gestionali interni, automatizzazioni, piccoli tool aziendali su misura, senza coinvolgere un singolo sviluppatore professionista. In un weekend. A costo quasi zero.

Per una PMI, il valore percepito è enorme. Per chi valuta solo quello che vede sullo schermo, è difficile non rimanere impressionati.

Il palazzo in cartongesso del software

Immaginate un palazzo costruito in metà tempo e a un terzo del costo di un edificio tradizionale. Dall’esterno: bello, rifinito, pronto per l’uso. All’interno: nessun muro portante, tubature improvvisate, impianto elettrico assemblato senza progetto. Nessuno se ne accorge finché qualcuno non spinge nel posto sbagliato.

Il codice prodotto tramite vibe coding è questo palazzo.

Il Veracode 2025 GenAI Code Security Report ha analizzato oltre 100 modelli linguistici su 80 task di codifica e ha trovato che il 45% del codice AI-generato introduce vulnerabilità di sicurezza. Non in casi limite, non in contesti insoliti: quasi una volta su due, quando l’AI ha la scelta tra un metodo sicuro e uno non sicuro, sceglie quello non sicuro. La ragione è strutturale: i modelli sono addestrati su codice pubblico, e il codice pubblico è pieno di esempi insicuri scritti da sviluppatori umani nel corso di decenni.

Il codice non è sbagliato. È incompleto nel modo che non si vede.

Cosa trovano i ricercatori quando entrano

Uno studio di Escape.tech su 5.600 applicazioni prodotte con vibe coding ha documentato oltre 2.000 vulnerabilità totali, più di 400 credenziali, chiavi API e token esposti direttamente nel codice, e 175 casi in cui dati personali degli utenti erano accessibili tramite indirizzi pubblici, senza alcuna autenticazione. Un secondo studio della DEV Community ha identificato 318 vulnerabilità in sole 100 app analizzate.

Vale la pena tradurre questi numeri in italiano comprensibile per chi non è tecnico.

Le “credenziali hardcodate nel codice” sono come scrivere la combinazione della cassaforte direttamente sulla cassaforte, in bella vista. Le vulnerabilità XSS sono porte laterali che un visitatore malintenzionato può usare per infilarsi nel sistema tramite un campo di testo qualunque, come un modulo di contatto. Un “endpoint pubblico senza autenticazione” è un archivio aperto in rete senza serratura, visibile a chiunque sappia l’indirizzo.

Nessuna di queste cose si vede cliccando sull’app. Funzionano tutte. Hanno solo la serratura sul retro lasciata aperta.

Gli attrezzi del cantiere sono bucati

Il problema non si ferma al codice prodotto. Si estende agli strumenti che lo producono.

La CVE-2025-54135, ribattezzata “CurXecute” dai ricercatori di AIM Security, era una vulnerabilità in Cursor, l’editor AI più diffuso tra chi fa vibe coding: permetteva a un agente di eseguire comandi arbitrari sul computer dello sviluppatore senza alcuna interazione da parte sua. La CVE-2025-53109 riguardava un server MCP di Anthropic e permetteva la lettura e scrittura di file arbitrari sul sistema. Un server MCP malevolo collegato all’email di un utente ha dimostrato in ambiente controllato di essere in grado di reindirizzare in silenzio tutta la corrispondenza verso un indirizzo nascosto.

Il “Vibe Security Radar” del Georgia Tech, attivo dal maggio 2025, traccia le vulnerabilità direttamente attribuibili agli strumenti di AI coding. Alla data di pubblicazione di questo episodio: 74 CVE confermate. La stima reale, secondo i ricercatori, oscilla tra 400 e 700.

L’Italia nel mirino

Il Rapporto Clusit 2026, presentato al Security Summit del 17 marzo 2026, non lascia molto spazio all’ottimismo. Il 2025 è stato l’anno peggiore mai registrato per attacchi informatici in Italia, con 507 incidenti gravi e un aumento del 42% rispetto al 2024. Il settore manifatturiero è il secondo più colpito a livello globale. Il 16% degli attacchi globali al manifatturiero avviene nel nostro Paese.

Questo prima che il vibe coding diventasse una pratica di massa nelle PMI italiane. Aggiungere superficie d’attacco tramite applicazioni costruite senza competenza tecnica, in un contesto già sotto pressione, non è neutralità: è una scelta attiva, anche quando non viene riconosciuta come tale.

Il problema che nessuno nomina

C’è un effetto collaterale del vibe coding più sottile di qualunque vulnerabilità tecnica, e più difficile da misurare.

Chi costruisce un’applicazione tramite prompt in linguaggio naturale non impara a leggere il codice che produce. Questo non è un giudizio: è una conseguenza logica del modello di lavoro. Il problema emerge il giorno in cui qualcosa va storto, che sia un bug, un attacco, un comportamento anomalo. In quel momento, chi ha costruito l’app non è in grado di aprirla e capire dove si è rotto qualcosa. Non sa chiamare nessuno con le informazioni giuste. Non sa nemmeno formulare la domanda corretta.

Questo è il comprehension gap: non l’incapacità di programmare, ma la perdita progressiva della capacità di leggere, controllare e debuggare sistemi di cui si è responsabili operativi. Nei cantieri fisici, nessun costruttore responsabile firmerebbe un collaudo senza aver capito cosa c’è dentro le pareti. Nel software, invece, questa firma avviene ogni giorno.

Come costruire meglio (non come smettere di costruire)

Il punto non è abbandonare gli strumenti. È distinguere tra usi accettabili e usi ad alto rischio.

Un prototipo interno, un tool per automatizzare report su dati non sensibili, un mockup per testare un’idea: questi sono contesti in cui il vibe coding può lavorare liberamente. Un gestionale che tocca dati dei clienti, un sistema connesso al CRM aziendale, qualsiasi applicazione che tratta dati personali o finanziari: qui il codice AI-generato deve essere revisionato da qualcuno che sa leggerlo prima di andare in produzione.

Una checklist minima non richiede un reparto IT interno. Richiede consapevolezza:

  • Nessuna credenziale del database scritta direttamente nel codice (equivale a lasciare le chiavi dell’ufficio sulla porta).
  • Autenticazione su qualsiasi pannello di amministrazione, senza eccezioni.
  • Revisione delle librerie di terze parti incluse automaticamente dall’AI, che possono contenere vulnerabilità proprie.
  • Un test manuale dei flussi di accesso prima di qualunque deploy in produzione.

Nessuna di queste verifiche richiede di saper programmare. Richiedono di coinvolgere qualcuno che lo sa fare, anche solo per un’ora.

La velocità con cui il vibe coding produce software funzionante è reale. Non è propaganda. Il palazzo in cartongesso si costruisce in effetti in metà tempo.

Il problema, ribelli digitali, è che il conto dell’impianto elettrico improvvisato non arriva con la consegna delle chiavi. Arriva la notte in cui qualcuno prova un interruttore nel posto sbagliato.

Fonti:

  1. Veracode 2025 GenAI Code Security Report — 45% del codice AI-generato contiene vulnerabilità.
  2. Escape.tech — Studio su 5.600 app vibe-coded: 2.000+ vulnerabilità, 400+ credenziali esposte, 175 casi PII. Citato in getautonoma.com, marzo 2026.
  3. DEV Community — 318 vulnerabilità in 100 app vibe-coded. Citato in getautonoma.com.
  4. Wiz Research — Moltbook breach: 1,5M token API, 35.000+ email, 4.060 messaggi privati esposti.
  5. AIM Security / Kaspersky Blog (ottobre 2025) — CVE-2025-54135 “CurXecute”: RCE in Cursor.
  6. Kaspersky Blog (ottobre 2025) — CVE-2025-53109: RCE tramite server MCP di Anthropic.
  7. Infosecurity Magazine (marzo 2026) — Georgia Tech Vibe Security Radar: 74 CVE confermate, stima 400-700.
  8. Rapporto Clusit 2026, Security Summit 17 marzo 2026 — 507 incidenti in Italia, +42%; manifatturiero secondo settore più colpito; 16% degli attacchi globali al manifatturiero in Italia.
  9. Andrej Karpathy, febbraio 2025 — Conio del termine “vibe coding”. Fonte: Medium/InsTunnel; Contrast Security.

Leave a comment

tredici + 11 =

Cerca nel Blog

Search

Articoli Recenti

13. Il codice che non puoi leggere vibe coding e sicurezza informatica
Esplora
Trascina