I rischi per la sicurezza del vibe coding non sono come i normali rischi per la sicurezza

Probabilmente era inevitabile che il vibe coding causasse una cascata di modifiche complesse alle pratiche di codifica e allo sviluppo software. Poiché il codice generato dall'AI continua a costituire una quota sempre maggiore delle basi di codice reali, una delle novità più importanti è stato un cambiamento significativo nella quantità dei rischi di cybersecurity e nella natura di tali rischi.

In poche parole, il vibe coding è l'idea di creare prodotti utilizzando esclusivamente strumenti di AI e prompt in linguaggio naturale. È diverso dall'agentic coding o dall' agentic engineering, che comportano un uso più deliberato degli strumenti di AI coding da parte di un programmatore esperto. Il termine è stato coniato in un tweet di Andrej Karpathy, stimato sviluppatore e veterano dell'AI, in cui descriveva uno stile di AI coding libero basato interamente su prompting da modelli linguistici di grandi dimensioni (LLM), permettendo all'utente di "lasciarsi andare alle vibes" e di "dimenticare l'esistenza del codice."

Lo ha descritto come un approccio divertente ai "progettini del fine settimana", ma la proliferazione di potente AI coding ha aperto le porte al vibe coding sul posto di lavoro, persino nei software di produzione che gestiscono dati sensibili. Alla fine del 2025, ricerche del settore indicano che il codice generato dall'AI rappresenta ora il 22% di tutto il codice fuso.¹ Su GitHub, i report stimano che il 46% di tutto il codice scritto sia stato generato da Copilot.²

Ciò ha determinato un notevole aumento delle vulnerabilità e dei problemi di sicurezza, ben oltre quanto spiegabile con il naturale incremento del volume e della velocità di nuovo codice reso possibile dagli assistenti di codifica. Un'analisi delle basi di codice del mondo reale ha rilevato che, mentre i team assistiti dall'AI spedivano il codice 4 volte più velocemente, riscontravano 10 volte più falle di sicurezza.³

Abbandonare completamente il vibe coding sacrificherebbe significativi guadagni di produttività dovuti all'automazione e a una maggiore partecipazione, ma è chiaro che le pratiche di codifica sicura devono evolversi di pari passo. I controlli di sicurezza tradizionali sono progettati per indirizzo come gli sviluppatori, e più nello specifico gli sviluppatori umani formati, commettono tipicamente errori. Le organizzazioni necessitano ora di un livello di sicurezza aggiornata e di strumenti di sicurezza all'avanguardia, adattati alla nuova realtà guidata da agenti AI e da vibe coders.

Su diverse piattaforme, ambienti e LLM, le ricerche del settore indicano costantemente che un aumento della generazione di codice con l’AI è accompagnato da un aumento delle vulnerabilità nella sicurezza delle applicazioni (AppSec).

Ad esempio:

• Uno studio di dicembre 2025 su repository open source ha rilevato che il codice generato da AI introduceva vulnerabilità di sicurezza nel 45% dei compiti di sviluppo. Confrontando le pull request (PR) basate sull’AI con le PR esclusivamente umane, i ricercatori hanno scoperto che le PR basate sull’AI generavano 2,74 volte più problemi di sicurezza (e 1,7 volte più problemi complessivi) rispetto al codice scritto dagli umani.⁴

• Un report di GitGuardian del 2026 sull’espansione incontrollata dei segreti postula che i commit assistiti da Claude Code ha esposto più del doppio dei dei segreti rispetto a quelli eseguiti da soli umani. Complessivamente, i segreti hardcoded (come password e chiavi API) esposti nei commit pubblici di GitHub sono aumentati del 34% su base annua nel 2025, il maggiore incremento annuale mai registrato.⁵ 

• Un report dell’ottobre 2025 ha rilevato che le vulnerabilità critiche e l’esposizione dei dati nelle applicazioni vibecoded, come le API mal configurate e altri problemi di autenticazione, erano spesso “all’aperto” e accessibili direttamente tramite endpoint pubblici.⁶

