Rischi legati alla programmazione Vibe: sicurezza, manutenibilità e idoneità alla produzione

Un'app creata chiedendo a un agente di intelligenza artificiale di generare codice può sembrare completamente finita e tuttavia presentare rischi reali per la sicurezza, come un controllo di autenticazione che non è mai stato scritto o un segreto contenuto in un file di configurazione. Nulla di tutto ciò emerge nella demo. Viene alla luce solo quando qualcuno con intenzioni malevole ci dà un'occhiata.

La sicurezza del "vibe coding" è il rischio più evidente, ma non è l’unico. La stessa velocità che rende attraente il "vibe coding" non si ferma a verificare se un'app sia in grado di reggere dal punto di vista operativo e di rimanere gestibile dopo che chi l'ha realizzata ha voltato pagina.

Questo articolo illustra i controlli che vale la pena eseguire prima che un'app realizzata con il "vibe coding" gestisca dati reali o assuma responsabilità aziendali, tre esempi di dove inizia il rischio e i percorsi disponibili una volta completata la revisione.

Quando un prototipo realizzato con il “vibe coding” diventa un rischio aziendale?

La programmazione "vibe" è il processo che consiste nel dare istruzioni a un agente di programmazione basato sull’intelligenza artificiale fino a quando un’applicazione non fa ciò che si desidera, con pochissima codifica manuale rispetto a quanto richiesto dallo sviluppo tradizionale di software. Ciò che conta davvero in termini di rischio, però, non è come è stata costruita l’app, ma cosa cambia una volta che non è più una demo.

Immaginate tre esempi, ciascuno a basso rischio all’inizio:

• Un mockup che utilizza dati di esempio per mostrare come potrebbe apparire una nuova dashboard. Il punto di svolta arriva quando inizia a prelevare dati in tempo reale invece che campioni.
• Un modulo di richiesta interno che consente ai dipendenti di inviare richieste di permessi, inizialmente limitandosi a registrarle in un foglio di calcolo. Il punto di svolta si verifica quando ottiene l’autorizzazione ad aggiornare effettivamente i registri aziendali.
• Un portale rivolto ai clienti che mostra la cronologia degli ordini e i dettagli dell’account. Il punto di svolta si verifica quando il portale viene aperto a clienti reali anziché a una manciata di tester interni.

Nessuno di questi progetti è pericoloso all’inizio. Ciò che cambia in ciascuno di essi è la stessa cosa che si presenta in una forma diversa, che si tratti di dati reali, autorizzazioni reali o utenti reali che sostituiscono un sostituto sicuro.

Ciò che conta davvero sono gli utenti di un’app, il suo accesso ai dati, con cosa è integrata e quanto un flusso di lavoro dipenda ora da essa, non se la demo apparisse ben rifinita. Neanche uno strumento interno è automaticamente a basso rischio. Gestire dati sensibili o apportare modifiche a registri importanti può comportare un rischio pari a quello di qualsiasi cosa rivolta ai clienti.

Cosa dovrebbero verificare i team prima del lancio?

Gli sviluppatori professionisti e i citizen developer utilizzano ormai strumenti di codifica basati sull’IA per trasformare prompt in linguaggio naturale in software funzionante attraverso iterazioni rapide, spesso senza la supervisione umana che i team di sicurezza normalmente si aspetterebbero. Si tratta dello sviluppo assistito dall’IA nella sua forma più veloce, e la velocità non si ferma per i consueti controlli.

La velocità con cui l’IA genera codice comprime i processi di sicurezza tradizionali, come la scrittura, la revisione e la distribuzione, in un unico ciclo di programmazione. Ciò significa che i problemi che un processo più lento normalmente rileverebbe, come falle di sicurezza o casi limite trascurati, possono invece arrivare direttamente in produzione. Gli strumenti tradizionali di AppSec (sicurezza delle applicazioni) sono ancora utili, ma non sono stati progettati per il ritmo a cui si muovono oggi gli strumenti di vibe coding . Possono inoltre trascurare difetti logici che emergono solo quando si comprende effettivamente a cosa serva una determinata funzionalità.

Garantire la sicurezza del risultato del vibe coding inizia con le stesse cinque domande a cui ogni app di produzione dovrebbe rispondere.

1. A quali dati può accedere l’app e chi può utilizzarli?

Si inizi con la sensibilità dei dati, le credenziali, l’autenticazione, i controlli di sicurezza e le autorizzazioni. È stata effettivamente effettuata una revisione umana, come la revisione del codice su una pull request, o si è ricorso solo a controlli automatizzati? L’accesso è stato testato per gli utenti che non dovrebbero poter visualizzare o modificare qualcosa, non solo per quelli che invece dovrebbero poterlo fare?

La sensibilità dei dati non è nemmeno solo una questione di giudizio interno. Un’app che gestisce cartelle cliniche, dati di pagamento o informazioni personali può rientrare in normative come HIPAA, SOX o GDPR , e il loro rispetto può richiedere vere e proprie modifiche architetturali piuttosto che una semplice spunta su una casella di una politica.

