Checklist di sicurezza prima di rilasciare un’app sviluppata con il vibe coding

Prima di rilasciare un’app sviluppata con il vibe coding, individua il commit esatto del rilascio, scansionalo e testa in un ambiente controllato i confini di accesso, la gestione dei segreti e i percorsi di errore. Usa i risultati di vetkit come evidenze da esaminare insieme ai tuoi test e alla configurazione di deploy. Una scansione superata non prova che l’app in esecuzione sia sicura o pronta per il rilascio.

Questa checklist riguarda la decisione di rilascio dopo la code review. Per la revisione riga per riga delle modifiche di un assistente, parti dalla checklist per la revisione del codice generato dall’AI. Conserva le evidenze descritte qui sotto insieme al rilascio, così un’altra persona potrà capire cosa è stato controllato.

1. Lega le evidenze al rilascio

• Annota lo SHA del commit e l’artefatto di build che intendi rilasciare.
• Verifica che il report dell’audit indichi lo stesso commit. Un report relativo a una punta di branch più vecchia non copre correzioni successive né file generati.
• Fai la build ed esegui i test del progetto da quella versione, con una configurazione controllata e dati sintetici. Conserva i risultati effettivi dei comandi, compresi errori e test saltati.

2. Verifica cosa è stato eseguito davvero

Il Security Quick Scan include posture, rilevamento dei segreti con gitleaks e controlli delle dipendenze con OSV. Gli audit più ampi possono includere controlli aggiuntivi, dove il tuo account e il perimetro selezionato lo consentono. Il template di rilascio di vetkit seleziona controlli per aree come analisi statica di sicurezza, infrastruttura, workflow e operabilità, ma non comprende tutti gli analizzatori disponibili. Per esempio, secrets-history e llm-app non rientrano nella selezione di quel template.

Un report parziale significa che uno o più analizzatori non sono stati completati e che le categorie interessate potrebbero essere sottostimate. Colma le lacune di copertura rilevanti o documenta la verifica alternativa prima di fare affidamento sul risultato.

3. Metti alla prova i confini di accesso

In un ambiente di test, crea due account ordinari e un account con privilegi elevati. Prova a leggere e modificare i record di un account usando l’altro, e chiama gli endpoint protetti senza aver effettuato l’accesso. Verifica che il server rifiuti le operazioni non autorizzate anche quando l’interfaccia del browser nasconde il pulsante. Includi download di file, esportazioni e operazioni in background che usano gli stessi dati.

Per un’app basata su Supabase, esamina con record sintetici le policy di row-level security e di storage effettivamente in produzione. Le regole vibe-stack di vetkit possono segnalare schemi supportati nel sorgente, come policy di row-level security mancanti o permissive e bucket di storage pubblici. L’ispezione del sorgente non stabilisce la configurazione attuale del tuo database ospitato né dimostra l’isolamento tra tenant.

4. Controlla segreti e asset del browser

Esamina i risultati sui segreti, i prefissi pubblici delle variabili d’ambiente e gli asset generati per il browser. Tieni lato server le credenziali dei provider e le service role key. Un audit del repository non può vedere un segreto di deploy assente dai file scansionati, e non ispeziona automaticamente il bundle del browser in produzione. Se una credenziale è stata esposta, revocala o ruotala; rimuovere la riga dal sorgente non basta. La guida ai segreti esposti spiega i controlli separati su repository, cronologia e browser.

5. Rivedi dipendenze e funzionalità AI

Usa il lockfile previsto per il rilascio ed esamina i risultati sulle dipendenze. Una ricerca di vulnerabilità note non può stabilire se un pacchetto sconosciuto sia affidabile. Controlla i nomi dei pacchetti appena introdotti e la loro provenienza; vedi la guida ai pacchetti allucinati.

Se la tua app chiama un LLM, verifica cosa succede con input sovradimensionati, errori del provider e output che richiedono un’operazione privilegiata. Imposta limiti di utilizzo lato server e richiedi un’autorizzazione per i tool che modificano dati. Le regole llm-app di vetkit individuano schemi supportati come output del modello eseguito come comando o come SQL e chiamate guidate dall’utente senza un limite di token in output. Non dimostrano che ogni tentativo di prompt injection fallirà né misurano i tuoi controlli di spesa in produzione.

6. Testa i percorsi di errore e il ripristino

• Simula il timeout di una dipendenza e una scrittura fallita. Verifica che l’utente riceva uno stato di errore utile e che un nuovo tentativo non duplichi l’operazione in silenzio.
• Controlla il comando di avvio in produzione, l’health check e la segnalazione degli errori. Usa guasti sintetici per confermare che l’operatore designato possa accorgersi di un rilascio difettoso senza che vengano registrate credenziali nei log.
• Prova la procedura di rollback o di ripristino in un ambiente di test. Se il rilascio modifica dati memorizzati, verifica separatamente il percorso di ripristino; riportare indietro il codice dell’applicazione potrebbe non ripristinare quei dati.

vetkit include regole statiche per schemi come chiamate in uscita senza timeout, server di sviluppo nei comandi di avvio in produzione e sincronizzazioni dello schema potenzialmente distruttive. Questi risultati possono orientare la tua revisione, ma l’audit non esegue per te questa prova dei guasti né ripristina un backup.

7. Documenta la decisione di rilascio

Tieni insieme commit, identificativo della build, perimetro dell’audit, risultati dei test e controlli di deploy. Risolvi le credenziali esposte e gli accessi non autorizzati dimostrati prima del rilascio. Per i risultati rimanenti, registra evidenze, impatto, responsabile della decisione e data di follow-up. Se un analizzatore rilevante è fallito o un comportamento critico non è mai stato testato, rendi esplicita questa lacuna invece di trattare il silenzio come un’approvazione.

Fonti e limiti

Verificato il 1º novembre 2026 sulla configurazione del Quick Scan di vetkit, sui template di audit, sul formatter dei report e sulle regole vibe-stack, llm-app, resilience, data-access e operability. Il catalogo pubblico dei controlli descrive le regole proprietarie e i linguaggi supportati; la documentazione descrive la configurazione degli audit. Disponibilità degli analizzatori, schemi supportati, limiti di scansione e perimetro selezionato influiscono sulla copertura.

I controlli manuali descritti qui sono lavoro per il tuo team, non affermazioni secondo cui vetkit esegue penetration test dal vivo, esegue la test suite della tua applicazione o certifica un rilascio. Un audit del sorgente non può verificare ogni permesso in produzione, ogni impostazione di deploy o ogni requisito di business. Mantieni questi controlli nel tuo processo di rilascio anche quando il report non contiene risultati.