I team di sicurezza devono anche considerare che i repository pubblici su GitHub (e servizi simili) sono solo la punta dell’iceberg. GitGuardian suggerisce che i repository interni hanno sei volte più probabilità di contenere segreti hardcoded rispetto ai repository pubblici.

Ugualmente preoccupante è il fatto che le credenziali sensibili esposte tramite vibe coding sembrano essere meno propense ad essere affrontate e risolte rispetto ai problemi di sicurezza che sorgono dai workflow tradizionali di codifica. Il report di GitGuardian ha evidenziato che quasi il 70% delle credenziali esposte, convalidate come legittime nel 2022, sono rimaste valide fino a gennaio 2025. A gennaio 2026, il 64% risultava ancora esposto e non revocato. In un episodio notevole, Football Australia ha involontariamente rivelato le sue chiavi di accesso AWS nel codice sorgente del suo sito web, e sono rimaste esposte per oltre 700 giorni.

Messi insieme, questi modelli suggeriscono che i rischi di sicurezza del vibe coding si stanno accumulando a un ritmo superiore a quello per cui i programmi di correzione tradizionali erano progettati.

La frequenza e l'entità delle vulnerabilità di sicurezza derivate dall'AI sembrano persistere anche mentre le funzionalità degli LLM continuano a migliorare. Gli osservatori del settore hanno quindi suggerito che le pipeline di addestramento e i benchmark utilizzati per ottimizzare e convalidare le prestazioni dei modelli non sono sempre naturalmente allineati con la generazione sicura del codice nel mondo reale.⁴ La maggior parte degli studi valuta il codice generato dall'AI in modo isolato, concentrandosi sulla correttezza, indipendentemente dal fatto che si limiti a compilare, eseguire ed eseguire il suo compito, e sulle prestazioni sui benchmark.⁷

Ma negli ambienti di sviluppo aziendali i modelli non operano in modo isolato. Il rapporto di GitGuardian ha rilevato che infrastrutture legate agli LLM, come i servizi per orchestrazione, retrieval-augmented generation (RAG) o storage, esponevano segreti a un tasso cinque volte superiore rispetto a quello dei fornitori di modelli core.⁵

In altre parole, molti rischi di sicurezza derivanti dal vibe coding non derivano dagli LLM: derivano dall'ecosistema in cui i modelli sono utilizzati. I nuovi provider di inferenza, gateway, registri e livelli di integrazione entrano rapidamente nei workflow di produzione, spesso troppo rapidamente perché i livelli di sicurezza (o i vibe coder principianti) possano stare al passo.

L'agentic AI aggiunge ulteriore complessità alle considerazioni di sicurezza: quando a un agente AI viene concesso l'accesso locale a file, archivi di credenziali e terminali, il computer stesso può diventare un'altra superficie di attacco. Inserzioni tempestive e attacchi alla supply chain che sfruttano credenziali locali esposte possono trasformarsi in rischi organizzativi. Nel famigerato worm Shai-Hulud, che ha compromesso il più grande registro JavaScript al mondo alla fine del 2025, quasi il 60% delle macchine compromesse non erano workstation personali ma runner di integrazione/consegna continua (CI/CD) ⁴ (il cui scopo, ironicamente, è automatizzare i test di sicurezza e garantire la qualità del codice).

Un fattore esacerbante importante per i rischi di sicurezza del vibe coding è il modo in cui le modifiche al codice basate sull'AI sono tipicamente impacchettate: in media, gli sviluppatori assistiti dall'AI producono più di tre volte i commit rispetto ai loro colleghi analogici, ma impacchettano questi commit in un numero di pull request (PR) molto inferiore e con dimensioni molto più grandi. Queste PR vibe-coded sono solitamente di portata più ampia e alterano più file e servizi.

Il "Developer Habits Report" di Cursor, pubblicato nella primavera del 2026, ha rilevato che il numero medio di righe di codice per PR era aumentato di circa il 250% anno dopo anno (e che il tasso di crescita stesso stava accelerando). Le "Mega PR", definite da Cursor come PR contenenti modifiche ad almeno 1.000 righe di codice, sono passate da una quota dell'8% di tutte le PR a gennaio 2025 al 13,9% di tutte le PR a maggio 2026.⁸

