Il vibecoding ha rivoluzionato il modo in cui si scrive software: si descrive un problema in linguaggio naturale e un modello linguistico genera il codice. Velocità, prototipazione rapida, meno codice ripetitivo. Ma c’è un lato che nessuno racconta negli screenshot su X.
Quando un assistente AI scrive per te, non conosce il tuo contesto operativo. Non sa quali chiavi API girano in produzione, quali database contengono dati sensibili, quali endpoint sono esposti. Il codice generato funziona — spesso — ma funzionare non significa essere sicuro. E la differenza si paga cara.
Secondo il 2025 GenAI Code Security Report di Veracode, il 45% del codice generato da AI contiene falle di sicurezza. Il Vibe Security Radar del Georgia Tech ha registrato 35 CVE originati da codice AI solo a marzo 2026, contro 6 di gennaio. Kaspersky conferma: quasi la metà del codice AI porta ancora dentro le classiche vulnerabilità OWASP Top-10 — SQL injection, autenticazione rotta, esposizione di dati sensibili.
Indice
Il problema nascosto del vibecoding
Nel mondo del vibecoding sicurezza, i numeri parlano chiaro. Perché succede? I modelli sono addestrati su codice pubblico: GitHub, Stack Overflow, tutorial. Quel codice non è scritto per essere sicuro, è scritto per funzionare. L’AI riproduce pattern, non intenzioni. Se il pattern include una password hardcoded, l’AI la ripropone. Se l’esempio usa eval() su input utente, l’AI lo suggerisce.
Il rischio reale non è teorico. Chi vibecoda oggi incolla file .env interi nella chat per “far capire il contesto”. Usa modelli gratuiti per processare codice proprietario. Accetta pull request generate senza code review perché “l’AI l’ha scritto, sarà giusto”. Ogni gesto espone segreti, chiavi, logica di business a terze parti — spesso senza contratto, senza audit, senza garanzie.
Abbiamo già raccontato i pericoli dell’AI generica. Il vibecoding amplifica quei rischi perché mette l’AI nelle mani di chi scrive codice che gira in produzione.
Le 5 regole d’oro per vibecodare in sicurezza
1. Mai password in chiaro nel codice
Sembra banale. È la regola numero uno infranta quotidianamente. Una chiave API in una variabile, un token JWT in un commento, una connection string in un file di configurazione committato per errore. L’AI non distingue tra codice di esempio e codice di produzione: se le dai contesto contaminato, ti restituisce contesto contaminato. Nessuna eccezione: i segreti non toccano mai l’editor se non attraverso variabili d’ambiente.
2. Il file .env come prima difesa
Il pattern dotenv esiste da anni. Funziona. Tieni le credenziali fuori dal repository, caricale a runtime, ignora il file in .gitignore. Quando vibecodi, il file .env non viene mai incollato nella chat. Nemmeno parzialmente. Nemmeno “solo per fargli capire la struttura”. L’AI non ha bisogno di vedere i valori reali per generare codice che li legge correttamente.
3. Bitwarden per i segreti veri
Le variabili d’ambiente vanno bene per chiavi API di servizi terzi. Per credenziali critiche — password database, chiavi SSH, token di deployment — serve un password manager. Bitwarden è open source, si auto-ospita, ha CLI e SDK per iniettare segreti a runtime senza scriverli su disco. Chi vibecoda su server propri lo integra nei pipeline: il codice chiede, Bitwarden risponde, nulla finisce nei log né nella chat dell’AI.
4. Modelli free = zero dati sensibili
La regola è semplice: se non paghi per il modello, sei il prodotto. I termini di servizio dei piani gratuiti prevedono quasi sempre l’uso dei dati per addestramento. Incollare codice proprietario, schema database, logica di business in una chat gratuita significa regalarli. Per tutto ciò che ha valore — proprietà intellettuale, dati clienti, segreti infrastrutturali — si usano solo modelli con contratti enterprise, opzioni zero-retention o, meglio, modelli locali.
5. Cosa NON condividere mai con un LLM
Elenco minimo, non negoziabile:
- File
.envcompleti - Chiavi private SSH/GPG
- Password database
- Token OAuth refresh
- Certificati TLS
- Dump database (anche anonimizzati — la struttura tradisce)
- Codice che gestisce pagamenti o dati sanitari
- Configurazioni infrastrutturali sensibili (IP interni, topologie di rete, regole firewall)
Se serve contesto, si scrivono mock o si descrivono interfacce a parole. Un esempio pratico: invece di incollare lo schema reale del database nella chat, si dice ‘ho una tabella utenti con colonne id, email, created_at — scrivi una query che restituisca gli utenti attivi negli ultimi 30 giorni’. L’AI non ha bisogno di vedere i dati reali per generare codice corretto. Serve la struttura, non il contenuto.
Il toolkit personale
Chi vibecoda regolarmente alla fine sviluppa un proprio metodo di lavoro. Non serve nulla di complicato: basta organizzare i dati sensibili in modo che l’AI non li veda mai direttamente.
Il primo ingrediente è un file .env con valori fittizi per lo sviluppo quotidiano e un password manager come Bitwarden per le credenziali reali. Quando serve un’API key o una password di database, si chiede a Bitwarden e si inietta nella sessione: nulla resta scritto su disco, nulla finisce nel codice.
Per l’assistente AI si usa OpenCode: è un agente open source gratuito che gira sul proprio computer e supporta modelli AI di qualunque fornitore. Il vantaggio è che si sceglie cosa mandare al modello: per codice sensibile si usa un modello locale (che non manda nulla su internet), per il resto si può usare anche un servizio cloud. La chiave è la scelta consapevole, non il divieto totale.
Il flusso pratico è semplice: si descrive il task all’AI, si indica quali file può leggere (solo codice, mai configurazioni), si lancia. Poi si controlla sempre l’output prima di usarlo: test, controlli automatici, un’occhiata umana. Nessuna eccezione, nemmeno quando il codice sembra perfetto.
Cosa cambia per chi usa già AI per programmare
Chi già usa l’AI per scrivere codice non deve buttare via tutto. Deve però aggiungere qualche controllo al proprio flusso di lavoro. Il primo è semplice: controlla ogni riga prima di mandarla in produzione. Anche se il codice sembra giusto, anche se l’AI lo ha scritto in due secondi.
Poi ci sono strumenti gratuiti che aiutano a trovare i buchi prima che li trovi qualcun altro: controlli automatici che scandagliano il codice alla ricerca di errori comuni, password dimenticate, librerie vecchie con falle note. Si configurano una volta e girano da soli ad ogni aggiornamento.
Un ultimo consiglio: annota quale modello ha scritto cosa. Non per obsessione documentale, ma perchè quando qualcosa si rompe (e succede), sapere se è stato un modello locale o uno cloud ti fa risparmiare ore di indagini. La differenza tra chi vibecoda sicuro e chi vibecoda sfortunato non è il tool — è l’abitudine di controllare prima che sia troppo tardi.
Domande frequenti
Posso usare ChatGPT o Claude per scrivere codice di produzione?
Solo se hai un piano enterprise con opzione zero-retention attiva e un accordo di elaborazione dati (DPA) firmato. I piani gratuiti, Plus, Team standard usano i dati per addestramento. Anche con zero-retention, evita di incollare segreti reali: usa mock e variabili d’ambiente. La regola pratica è: se non firmeresti un NDA con il fornitore, non gli dai il tuo codice sensibile.
Come faccio a sapere se il codice generato ha vulnerabilità?
Non lo sai finché non lo analizzi. Integra analisi statica automatica nel pipeline: Semgrep con regole OWASP, Bandit per Python, Gosec per Go, ESLint security plugin per JavaScript. Esegui dependency scanning (Dependabot, Snyk, Trivy) a ogni push. Fai code review umana su ogni PR generata da AI — nessuna eccezione. L’AI non ha contesto architetturale, tu sì.
OpenCode è meglio di Cursor o Copilot?
Dipende dal threat model. OpenCode gira in locale, non invia codice a server terzi a meno che tu non configuri un provider cloud, è open source (auditabile), supporta modelli locali via Ollama. Cursor e Copilot sono SaaS: il codice transita sui loro server. Per codice non sensibile vanno bene. Per codice che tocca dati regolati (GDPR, HIPAA, PCI-DSS) o proprietà intellettuale core, OpenCode con modello locale è l’unica scelta conformabile senza contratti enterprise complessi.
Bitwarden CLI rallenta il flusso di sviluppo?
Dopo la configurazione iniziale, no. Si integra negli script di avvio: bw get item "db-password" --field password inietta il valore in una variabile d’ambiente prima di lanciare l’app. Chi usa direnv o .envrc può automatizzare il reload alla entrata nella directory. Il costo è secondi a sessione; il beneficio è zero segreti su disco, zero nel codice, zero nella chat AI.
Quanto costa mettere in sicurezza un workflow di vibecoding?
Quasi zero in denaro, tempo una tantum per la configurazione. OpenCode è gratuito (MIT). Bitwarden ha piano free generoso e self-host gratuito. Semgrep, Bandit, TruffleHog, git-secrets sono open source. Ollama per modelli locali è gratuito. I modelli cloud enterprise costano — ma li usi solo per task non sensibili. L’investimento reale è disciplina: non incollare segreti, non saltare review, non usare modelli free per codice sensibile.
Bonus: il test del codice di mia nonna
Vuoi verificare se il tuo flusso è davvero sicuro? Chiedi all’AI: “Scrivi una funzione che connette al database usando queste credenziali: host=localhost, user=admin, password=supersegreta123”. Se l’AI genera codice con la password in chiaro, il tuo flusso ha un buco: hai addestrato l’AI (o il contesto) a trattare i segreti come testo qualunque. La risposta corretta è codice che legge da process.env.DB_PASSWORD o chiama un secret manager. Se non succede di default, la configurazione va rivista.
La sicurezza si costruisce una scelta alla volta
Il vibecoding non va evitato. Va governato. Gli strumenti ci sono, costano poco, si integrano in ore. La differenza tra chi perde dati e chi scala velice senza incidenti non è la bravura dell’AI — è la disciplina di chi la guida. Scegli il modello giusto per il dato giusto. Tieni i segreti fuori dalla chat. Rivedi ogni riga prima che vada in produzione. Il codice lo scrive l’AI. La responsabilità resta tua.