I pin verdi mentono: perché una dashboard tutta verde non certifica il tuo repository

Un'interfaccia tutta verde non dimostra che il tuo codice sia sano

Un progetto pubblicato su dev.to di Alex R. racconta una lezione tecnica semplice ma scomoda: un indicatore verde non significa che tutto funzioni davvero. L'autore ha costruito un gioco investigativo basato su telemetria reale per dimostrare che un "pin verde" può nascondere uno stato completamente diverso da quello che mostra. La sua frase chiave è netta: la UI verde è una recita finché i numeri non arrivano da uno stato realmente osservato.

Se hai mai guardato la dashboard del tuo progetto e ti sei sentito tranquillo perché tutto era verde, quella frase dovrebbe farti fermare un attimo. Il colore di un pannello di controllo è un'interpretazione, non una misura. E tra l'interpretazione e la realtà del tuo repository può esserci una distanza che nessuno ha ancora quantificato.

Il punto non è la grafica. È che la maggior parte di chi pubblica un prodotto oggi si fida di segnali indiretti — build passata, deploy riuscito, nessun errore rosso in console — e li scambia per un verdetto sulla sicurezza e sulla correttezza del codice. Non lo sono.

Cosa significa se il tuo codice l'ha scritto Lovable

Supponiamo che tu abbia costruito la tua applicazione con Lovable. Hai collegato un backend Supabase, hai definito le tabelle, hai spinto tutto in produzione. L'app funziona: gli utenti si registrano, i dati si salvano, la home è verde. Tutto sembra a posto.

Il problema è che "funziona" e "è protetto" sono due stati diversi, esattamente come il pin verde e lo stato reale del sistema. Il caso più frequente in questo tipo di stack riguarda le policy RLS — Row Level Security. Lovable genera schema e query velocemente, ma la logica di autorizzazione a livello di riga è spesso il punto in cui la generazione automatica lascia buchi.

Uno scenario tipico: la tabella orders esiste, la query funziona, l'app mostra i dati giusti all'utente giusto durante i tuoi test. Ma se RLS è disattivato o se una policy è scritta in modo troppo permissivo (using (true) è più comune di quanto pensi), qualsiasi utente autenticato può leggere le righe di chiunque altro chiamando direttamente l'endpoint. La dashboard resta verde. Il deploy resta riuscito. E intanto i dati dei tuoi clienti sono esposti a chi conosce due nozioni di API.

Questo è il vero senso della lezione sui pin verdi: lo stato che vedi non è lo stato che hai. Nessun indicatore visivo ti dirà mai che una policy RLS è troppo aperta, perché dal punto di vista dell'interfaccia va tutto benissimo.

Perché ora ti serve un audit

Un audit serve proprio a colmare quella distanza tra ciò che credi di avere e ciò che hai davvero. Non è un dettaglio filosofico: è la differenza tra un verdetto misurato e una sensazione.

Quando sviluppi con uno strumento AI, il codice arriva più in fretta di quanto tu riesca a capirlo riga per riga. Non è una colpa — è il senso stesso di quegli strumenti. Ma la velocità di generazione crea un debito di comprensione: hai in produzione decine di file che non hai mai letto con attenzione, e non sai in che stato siano davvero le tue autorizzazioni.

Un audit come VibeInspect risponde a una domanda precisa: qual è lo stato reale del mio repository, al di là dei segnali verdi? Carichi lo ZIP del progetto, alcuni specialisti AI analizzano il codice e ricevi un PDF con un verdetto. Nessun server coinvolto, e il codice sorgente viene cancellato al termine dell'analisi.

Vale la pena essere chiari su cosa non è. VibeInspect non è un penetration test, non sostituisce un revisore umano e non promette sicurezza assoluta. Non corregge il codice al posto tuo. Ti dà una cosa sola, ma che oggi ti manca: una valutazione misurata invece di un'impressione. Esattamente come il progetto sui pin verdi premia la fiducia calibrata e punisce la sicurezza gonfiata, un audit serio ti dice dove sei davvero, non dove speri di essere.

Se la tua domanda è "il mio RLS è configurato correttamente su tutte le tabelle sensibili?", quella è una domanda tecnica specifica. E merita evidenze, non un colore.

Cosa un linter non vede

Qui è facile fraintendere. Molti pensano: "ho ESLint attivo, il mio codice è controllato". Ma un linter e un audit guardano cose diverse.

Un linter analizza la forma del codice: variabili non usate, stile, pattern potenzialmente rischiosi a livello sintattico. È utile e dovresti tenerlo. Ma un linter non capisce la tua logica di autorizzazione. Non sa se la policy RLS sulla tabella orders corrisponde davvero all'intenzione di business "ogni utente vede solo i propri ordini". Non sa che un using (true) in una policy è tecnicamente valido ma disastroso sul piano della sicurezza.

Un linter non correla lo schema del database con gli endpoint esposti. Non ti dice che un IDOR è possibile perché l'ID viene passato in chiaro e nessuna policy filtra per proprietario. Non vede il contesto: vede la sintassi. Il tuo codice può superare ogni regola di linting ed essere comunque completamente aperto in lettura.

Questo è il punto cieco. Il verde del linter, come il pin verde della dashboard, è un segnale su una dimensione ristretta del problema. Ti dice che il codice è formattato bene. Non ti dice che è sicuro. Confondere i due livelli è esattamente l'errore che il progetto sulla telemetria racconta: scambiare un segnale comodo per un verdetto completo.

Cosa fare questa settimana

Non serve riscrivere tutto. Serve trasformare un'impressione in una misura, partendo da un'azione concreta.

Questa settimana, fai tre cose. Primo: apri la console del tuo Supabase (o del tuo backend) ed elenca tutte le tabelle che contengono dati personali o sensibili. Secondo: per ognuna, verifica che RLS sia attivo e leggi la policy — se trovi un using (true) su una tabella con dati utente, hai già un problema da chiudere. Terzo: prova a chiamare un endpoint con l'account di un utente per leggere i dati di un altro. Se ci riesci, il tuo pin era verde per niente.

Se questa verifica manuale ti conferma che non sai con certezza in che stato siano le tue autorizzazioni, è il momento di un verdetto misurato. Con il piano Diagnostic di VibeInspect ricevi file, riga ed evidenze sui punti critici del tuo repository, così sai esattamente dove intervenire invece di fidarti di un colore.

Il codice generato con l'AI non è il problema. Il problema è pubblicarlo senza un verdetto. Rendi misurabile ciò che oggi è solo verde.