Le PR grandi ed estese che toccano molte parti della base di codice sono molto più difficili da revisionare in modo esaustivo rispetto ai PR più piccoli e mirati. Modifiche isolate a un servizio o blocco di codice potrebbero richiedere ulteriori modifiche altrove per evitare problemi a valle, ma questi effetti accessori sono meno propensi a essere catturati nella revisione del codice se la PR esaminata adotta un approccio a pompa che diluisce l'attenzione del revisore. Una ricerca di Apiiro, una piattaforma AppSec, ha rilevato che, mentre il volume di PR per i team assistiti dall'AI è diminuito di quasi un terzo, questi team hanno inviato 10 volte più difetti di sicurezza.³

In breve, l'AI accelera ogni parte della creazione del codice, compresa la cattiva abitudine di implementare troppe modifiche contemporaneamente. Concentrare e accelerare il cambiamento può anche concentrare e accelerare il rischio di ogni fusione.

Uno studio su larga scala su 500.000 campioni di codice, presentato al 36° IEEE International Symposium on Software Reliability Engineering (ISSRE 2025), ha determinato che "il codice generato dall'AI differisce dal codice scritto dagli esseri umani non solo per il numero di vulnerabilità di sicurezza ma anche per la loro natura e distribuzione." 

Questo solleva una preoccupazione esistenziale: i framework esistenti per valutare la qualità del codice e le vulnerabilità di sicurezza sono "centrati sull'uomo, progettati attorno a assunzioni sulla cognizione umana, modalità di errore e processi di revisione." Il codice generato dall'AI dimostra caratteristiche e tendenze notevolmente diverse, il che rende quei framework incentrati sull'uomo poco adatti a valutarlo.⁷

A complicare ulteriormente la questione, la ricerca sulla sicurezza del vibe coding ha anche rivelato molteplici tipologie emergenti di attacchi che non hanno equivalenti nei software scritti da esseri umani.

Gli LLM e gli strumenti di codifica AI che alimentano tendono a raccomandare pacchetti che in realtà non esistono, e le ricerche hanno scoperto che questi nomi allucinati a volte si ripetono in diversi scenari e persino in modelli differenti. Lo slopsquatting, un tipo di attacco di allucinazione, utilizza questa tendenza.

I criminali informatici che praticano lo slopsquatting osservano i nomi dei pacchetti fittizi che gli LLM generano ripetutamente e pre-registrano questi nomi di pacchetto (precedentemente) inventati nei registri pubblici. Quando i vibe coder, spesso del tutto ignari di pacchetti comunemente usati (e che pertanto tenderanno a non individuarne uno falso), effettuano il commit del codice contenente questi nomi di pacchetto, stanno inconsapevolmente installando codice malevolo.

Questo non ha analogie nello sviluppo software tradizionale. Un programmatore umano difficilmente avrebbe allucinazioni su un pacchetto che non esiste e, anche se lo facesse, sarebbe impossibile e poco pratico per un potenziale criminale informatico prevederlo, indovinare il nome del pacchetto allucinato e registrare codice malevolo sotto quel nome.

Gli attacchi backdoor ai file di regole sfruttano i file di configurazione ("regole") utilizzati per personalizzare il comportamento degli agenti AI durante la generazione o la modifica del codice su piattaforme come Cursor, GitHub Copilot e Claude Code. 

I criminali informatici tipicamente modificano i file di regole open source più diffusi, incorporando istruzioni malevole sotto forma di caratteri Unicode nascosti quasi impossibili da rilevare. Una volta accettate queste modifiche, quel codice malevolo verrà attivato in ogni successiva sessione di AI coding che faccia riferimento al file di regole infette. Di conseguenza, qualsiasi codice generato durante tali sessioni sarà compromesso, ma poiché l'output compromesso è composto da caratteri Unicode essenzialmente invisibili, appare pulito nella revisione del codice.

