Debian discute l’AI: il rischio vero è la supply chain del tuo repo Replit

Il punto non è chi ha scritto il codice, ma cosa stai spedendo

Debian sta discutendo se limitare o vietare i contributi realizzati con l’aiuto di modelli linguistici. Il motivo dichiarato è proteggere la reputazione del progetto per stabilità e affidabilità, in un contesto dove generare codice plausibile è diventato molto più facile che verificarlo.

La notizia è raccontata in “Debian just proposed banning AI code. Here’s why it matters for open source developers & maintainers.”, pubblicato il 20 agosto 2026.

Per un founder, la domanda utile non è se il codice sia stato scritto da una persona o da un modello. È un’altra: sai dimostrare cosa è entrato nel tuo prodotto, da quali pacchetti dipende e quali script vengono eseguiti durante build, installazione e deploy?

Se hai spedito velocemente con Replit, questo è il punto cieco da controllare.

Cosa significa se il tuo codice l’ha scritto Replit

Immagina una web app costruita con Replit: autenticazione, pagamenti, pannello admin e un’integrazione AI. Il progetto funziona. Hai collegato un database, aggiunto qualche pacchetto e configurato il deploy con pochi passaggi.

Poi arriva una modifica urgente. Il tuo agente propone una libreria per gestire file, PDF, immagini o chiamate HTTP. Il pacchetto sembra noto, il nome è plausibile e l’installazione va a buon fine.

Il buco tecnico è la supply chain non verificata, in particolare una dipendenza o uno script di installazione che introduce codice indesiderato, usa permessi eccessivi o porta nel progetto una versione vulnerabile.

Il problema può comparire in più punti:

• un nome di pacchetto simile a quello corretto;
• una dipendenza transitiva che non hai aggiunto direttamente;
• uno script postinstall che esegue comandi durante l’installazione;
• una versione aggiornata senza lockfile coerente;
• un’immagine di build o un’azione CI non fissata a una versione verificata;
• un token disponibile nell’ambiente di build e leggibile da uno script;
• una libreria abbandonata che continua a ricevere aggiornamenti senza controllo.

Non significa che Replit sia il problema. Replit riduce molto il tempo tra idea e prodotto. Ma più velocemente aggiungi dipendenze, più aumenta la distanza tra “il progetto parte” e “so cosa viene eseguito nel progetto”.

Perché ora ti serve un audit: la provenienza deve diventare un verdetto

La discussione Debian mette al centro la provenienza del codice e la capacità di verificare ciò che viene accettato. Nel tuo repo, questa verifica non può fermarsi al file principale o al lockfile letto velocemente.

Un audit VibeInspect ricostruisce il percorso tecnico della supply chain e ti restituisce un verdetto sul rischio reale. Per un progetto Replit, l’analisi dovrebbe rispondere almeno a queste domande:

1. Quali dipendenze dirette e transitive vengono installate?
2. Il lockfile è presente, coerente e usato anche in produzione?
3. Esistono script preinstall, install o postinstall?
4. Quali comandi vengono eseguiti durante build, test e deploy?
5. Le dipendenze sono fissate a versioni precise o usano intervalli elastici?
6. Un pacchetto può leggere variabili d’ambiente, file locali o credenziali del progetto?
7. Ci sono token, chiavi o URL sensibili disponibili al processo di installazione?
8. Le immagini container e le action usate dalla pipeline sono versionate e verificabili?
9. Una dipendenza vulnerabile arriva in produzione anche se non è importata direttamente?
10. Esiste una separazione tra ambiente di sviluppo, preview e produzione?

Questo è il peso dell’audit: collegare manifest, lockfile, script, configurazione e pipeline. Una dipendenza non è rischiosa solo perché è vecchia. Diventa un problema quando ha accesso a dati o credenziali, quando viene aggiornata senza controllo o quando il sistema non ti permette di ricostruire con certezza cosa è stato installato.

Il Diagnostic da €499 è il piano coerente se vuoi file, righe ed evidenze sul percorso della dipendenza o dello script. Lo Snapshot da €49 fornisce uno score iniziale, ma non localizza il problema. L’audit produce un PDF con il verdetto: non sistema il codice e non è un pentest.

Cosa un linter non vede

Un linter può controllare sintassi, stile, tipi e alcuni pattern pericolosi. Non può dirti se una libreria arrivata come dipendenza transitiva esegue uno script durante l’installazione o se una versione nuova modifica il comportamento della build.

Può vedere:

import pdfParser from "pdf-parser"

Ma non sa automaticamente:

• quale pacchetto venga risolto davvero;
• quale versione sia stata installata nel deploy;
• quali dipendenze secondarie vengano scaricate;
• quali comandi vengano eseguiti dal package manager;
• quali permessi abbia il processo durante la build;
• se la stessa dipendenza sia stata verificata in preview e in produzione.

Il linter guarda soprattutto il codice che hai scritto. La supply chain vive anche fuori da quel codice: nei manifest, nei registry, nei lockfile, negli script di lifecycle, nelle immagini e nelle impostazioni della pipeline.

Anche uno scanner di vulnerabilità non basta da solo. Può trovare un identificativo noto in un database, ma non spiegare se una dipendenza viene realmente eseguita, se un pacchetto può leggere un secret o se un aggiornamento ha cambiato il comportamento del deploy.

La differenza è tra presenza e impatto. Trovare una libreria è il primo passo. Capire cosa può fare nel tuo ambiente è il lavoro che porta al verdetto.

Cosa fare questa settimana

Prima di aggiungere un altro pacchetto al progetto Replit, fai queste verifiche:

1. Blocca le versioni. Usa lockfile coerenti e assicurati che build e produzione li rispettino.
2. Controlla gli script di lifecycle. Cerca preinstall, install, postinstall, script shell e comandi eseguiti automaticamente.
3. Genera l’albero delle dipendenze. Non fermarti alle librerie che hai installato direttamente.
4. Riduci i permessi della build. Un processo di installazione non dovrebbe avere accesso indiscriminato a credenziali o dati di produzione.
5. Verifica la pipeline. Fissa immagini, action e toolchain a versioni note, invece di usare sempre l’ultima disponibile.
6. Confronta preview e produzione. Stesso lockfile, stessi comandi e differenze esplicite.
7. Definisci un criterio di aggiornamento. Ogni upgrade deve avere una motivazione, un test e una possibilità di rollback.
8. Chiedi un verdetto prima del go-live. Se non sai ricostruire cosa viene installato e cosa viene eseguito, la supply chain è ancora una supposizione.

Se hai spedito con Replit e vuoi capire se il tuo repository include dipendenze o script non verificati, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con verdetto in PDF e il sorgente verrà cancellato a fine analisi.

Scegli il Diagnostic se vuoi evidenze file/riga sulla supply chain. Il problema non è aver usato l’AI per accelerare il prodotto: è non sapere più quali pezzi lo compongono.