Due motori, un solo audit

Fai leggere la stessa pull request a due revisori esperti e ottieni due elenchi diversi. Uno nota che l'identificatore nell'URL non viene mai confrontato con la sessione; l'altro vede che il ciclo di retry lascia aperta una connessione al database a ogni errore. Nessuno dei due sbaglia e nessuno dei due è completo. I modelli linguistici si comportano allo stesso modo, per la stessa ragione: ciò che un revisore nota dipende da ciò che ha già visto.

L'accordo è un segnale

Un singolo modello ti dice quanto è sicuro. Quel numero vale qualcosa, ma è autodichiarato: il modello corregge il proprio compito. Quando due modelli addestrati da laboratori diversi, su dati diversi, con debolezze diverse, arrivano in modo indipendente alla stessa debolezza nello stesso file, quell'accordo è una prova che viene da fuori del modello. È la cosa più vicina a un secondo parere che una revisione automatica possa avere.

Il contrario conta altrettanto. Un problema segnalato da un solo motore non è per questo sbagliato, e scartarlo significherebbe buttare via proprio i bug che un revisore singolo individua bene. Va riportato e attribuito, così sei tu a soppesarlo.

Dove un motore tace

Nella pratica i due motori divergono soprattutto sulle classi di bug che richiedono ragionamento invece di riconoscimento di schemi:

• Errori di logica: uno sconto applicato due volte, una macchina a stati che accetta un rimborso dopo un rimborso, un controllo di proprietà eseguito sull'oggetto sbagliato.
• Autorizzazione specifica del framework: middleware che protegge un gruppo di rotte ma non l'handler API montato accanto.
• Perdite di risorse e memoria: listener, timer e connessioni aperti a ogni richiesta e rilasciati solo sul percorso felice.
• Prompt injection nascosta in commenti o fixture, che si legge come testo innocuo se non la stai cercando.

Come due report diventano uno

L'unione è il punto in cui il secondo motore si ripaga oppure raddoppia il rumore. Le regole che abbiamo scelto:

• I problemi vengono abbinati su ciò che identifica un bug, non sulla formulazione: la classe CWE e il file in cui si trova.
• Una corrispondenza viene riportata una volta sola, con la più severa delle due gravità, perché la lettura sicura è quella su cui si agisce.
• Si tiene la stesura con cui uno sviluppatore può lavorare: la prova più lunga, la patch concreta, i passaggi ordinati.
• Un problema confermato passa a confidenza alta ed è etichettato con entrambi i motori.
• Un problema visto da un solo motore resta, marcato con il motore che l'ha trovato.

I due motori leggono la stessa sorgente nello stesso momento, quindi l'audit non dura il doppio; costa il doppio eseguirlo, ed è per questo che appartiene al piano Pro. Se il secondo motore non è disponibile o restituisce qualcosa di inutilizzabile, l'audit si conclude con il primo invece di fallire.

Niente di tutto ciò rende vero un report. Due motori possono concordare ed essere entrambi in errore; la prova citata sotto ogni problema è lì proprio perché tu verifichi invece di fidarti. Quello che la conferma ti dà è un ordine: quando arrivano cento problemi e hai un pomeriggio, parti da quelli che due revisori indipendenti hanno visto entrambi.