L'obiettivo dei criminali informatici è solitamente quello di introdurre vulnerabilità e "backdoor" nel codice generato successivamente (e nelle applicazioni che utilizzano tale codice) che potranno sfruttare in seguito.

Armate di una comprensione di questi specifici schemi, le organizzazioni dovrebbero aggiornare le loro migliori pratiche di sicurezza per beneficiare dei vantaggi del codice generato dall'AI senza cadere vittima dei tipi di vulnerabilità che emergono dal vibe coding indiscriminato.

Sebbene il potenziale di questi difetti di sicurezza possa derivare dalle imperfezioni degli strumenti di AI coding, la realizzazione di questi rischi è un fallimento della supervisione umana. In definitiva, gli sviluppatori hanno ancora il controllo su quali aggiunte e modifiche vengono accettate, riviste o ignorate. Gli assistenti di codifica continuano ad espandere e migliorare i loro guardrail integrati, ma la revisione umana rimane l'ultimo ostacolo alla pubblicazione delle vulnerabilità di sicurezza, motivo per cui le impostazioni predefinite di IBM integrano le recensioni manuali e l'approvazione umana in ogni fase.

Ciò detto, esistono modi per migliorare l'efficacia della recensione umana.

• I difetti nascosti in pull request enormi e estese sono molto più difficili da individuare in un controllo di sicurezza rispetto a quelli situati in PR più mirati. Di conseguenza, i team di sicurezza dovrebbero implementare le linee guida per le dimensioni delle PR.

• I pacchetti devono essere esaminati con particolare attenzione per ridurre al minimo il rischio di attacchi slopsquatting. I team di sicurezza devono tenere presente che con ogni nuova iterazione di un determinato modello AI, possono emergere nuovi modelli di allucinazioni dei pacchetti.

• Sviluppatori e team di sicurezza dovrebbero familiarizzare con le differenze tra difetti di codice scritti da umani e quelli generati dall'AI.

Le organizzazioni dovrebbero considerare il codice generato dall'AI come una categoria di input distinta che richiede controlli di sicurezza dedicati (piuttosto che semplicemente integrare l'output dell'AI nei processi di recensione standard e orientati all'umano).

Come assioma generale, le organizzazioni dovrebbero trattare qualsiasi codice o modulo derivato dall'AI come input non affidabile, allo stesso modo in cui tratterebbero il codice di libreria esterna. Il test di sicurezza ad analisi statica (SAST) devono fungere da barriera obbligatoria attraverso la quale tutti i contributi dell'AI devono passare prima di entrare nel codice base. I file di regole di terze parti, come open source o regole cursore preconfigurate, file Claude.md , istruzioni Copilot o modalità Bob, dovrebbero essere esaminati attentamente e aggiunti selettivamente a una whitelist successivamente, piuttosto che consentiti di default.

Il continuo miglioramento delle piattaforme di agentic engineering offre un'opportunità per combattere il fuoco con il fuoco attraverso il rilevamento dei segreti basato sull'AI, in cui credenziali specifiche per l'AI, come chiavi API LLM o token vettoriali di database, hanno proprie firme di rilevamento dedicate.

 IBM Bob, ad esempio, dispone di strumenti integrati per imporre la codifica sicura e il controllo degli accessi su larga scala attraverso una combinazione di modalità personalizzate Bob, integrazione con HashiCorp Vault e IBM MCP Gateway. Esegue inoltre revisioni del codice in tempo reale, scansionando il codice alla ricerca di problemi di complessità, potenziali vulnerabilità e opportunità di rifattorizzazione che possono essere affrontate in linea o revisionate successivamente nel pannello Bob Findings .

La capacità di rilevare difetti appena introdotti in una base di codice dipende in gran parte dalla leggibilità di quella base. Definire e far rispettare gli standard di qualità del codice è pertanto essenziale per agevolare recensioni produttive di sicurezza. Gli standard condivisi e il refactoring di routine massimizzeranno le possibilità che il codice non sicuro venga identificato e risolto.