Debian discute l’AI: il problema vero è il verdetto sul tuo repo

La comunità Debian sta discutendo se vietare i contributi scritti o assistiti da modelli generativi, citando la reputazione del progetto per stabilità e affidabilità. La proposta e le alternative sono ancora oggetto di voto, ma il punto operativo è già chiaro: il problema non è soltanto sapere se l’AI ha scritto il codice. È sapere se quel codice merita di entrare in produzione. La fonte originale è qui.

Se hai spedito un prodotto costruito con Cursor, questa domanda riguarda direttamente il tuo repo. Non perché usare Cursor sia irresponsabile. Al contrario: l’AI ti ha probabilmente permesso di arrivare più velocemente a una prima versione utile. Il rischio nasce dopo, quando il repository sembra completo, i test passano e nessuno ha ancora emesso un verdetto tecnico sui confini reali del sistema.

Debian discute l’origine del codice, ma il tuo problema è il comportamento

Nel dibattito Debian emerge una preoccupazione comprensibile: codice generato rapidamente può sembrare plausibile senza essere davvero coerente con gli standard del progetto. La provenienza diventa quindi un segnale di attenzione.

Per il tuo prodotto, però, sapere che una funzione è stata scritta da Cursor non ti dice se un utente può leggere o modificare dati che non gli appartengono. Non ti dice se un webhook accetta eventi senza verificare la firma. Non ti dice se un endpoint usa un identificativo prevedibile e concede accesso senza controllare il proprietario della risorsa.

Prendiamo un caso concreto: hai una dashboard per team. Cursor crea una rotta come /api/projects/:id, recupera il progetto dal database e restituisce il JSON. La pagina funziona. Il test con il tuo account funziona. Il linter non segnala nulla.

Ma cosa succede se un utente autenticato cambia :id con quello di un altro progetto?

Se il server controlla soltanto che l’utente abbia una sessione valida, hai un problema di autorizzazione a livello di oggetto: un IDOR. L’autenticazione dice “sei loggato”. L’autorizzazione deve dire “puoi vedere proprio questa risorsa”. Sono due controlli diversi, e il secondo è quello che spesso manca nei repo vibe-coded.

Perché ora ti serve un audit sul repo costruito con Cursor

Un audit serve a trasformare una sensazione — “sembra pronto” — in un verdetto documentato. Il valore non è aggiungere un altro parere generico sul codice. È capire se esiste un buco tecnico concreto, quanto è esposto e quali evidenze lo dimostrano.

Nel caso di un possibile IDOR, l’analisi deve seguire il percorso completo:

• quale endpoint riceve l’identificativo della risorsa;
• quale query viene eseguita sul database;
• dove viene verificato l’utente autenticato;
• se il controllo lega davvero utente, ruolo, organizzazione e risorsa;
• quali risposte riceve un account autorizzato e quali un account estraneo;
• se lo stesso controllo esiste anche nelle varianti di lettura, modifica e cancellazione.

Questa è la differenza tra guardare una funzione e valutare un comportamento. Un’applicazione può avere codice ordinato, nomi chiari e test verdi, ma lasciare un confine di accesso incompleto tra API, database e interfaccia.

Con VibeInspect carichi lo ZIP del repo e ottieni un PDF con un verdetto. Nel piano Diagnostic, il report indica file, righe ed evidenze del problema individuato. Non è una promessa di sicurezza assoluta e non è un certificato: è un punto fermo per decidere cosa correggere prima del go-live.

Il servizio non richiede un server da installare e il sorgente viene cancellato al termine dell’analisi. Se non sai ancora quale rischio cercare, esiste Snapshot con score ma senza file o riga. Se invece hai già un sospetto tecnico — come autorizzazioni mancanti, segreti esposti o webhook non verificati — Diagnostic è il piano coerente.

Cosa un linter non vede

Un linter è utile, ma lavora su un perimetro preciso: sintassi, stile, pattern locali, tipi e alcune regole statiche. Può dirti che una variabile non viene usata o che una promessa non è gestita correttamente.

Non può emettere da solo un verdetto affidabile su una domanda come questa: “L’utente A può raggiungere il record B passando da questo endpoint, con questo ruolo, dentro questa organizzazione?”.

Per rispondere devi collegare più livelli del repo:

1. la rotta HTTP;
2. il middleware di sessione;
3. il modello dati;
4. la query effettiva;
5. le relazioni tra utente, team e risorsa;
6. le varianti della stessa operazione;
7. i test e i casi negativi.

Anche una suite di test può mancare il punto se verifica soltanto il caso felice: utente corretto, progetto corretto, risposta 200. Il test che serve è spesso quello che nessuno ha scritto: utente autenticato ma appartenente a un altro team, ruolo valido ma risorsa estranea, ID modificato manualmente, richiesta ripetuta su un endpoint secondario.

Questo non è un attacco simulato contro un sistema live. È un’analisi del repository e dei suoi percorsi applicativi, con evidenze leggibili e un risultato utilizzabile dal team.

Il verdetto che manca tra “funziona” e “può andare online”

Il dibattito Debian mette in discussione la fiducia nei contributi generati con AI. Per chi ha usato Cursor, la risposta più pratica non è nascondere l’origine del codice né bloccare ogni acceleratore. È aggiungere una verifica indipendente prima di affidare il comportamento del prodotto agli utenti.

Il tuo team dovrebbe poter rispondere a tre domande:

• Qual è il rischio tecnico più importante rimasto nel repo?
• In quale punto del codice si manifesta?
• Quale evidenza ci permette di decidere se correggerlo ora o accettarlo consapevolmente?

Senza queste risposte, “abbiamo fatto review”, “i test sono verdi” e “Cursor ha sistemato tutto” restano segnali, non un verdetto.

Cosa fare questa settimana

Scegli un flusso che tratta dati reali: progetti, documenti, ordini, fatture o profili. Poi controlla manualmente se ogni endpoint verifica non solo la sessione, ma anche il diritto ad accedere alla risorsa richiesta.

Subito dopo:

• cerca endpoint che ricevono id, projectId, userId o organizationId dal client;
• verifica se la query filtra anche per il proprietario o l’organizzazione;
• prova casi negativi nei test, non soltanto il percorso autorizzato;
• controlla che lettura, modifica e cancellazione usino lo stesso confine;
• separa i bug tecnici dalle decisioni di prodotto;
• ottieni un verdetto sul repo prima di dichiararlo pronto.

Se hai spedito con Cursor e vuoi smettere di affidarti alla sensazione che “funzioni tutto”, carica il tuo repo su VibeInspect. Per un buco tecnico come un IDOR, scegli Diagnostic: ti serve sapere dove guardare, perché è un problema e quali evidenze portare nel prossimo fix.