Il codice di esempio copiato dalla prima bozza di un prompt non è di per sé un codice sicuro. Il codice non sicuro legato alla logica di autenticazione è una delle cose più facili da trascurare in una revisione veloce. I modelli di IA addestrati su enormi quantità di dati di addestramento possono riprodurre schemi non sicuri e altre vulnerabilità di sicurezza senza che nessuno lo intenda.

Uno studio della NYU ampiamente citato ha rilevato che GitHub Copilot ha generato bug sfruttabili o difetti di progettazione rilevanti per la sicurezza in circa il 40% dei casi di test, mentre il benchmark BaxBench ha rilevato che il 62% delle soluzioni, anche quelle provenienti dal modello con le migliori prestazioni, erano errate o contenevano una vulnerabilità di sicurezza. Considerare sicuro il codice generato dall’IA solo perché funziona è il modo in cui questi schemi sfuggono all’attenzione.

Documentate a quali dati e sistemi l’app può accedere, quali ruoli hanno l’autorizzazione a utilizzarla e cosa hanno rilevato i test di accesso.

2. Gestisce correttamente le regole di business e gli errori?

Testare il percorso previsto ti mostra solo il caso ideale in cui la logica di business funziona. Prova anche input non validi, informazioni mancanti, azioni in conflitto e richieste fallite. In condizioni d’uso previste, comprese azioni simultanee o un picco di traffico dove pertinente, l’app si comporta ancora come dovrebbe?

I difetti del software e la logica non sicura nascosti all’interno di una funzionalità altrimenti funzionante raramente vengono alla luce finché qualcuno non testa i percorsi che nessuno aveva pensato di provare. Una funzione generata dall’IA può superare ogni test che qualcuno abbia pensato di scrivere e comunque fallire quello che nessuno ha previsto.

Riflettete su cosa succede se il risultato è semplicemente sbagliato, specialmente per qualsiasi operazione che elabori ordini, approvazioni o modifiche agli account. Registrate quali scenari sono stati testati e quali errori rimangono ancora irrisolti. “Funziona” e “produce costantemente il risultato corretto” sono due constatazioni molto diverse, ed è facile confondere l’una con l’altra.

3. Cosa succede quando un’integrazione smette di funzionare?

Identificate ogni sistema da cui l’app legge o su cui scrive, comprese eventuali risorse cloud che può creare, modificare o eliminare durante il processo. Cercate aggiornamenti incompleti, azioni duplicate, dati incoerenti e messaggi di errore che aiutino effettivamente a capire cosa sia andato storto. Il team è in grado di rilevare un’integrazione fallita e di ripristinare la situazione in modo sicuro?

Documentate le integrazioni stesse, cosa hanno evidenziato i test di errore negli ambienti di prova e come il team correggerebbe o annullerebbe un’azione completata solo parzialmente.

4. Un’altra persona è in grado di gestirla?

Il modo in cui è stato generato il codice dall’IA è importante tanto quanto il fatto che funzioni. Un’app generata dall’IA che nessuno è in grado di spiegare è più difficile da mantenere rispetto al codice esistente o a quello scritto da esseri umani che ha già attraversato il normale processo di sviluppo del team.

Il controllo di versione che tiene traccia di ogni ciclo di generazione del codice fornisce a un futuro manutentore una traccia documentale che i prompt da soli non offrono, e ogni nuovo lotto di codice generato dall’IA dovrebbe avere qualcuno responsabile della sua revisione prima della distribuzione.

Qualcuno, oltre al creatore originale, deve essere in grado di spiegare i percorsi di codice importanti, le dipendenze e le decisioni di progettazione, non limitandosi a ricordare approssimativamente cosa avrebbe dovuto fare un prompt o una serie di strumenti di sviluppo. Cercate test che rendano più sicure le modifiche future e un responsabile che sia effettivamente incaricato di mantenere l’applicazione funzionante.

Verificate che sia il responsabile che almeno un altro membro qualificato del team siano in grado di capire come modificare l’app senza fare affidamento sulla memoria dello sviluppatore originale o sulla cronologia dei prompt. Una revisione manuale da parte di qualcuno che non abbia familiarità con il progetto è un buon test in tal senso.

5. Il team è in grado di fornire assistenza dopo il lancio?

Verificate chi riceve effettivamente gli avvisi, indaga sugli incidenti, approva le modifiche e gestisce gli aggiornamenti una volta che l’app è attiva. Dove verrà eseguita, in che modo le modifiche raggiungeranno effettivamente i sistemi di produzione e come farebbe il team a identificare e annullare una versione difettosa? La visibilità in fase di esecuzione, ovvero la capacità effettiva di vedere cosa sta facendo l’app una volta che è online, è importante qui tanto quanto lo era durante i test.

