La revisione del codice adversariale consiste nel leggere il sorgente con la domanda di un attaccante in mente (come si potrebbe far sì che questo faccia qualcosa che non deve) anziché con la domanda di un manutentore, se cioè il codice sia corretto e ordinato. Ciò che consegniamo sotto questo nome è un fascicolo di rilievi firmato: ogni rilievo confermato graduato secondo la prova effettivamente raggiunta, ogni superficie esaminata e trovata solida annotata insieme al metodo che l’ha esaminata, prodotto da revisori indipendenti dall’autore del vostro codice, giudicato da una persona con nome e cognome che il vostro acquirente, assicuratore o cliente può citare, e ritirato per iscritto se non regge. Questa pagina dice cosa ciò aggiunge agli altri significati che l’espressione ha assunto, e quanto costa.
Cosa significa oggi l’espressione
Nella nostra lettura del mercato (una ricerca nel settembre 2026, non un censimento) quattro pratiche portano il nome. Ciascuna fa qualcosa di reale. Le prime due sono strumenti del nostro stesso banco.
Il prompt critico. Un agente scrive una modifica; un secondo, in contesto nuovo e spesso di un’altra famiglia di modelli, legge il diff attraverso lenti ostili. Questo elimina l’autovalutazione, il che conta dove si applica: misurata su otto modelli giudicanti, la preferenza per sé era forte in uno, moderata in due, vicina a zero in due e leggermente invertita in tre (preferenza per sé, arXiv:2410.21819). Come pratica fornisce l’inquadramento dell’attaccante; non fornisce da sola un fascicolo conservato, una misura di quanto fossero correlate le due letture, né una firma.
L’orchestratore a due revisori. Due famiglie di modelli esaminano la stessa modifica in modo indipendente (a volte alla cieca l’una dall’altra) e poi si criticano a vicenda, e una delle due sintetizza il risultato, spesso applicando anche la correzione. La fase cieca è giusta. Come forma, lascia il modello revisore a fare da giudice dei propri rilievi e insieme da riparatore, e non produce da sola né una verità di riferimento né una misura di correlazione.
L’insieme di piattaforma. Un prodotto di revisione fa girare più modelli dentro la propria pipeline e restituisce commenti sulla pull request con livelli di gravità; porta il nome soprattutto per vicinanza, dato che chi si descrive così pratica in larghissima parte le prime due. La pluralità di modelli è qui una scelta progettuale del fornitore; per come è venduta, la forma non espone quale modello abbia detto cosa, su quale prova, né quanto spesso concordino sbagliando. Fornisce volume e integrazione. Un filo di commenti non è un audit.
La casa di persone con mentalità d’attacco. Lettori con esperienza offensiva leggono il sorgente come farebbe un attaccante, sia come studio sia come folla. È qui che viene inventato un attacco che nessuno aveva formulato, ed è la pratica che la nostra è costruita per alimentare anziché sostituire. Come forma, non separa da sola la propria prova dal proprio verdetto, e l’indipendenza dei suoi revisori tra loro non è misurata, come quella di tutti.
Tre proprietà, una sola parola
Tre proprietà vengono impacchettate in adversariale: l’inquadramento del compito (la domanda dell’attaccante), l’indipendenza degli errori tra revisori, e l’indipendenza organizzativa di chi firma.
| Inquadramento del compito | Indipendenza degli errori | Indipendenza organizzativa | |
|---|---|---|---|
| Prompt critico | sì | non da solo, un incarico, un giudice | no |
| Orchestratore a due revisori | sì | una fase cieca, non misurata; il revisore arbitra | no |
| Insieme di piattaforma | sì | interna al fornitore, non esposta | no, uno strumento non può firmare |
| Casa umana | sì | una sola squadra | sì |
| CounterProof | sì | delimitata e registrata, non misurata: discendenze di modelli distinte, l’incarico agli atti, istanze correlate o cadute non contate | sì: firmatario con nome, indipendente dall’autore del codice; interessi di settore dichiarati per iscritto |
Un secondo modello, scelto da voi, puntato su ciò che gli mostrate, giudicato da voi, non è un avversario. È una seconda estrazione da una distribuzione dentro la quale siete già. Ne seguono tre divari, e nessuno è un problema di qualità del modello.
Divario uno: un altro fornitore non è un testimone indipendente
Due modelli di aziende diverse hanno dati di addestramento diversi, quindi l’accordo vale come conferma e il silenzio come rassicurazione; questo è il ragionamento. Uno studio su più di 350 modelli ha trovato che quando due modelli sbagliano entrambi concordano sulla stessa risposta sbagliata assai più spesso del caso (una media del 60 % su una classifica e del 42 % sull’altra), con coppie di fornitori diversi incluse per tutto il lavoro; la sua affermazione tra fornitori è un’inferenza dal modello di regressione dello studio, non un’analisi delle sole coppie tra fornitori diversi (Kim et al., ICML 2025, arXiv:2506.07962). Ha misurato banchi di prova e scrematura di curricula, non la revisione di vulnerabilità, quindi non dà a nessuno la cifra di sovrapposizione per il codice; ciò che accerta è che fornitori diversi non sono automaticamente indipendenti. Che questo debba cambiare il modo in cui leggete l’accordo di un secondo revisore sul vostro codice è una nostra inferenza. Gli studiosi dei testi hanno fatto dello stesso punto una regola cinque secoli fa: una copia di cui si dimostri che discende da un’altra copia conservata viene tolta dal computo, non perché sia errata ma perché non aggiunge testimonianza.
Il canale di correlazione che sfugge non è il fornitore. È l’incarico: prompt, strumenti, pacchetto di prove e inquadramento del ruolo correlano i revisori attraverso i fornitori, e due modelli a cui si porge lo stesso pacchetto curato condividono tutto ciò che quel pacchetto omette. Trattiamo l’incarico come parte dell’apparato e lo depositiamo agli atti della revisione. L’attaccante può usare qualunque modello sviluppa cosa questo autorizza e cosa no.
Divario due: nessuno decide quando un parere non andrebbe chiesto
Alcune affermazioni hanno un oracolo, qualcosa che risponde senza il parere di nessuno. Questo percorso viene eseguito? Eseguitelo. La specifica ammette questo valore? Leggetela. Dove esiste un oracolo, un test che è stato eseguito batte un modello che ha ragionato, e anche una persona che ha ragionato.
Se si chiede a un agente revisore se un’espressione regolare corrisponde a un percorso, produrrà un parere scorrevole sul fatto che vi corrisponda. Indirizzare invece quella domanda a un’esecuzione è una scelta ingegneristica, e nella nostra lettura la maggior parte degli strumenti di revisione non l’ha fatta, perché la categoria si compra a rilievi per pull request, e un rilievo che si rivela essere uno script di due minuti non è un rilievo. Conosciamo la difficoltà dall’interno: abbiamo costruito un controllo per imporre proprio quell’instradamento e lo abbiamo rilasciato con il suo autotest definito e mai invocato. Cosa risolve un rilievo ne è l’autopsia.
Le affermazioni senza oracolo (quanto è grave, se questo presupposto di fiducia sia accettabile, se un attaccante si darebbe la pena) sono questioni di giudizio, e nessuna quantità di output di modello converte un giudizio in un fatto.
Divario tre: nessuno ha firmato
Un’esecuzione interna di agenti (con quanti modelli si vuole, per quanto isolati i loro contesti) produce la vostra parola sul vostro codice, senza che nessuno fuori dalla vostra organizzazione risponda di una sola delle sue frasi. Per nostra esperienza è questa la proprietà che i legali di un acquirente, l’underwriter di un assicuratore cyber e il team di sicurezza di un cliente enterprise chiedono per primi, perché è quella che la vostra squadra non può fornire sul proprio lavoro.
Sotto il Cyber Resilience Act la maggior parte dei fabbricanti può autovalutarsi ed è poi tenuta a ogni documento che sta dietro: le relazioni delle prove effettuate, nella documentazione tecnica (allegato VII, punto 6), che attestano l’obbligo di prova (allegato I, parte II, punto 3), conservate dieci anni o per il periodo di assistenza se superiore (articolo 13, paragrafo 13). La segnalazione delle vulnerabilità sfruttate attivamente è iniziata l'11 settembre 2026; il regolamento si applica pienamente dall'11 dicembre 2027. Una valutazione esterna sostiene il fascicolo che mettete insieme; non è il fascicolo, e noi non siamo un organismo notificato. Le norme possono slittare, la data di notifica no tratta il calendario.
Cosa ottenete da noi
Nulla di quanto segue è un segreto. Una squadra ben condotta potrebbe adottare ognuno di questi punti. Ciò che comprate è che siano fatti tutti, messi per iscritto e firmati, come un fascicolo da consegnare a qualcuno che non era nella stanza.
- Prima l’oracolo. Un’affermazione decidibile è indirizzata all’esecuzione, alla compilazione o alla specifica prima che su di essa venga commissionato alcun parere. Il nostro strumento per i pacchetti di revisione si rifiuta di costruire un incarico senza il relativo pacchetto di prove, e l’incarico dichiara ciò che quel pacchetto non può mostrare, così che il silenzio di un’istanza su qualcosa che non ha mai ricevuto sia letto come silenzio e non come assenza.
- Le istanze sono discendenze, e l’incarico è agli atti. I revisori sono famiglie di modelli distinte; le istanze con accesso ai file costruiscono le proprie prove dal sorgente, quelle senza leggono solo ciò che l’incarico porta con sé. L’incarico, gli strumenti e il pacchetto ricevuti da ciascuna fanno parte del fascicolo. Un’istanza caduta è registrata come assente, mai come accordo; un’istanza che risulti condividere il contesto con un’altra è segnalata e non conteggiata, compresa la volta in cui una delle nostre si è rivelata avere il nostro stesso documento di rilievi nel contesto.
- I ritorni ciechi sono raccolti prima che esista un giudizio. Ciò che ciascuna istanza ha detto, alla lettera, con la sua busta (modello, imbracatura, data, file aperti) è messo per iscritto prima che chiunque li confronti.
- Un conteggio non accerta mai nulla. I rilievi non si chiudono per voto. Dove i revisori divergono su cosa fa il codice, decide il sorgente; dove un rigetto poggia su «incerto», l’affermazione passa a una coda conservata con un responsabile, una scadenza e un criterio di riapertura, ed è riesposta a una discendenza fresca. La conferma sale il gradino di prova: traccia nel sorgente, prova in compilazione, test, riproduzione in esercizio, e per ogni affermazione probabilistica un tasso con intervallo e i registri delle singole prove conservati; tutto ciò che resta sotto un gradino è solo plausibile, l’altra disposizione e non un gradino più debole. Una superficie esaminata e trovata solida è registrata con il metodo che l’ha esaminata e con il controllo che ha mostrato che quel metodo sa trovare ciò che cercava.
- Una persona con nome firma, e ritira per iscritto. Sotto un identificativo che i vostri manutentori e il vostro acquirente possono citare, anche quando il rilievo era nostro. Pubblichiamo i casi in cui i nostri stessi strumenti hanno fallito, perché una pratica che non sa mostrarvi dove ha sbagliato non ha alcuna autorità dove dice di aver ragione.
Interrogare più modelli e prendere la maggioranza è un insieme; per come è venduto, non espone nulla di tutto questo all’acquirente. Quando abbiamo cercato nel settembre 2026 non abbiamo trovato alcuna pratica che offra questo insieme come un protocollo ispezionabile da un acquirente. È un’affermazione sulla forma, non sul tasso di individuazione: di quello tratta ciò che vi diciamo prima dell’acquisto, qui sotto.
Dove si colloca nella vostra gestione delle vulnerabilità
Trovare non è dove guadagniamo il nostro onorario. Scanner, fuzzer, piattaforme di revisione e i vostri stessi ingegneri producono già candidati più in fretta di quanto chiunque riesca a giudicarli, e anche i nostri incarichi trovano cose; quello è il sottoprodotto. Ciò per cui siamo pagati sta dove il ciclo di vita si rompe: il giudizio: un candidato è indirizzato prima al suo oracolo e poi graduato per il gradino di prova raggiunto, così che la gravità segua la prova e non la sicurezza di un modello; la chiusura: il disaccordo è deciso dal sorgente e non da un voto, e «incerto» è tenuto in una coda conservata con un responsabile invece di diventare in sordina «accettato»; e la garanzia: l’esito è un fascicolo che una persona con nome esterna alla vostra organizzazione ha firmato e può ritirare, quella parte di un fascicolo tecnico, di un pacchetto di due diligence o di una richiesta assicurativa che non potete produrre sul vostro stesso lavoro. Collocateci nell’identificazione e competeremo con il vostro scanner sui volumi, una corsa che non corriamo. Collocateci dove un rilievo diventa una decisione che qualcuno dovrà poi giustificare, e il fascicolo è il prodotto. Un rilievo non è un verdetto copre la prima fase e Cosa risolve un rilievo la metà decisiva della seconda; la coda conservata è descritta sopra. Gestione delle vulnerabilità sotto il Cyber Resilience Act percorre ogni fase con il dovere del CRA corrispondente.
Cosa vi diciamo prima dell’acquisto
Questo protegge voi, perciò sta sulla pagina e non nel contratto.
- Vendiamo un fascicolo, non un tasso di individuazione. Non abbiamo dimostrato che un panel trovi più difetti reali di un solo buon revisore, e non lo sosteniamo; abbiamo misurato il nostro apparato completo contro una sola passata economica, preregistrata e valutata alla cieca, e non ha vinto nettamente su nessuno dei due bersagli: uno l’ha perso, e sull’altro ha fatto scattare la propria soglia di precisione solo cancellando i rilievi che il revisore professionale aveva giudicato reali. Abbiamo misurato il nostro metodo, e non ha ripagato il suo costo. La relazione di caso da cui lavoriamo dice che una dottrina più semplice (una revisione esterna indipendente su tutto ciò su cui agirete, le dispute decise leggendo il sorgente, nessun numero non misurato pubblicato) si accorda con le stesse evidenze; se è tutto ciò che portate via da questa pagina, portatelo via. Ciò che vendiamo è il fascicolo di averlo fatto, sotto una firma. L’indipendenza tra le nostre istanze è delimitata dalla procedura e registrata, ma non misurata per la revisione del codice; nessuno l’ha misurata. Ogni rilievo nel fascicolo ha raggiunto un gradino con un nome oppure è marcato come non averlo raggiunto.
- Dove l’autore è nel circuito. La nostra regola è che chi ha sollevato un’affermazione contestata non la giudica da solo. Il nostro banco di revisione è di due persone, il che significa meno incarichi, rifiutare lavoro fuori dal nostro dominio, e che questa regola non ha ancora alcun meccanismo che la imponga; la nostra stessa relazione di caso indica quell’assenza come la sua maggiore debolezza non corretta. In pratica un’affermazione contestata passa dal sorgente e da una discendenza fresca prima di essere chiusa, il giudizio è registrato e il firmatario è nominato, così potete vedere quali rilievi sono stati chiusi in quel modo e pesarli voi stessi.
- Nessun metodo raggiunge un difetto che nessun testimone ha sollevato. La collazione sceglie soltanto tra ciò che è stato emesso. Test, fuzzing, dimostrazioni e la lettura di uno specialista sono vie distinte verso lo stesso luogo, e un programma serio le impiega anch’esse.
- Siamo indipendenti dall’autore del vostro codice, non disinteressati in ogni settore. CounterProof fa parte di un gruppo che costruisce infrastrutture di pagamento e di custodia di attivi digitali. Se costruite su quei mercati, la nostra affiliata può esservi vicina o concorrervi. Vi diciamo per iscritto cosa costruisce il gruppo e dove opera prima di ogni incarico e prima che si muova del denaro, e non emettiamo alcuna valutazione su codice scritto da CounterProof o da una società del nostro gruppo.
L’argomentazione estesa, con i propri limiti, è il nostro documento di lavoro, una prestampa non sottoposta a revisione paritaria: research.counterproof.io (doi:10.5281/zenodo.22030516).
Domande che ci fanno
La revisione del codice adversariale è la stessa cosa di un penetration test? No. Un penetration test sollecita un sistema in esercizio; questa legge il sorgente a un commit fissato e accerta rilievi contro il codice. Entrambe ragionano dall’attaccante, rispondono a domande diverse, e un programma serio le usa entrambe.
Non posso semplicemente far girare due modelli di IA sul mio codice? Potete, e un secondo revisore potrebbe far emergere candidati che il primo non aveva. Ciò che non può produrre è l’indipendenza organizzativa: la vostra squadra sceglie cosa i revisori vedono, formula le domande e giudica le risposte, e nessuno all’esterno ha firmato.
Una piattaforma di revisione fa già girare più modelli. Non è un panel? No. Un insieme i cui modelli li sceglie il fornitore, i cui ritorni individuali non potete vedere e i cui disaccordi si risolvono dentro la pipeline è uno strumento con più parti. Un panel sono più strumenti i cui ritorni sono registrati separatamente e i cui disaccordi sono decisi dal sorgente.
La revisione del codice adversariale vale solo per il codice generato dall’IA? No. Al metodo non importa chi (o cosa) ha scritto il codice. Il codice scritto da una macchina rende soltanto il divario più difficile da ignorare, perché il volume cresce e la scorrevolezza nasconde le congetture.
In cosa differisce da uno strumento di revisione del codice basato su IA? Quegli strumenti generano rilievi, e noi usiamo strumenti di quella classe come strumenti di misura. Ciò che uno strumento non può fare è rispondere di quanto afferma o firmare.
Le inferenze segnalate come tali sopra, e qui: che l’accordo di un secondo revisore sul codice vada scontato (Kim et al. hanno misurato altri domini); che l’incarico correli i revisori; che le quattro pratiche siano la forma del mercato e che gli strumenti di revisione competano sui rilievi per pull request (nostra lettura, una ricerca, settembre 2026); che l’indipendenza organizzativa sia ciò che acquirenti, assicuratori e compratori enterprise chiedono per primo (nostra esperienza, non un sondaggio). Se qui c’è qualcosa di sbagliato, lo correggeremo per iscritto su questa pagina.