Copilot ti ha aiutato a fare debug: ma la regex può bloccare il server

Il debug assistito funziona solo se qualcuno insiste sulla verifica

Linus Torvalds ha raccontato una sessione di debugging difficile in cui l’AI ha svolto gran parte del lavoro ripetitivo: ha aggiunto strumentazione, analizzato i risultati e continuato a esplorare il problema anche dopo averlo giudicato impossibile. La parte interessante non è che l’agente avesse sempre ragione. È che il risultato è arrivato grazie a un ciclo di ipotesi, misurazioni e verifiche, non grazie alla prima risposta plausibile.

La fonte è Quoting Linus Torvalds, pubblicato il 22 agosto 2026.

Per chi ha spedito un prodotto costruito con GitHub Copilot, questa è una distinzione decisiva. L’assistente può aiutarti a trovare un errore, riscrivere una funzione o aggiungere test. Ma una correzione che passa sul dataset di sviluppo può ancora degradare il sistema quando l’input diventa grande o costruito ad arte.

Il buco tecnico di oggi è il catastrophic backtracking nelle espressioni regolari: una regex apparentemente innocua può consumare CPU in modo sproporzionato quando riceve una stringa sfavorevole.

Cosa significa se il tuo codice l’ha scritto Copilot

Immagina una funzione che valida email, slug, URL, codici prodotto o filtri di ricerca. Copilot può proporti rapidamente una regex completa, leggibile e corretta per i casi più comuni:

const pattern = /^(a+)+$/;
return pattern.test(input);

Su una stringa breve il risultato sembra normale. Ma alcune combinazioni di caratteri costringono il motore regex a provare molte alternative prima di concludere che l’input non corrisponde. La richiesta resta occupata, il worker consuma CPU e le richieste successive iniziano ad accumularsi.

Il problema non è soltanto la regex in sé. È il punto in cui viene usata:

• un endpoint pubblico accetta input arbitrario;
• il controllo viene eseguito prima del rate limit o della coda;
• la regex non ha un limite di tempo o di lunghezza;
• la stessa validazione viene ripetuta in middleware, servizio e database;
• un pool di worker esegue molte richieste contemporaneamente.

Nel percorso felice, l’utente inserisce un valore valido e riceve subito una risposta. Nel percorso avverso, invia una stringa abbastanza lunga da attivare il comportamento peggiore. Se l’endpoint è pubblico, non serve un accesso privilegiato: basta un input che costringa il motore a lavorare troppo.

Copilot non è il nemico. Il problema è trattare una regex generata come una decisione locale, quando in realtà può determinare il consumo di risorse dell’intero servizio.

Perché ora ti serve un audit: devi misurare il costo del caso peggiore

Un audit VibeInspect serve a trasformare il dubbio “questa validazione potrebbe essere lenta” in un verdetto sul repository che hai davvero spedito.

Nel caso del catastrophic backtracking, l’analisi deve seguire il percorso completo dell’input:

• dove nasce il valore controllato dall’utente;
• quali regex vengono applicate lungo la richiesta;
• quale motore e quale modalità di esecuzione vengono usati;
• se il pattern contiene gruppi annidati, quantificatori ambigui o alternative sovrapposte;
• se esistono limiti sulla lunghezza dell’input;
• se la validazione avviene prima di autenticazione, rate limit o coda;
• quale timeout protegge il worker;
• cosa succede quando la validazione fallisce o scade;
• se la stessa espressione viene usata anche in job asincroni o import massivi.

Il verdetto utile non è “la regex è complessa”. È: l’endpoint /api/search passa input non limitato a una regex con quantificatori annidati; il controllo avviene nel thread della richiesta; non risultano timeout o cap sulla lunghezza; con un input sfavorevole la CPU cresce mentre il worker resta occupato.

Oppure: la validazione usa un pattern lineare, limita l’input a una dimensione ragionevole e viene eseguita in un percorso protetto da timeout e rate limit. Anche questo è un verdetto: non dimostra che il sistema sia privo di ogni rischio, ma documenta perché quel percorso non presenta il problema specifico analizzato.

Questo è ciò che spesso manca dopo una sessione di debugging con Copilot. Hai una patch, magari un test verde e una spiegazione convincente. Ma non hai ancora una valutazione indipendente del comportamento nel caso peggiore.

VibeInspect parte da uno ZIP del repository, analizza codice e configurazione con specialisti AI e produce un PDF con score, verdetto ed evidenze. Non richiede un server dedicato e il sorgente viene cancellato a fine analisi.

Per un sospetto tecnico già concreto, il piano adatto è Diagnostic: servono file, righe ed evidenze per capire se il pattern regex, il punto d’ingresso e i limiti operativi possono causare un consumo anomalo di CPU.

Cosa un linter non vede

Un linter può segnalare sintassi, import inutilizzati, tipi incoerenti e alcune regole di stile. Non può però misurare quanto tempo impiega il motore regex su ogni possibile input.

Questo codice può superare i controlli statici:

EMAIL_RE = re.compile(r"^([a-zA-Z0-9._%+-]+)+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")

if EMAIL_RE.match(user_input):
    return {"valid": True}

Il linter vede una regex valida e una chiamata corretta. Non sa se user_input arriva da una richiesta pubblica, quanto può essere lunga o se il pattern può esplodere su una sequenza costruita per farlo fallire lentamente.

Nemmeno i test funzionali bastano da soli. Un test con utente@example.com dimostra il caso nominale. Non dimostra la latenza su stringhe lunghe, input quasi validi, caratteri ripetuti o richieste concorrenti.

Una scansione delle dipendenze può trovare una versione vulnerabile del motore, ma il problema può esistere anche con librerie aggiornate: è il pattern scelto, combinato con l’input e con il contesto di esecuzione, a creare il rischio.

Il punto non è vietare ogni espressione regolare. È sapere quali pattern sono lineari, quali input possono raggiungerli e quale costo massimo sei disposto a sostenere per una singola richiesta.

Cosa fare questa settimana

Se hai spedito con Copilot una funzione di validazione o ricerca, fai un controllo mirato:

1. Cerca tutte le regex usate su input provenienti da URL, form, query e file caricati.
2. Identifica i pattern con gruppi annidati, quantificatori ripetuti e alternative sovrapposte.
3. Verifica la lunghezza massima dell’input prima della validazione.
4. Prova il pattern con input validi, quasi validi e volutamente sfavorevoli.
5. Misura tempo CPU e latenza con stringhe di dimensione crescente.
6. Controlla se la regex viene eseguita nel thread principale o dentro worker condivisi.
7. Applica timeout, rate limit e circuit breaker al percorso pubblico.
8. Valuta parser o validatori strutturati quando una regex deve riconoscere grammatiche complesse.
9. Evita di ripetere la stessa validazione in più livelli senza motivo.
10. Aggiungi un test di regressione che imponga un limite massimo di esecuzione.

La domanda decisiva è semplice: quanto lavoro può imporre una singola stringa al tuo server?

“Il pattern riconosce un’email” non è un verdetto. “Il pattern ha costo controllato, l’input è limitato, il worker ha un timeout e il caso peggiore resta entro il budget di latenza” lo è.

Se vuoi un primo orientamento, carica il tuo repo su VibeInspect.ai con Snapshot. Se hai già trovato regex complesse su input pubblici o hai visto CPU e latenza crescere con la lunghezza delle stringhe, scegli Diagnostic per ottenere evidenze su file, righe e flusso.

Copilot può aiutarti a insistere quando il bug non è evidente. Ma il tuo prodotto non è pronto perché la regex funziona sul caso felice: è pronto quando sai quanto costa il caso peggiore.