Verificate se il team è in grado di ripristinare il servizio dopo un'interruzione, non solo di rilevarne il verificarsi. Registrate il responsabile dell’assistenza, la configurazione degli avvisi e le procedure di rilascio e ripristino. L’assistenza continua deve far parte della preparazione al lancio sin dall’inizio, non essere un compito assegnato a qualcuno dopo il primo incidente.

Cosa dovreste fare dopo la revisione dei rischi?

La revisione tecnica non comporta sempre piccole correzioni. Può portare a cambiamenti concreti, a una ricostruzione sostanziale o al passaggio a un approccio di implementazione completamente diverso.

Non esiste un punteggio di rischio rigido che renda automatica questa decisione. Ciò che conta è disporre di prove concrete a sostegno di qualsiasi percorso venga scelto e di qualcuno che lo approvi effettivamente. Il responsabile dell’applicazione dovrebbe coinvolgere revisori tecnici e di sicurezza, a seconda del livello di rischio dell’applicazione.

In che modo Liferay DXP può inserirsi in questo processo decisionale?

Quando una revisione suggerisce di realizzare qualcosa di diverso piuttosto che applicare patch a ciò che esiste, la domanda successiva è su quale base realizzarlo. Molti degli aspetti effettivamente segnalati dalla revisione – proprietà dei dati poco chiara, fasi di approvazione mancanti, autorizzazioni che nessuno ha definito in modo completo – sono lacune che una piattaforma governata è progettata per colmare di default, non problemi che un team deve progettare e verificare da solo.

Liferay DXP affronta questo aspetto attraverso:

• Oggetti che conferiscono ai dati strutturati una forma definita, un proprietario e una cronologia fin dall’inizio
• Moduli che acquisiscono gli input con validazione e autorizzazioni già integrate
• Flussi di lavoro che indirizzano le approvazioni attraverso fasi che un team può visualizzare e verificare
• Ruoli e autorizzazioni che controllano l’accesso a livello di piattaforma, non nascosti all’interno del codice dell’applicazione
• API e integrazioni che si collegano ai sistemi esistenti attraverso un percorso supportato e testato

Nulla di tutto ciò elimina la necessità di un giudizio. Un team deve comunque decidere cosa appartiene effettivamente alla piattaforma e cosa richiede realmente uno sviluppo personalizzato, e qualsiasi componente personalizzato necessita comunque della stessa revisione e degli stessi test di tutto il resto. Ciò che cambia è il punto di partenza. Anziché dover verificare da zero autorizzazioni, approvazioni e integrazioni, un team che sviluppa su questa piattaforma parte da qualcosa che ha già superato tale soglia.

Prendere la decisione di messa in produzione in modo ponderato

La vera domanda non è se un’app sembri completa. È piuttosto quali requisiti debba soddisfare affinché questa specifica app sia sicura e su cui ci si possa effettivamente fare affidamento. Il percorso giusto dipende dal suo scopo, a cosa è esposta e per quanto tempo si prevede che rimanga in uso, non da come è stata originariamente realizzata.

Esplora le funzionalità low-code di Liferay DXP se una base applicativa governata ti sembra la scelta giusta per il futuro.

Domande frequenti sui rischi legati alla codifica Vibe

Un'app interna sviluppata con Vibe Coding può comunque comportare un rischio elevato?

Sì. Il fatto che sia interna limita solo chi può accedere all'app, non ciò che essa può fare una volta che qualcuno la sta utilizzando. Uno strumento interno che gestisce dati sensibili o modifica record importanti può comportare lo stesso livello di rischio di qualsiasi strumento rivolto ai clienti, a volte anche di più, poiché gli strumenti interni sono spesso sottoposti a un controllo meno rigoroso.

Una verifica di sicurezza significa che un'app sviluppata con Vibe Coding è pronta per la produzione?

Non di per sé. La sicurezza è solo una parte del quadro, indipendentemente dagli strumenti di IA utilizzati per sviluppare l’app. Un’app deve anche gestire correttamente gli errori, superare eventuali problemi di integrazione, poter essere gestita da qualcuno diverso dal suo sviluppatore originale e disporre di un piano di assistenza concreto dopo il lancio.

E se un’app sviluppata “a sensazione” avesse già degli utenti?

Eseguite gli stessi controlli su quell’app sviluppata in modo approssimativo, ma con maggiore urgenza. Gli utenti esistenti non rendono un’app più sicura. Significano semplicemente che le conseguenze di una falla si stanno già manifestando. Date priorità ai controlli legati a qualsiasi dato o processo aziendale con cui l’app interagisce attualmente.

Ogni prototipo realizzato con il "vibe-coding" deve necessariamente diventare un'app di produzione?

No. Molti prototipi realizzati con assistenti di programmazione basati sull’intelligenza artificiale svolgono il loro compito rispondendo a una domanda o verificando un’idea, per poi essere dismessi. La pressione per formalizzare qualcosa di solito emerge solo quando le persone iniziano a fare affidamento su di essa, che è esattamente il momento in cui questo tipo di revisione assume maggiore importanza.