CounterProof è una practice indipendente di revisione avversariale per le basi di codice moderne — il codice scritto dalle macchine, prima di tutto. Consegniamo l'unica cosa che non potete produrre internamente: una valutazione di sicurezza indipendente, firmata, graduata per livello di evidenza, costruita per il vaglio di regolatori, acquirenti, assicuratori e clienti enterprise.
Un codice scritto da un modello e revisionato dallo stesso modello non è stato revisionato da nessuno.
Parlateci prima che lo faccia la scadenza →Nessuno compra una revisione del codice. Si compra ciò che essa sblocca.
Non state leggendo questo perché vi siete svegliati desiderando una valutazione di sicurezza. Qualcosa vi sta chiedendo delle prove.
Tre di questi quattro non accettano mai la vostra parola sul vostro stesso codice — l'indipendenza è la proprietà che comprano, ed è l'unica proprietà che nessun team può fornire sul proprio lavoro. Il quarto, il regolatore, accetterà spesso la vostra autovalutazione — e poi vi chiederà conto di ogni documento che la sostiene. In entrambi i casi, le prove devono reggere. È ciò che produciamo.
Il deliverable è il punto.
Un incarico produce una CounterProof Assessment sotto un identificatore di incarico persistente (CPR-YYYY-NNN — ciò che i vostri maintainer, il vostro acquirente o i vostri commit di correzione citano). Ogni rilievo viene confermato contro il vostro codice sorgente — file e riga esatti, percorso di riproduzione, classificazione dell'impatto — oppure graduato esplicitamente come solo plausibile. Niente riempitivi, niente generato da scanner, niente su cui non possiate agire. Il fascicolo riporta anche ciò che abbiamo controllato e non trovato: un negativo registrato è qui un deliverable, non un incarico fallito.
Ogni rilievo nomina il gradino di evidenza effettivamente raggiunto — traccia nel sorgente, prova di compilazione, test o riproduzione in esecuzione — e non ne lascia mai intendere uno superiore. Ogni citazione percorso:riga viene risolta meccanicamente contro la revisione esatta che abbiamo esaminato, prima che il rapporto lasci le nostre mani. Potete verificare il nostro lavoro. È deliberato.
Quando un rilievo non regge allo scrutinio — il vostro, quello dei vostri maintainer o il nostro stesso riesame — lo ritiriamo per iscritto, con la ragione, sotto lo stesso identificatore di incarico. Lo facciamo senza che ci venga chiesto; la controparte non deve domandarlo. Il registro dei ritiri non è un'ammissione; è il meccanismo.
Esemplare — la forma di un rilievoEsemplare illustrativo, non proveniente da un incarico cliente; gli identificatori sono segnaposto. I rapporti sono emessi in inglese.
«I testimoni ormai sono gratis. L'edizione critica no.»
Il mercato ha cominciato a competere su quanti rilievi un tool sa generare — ma un rilievo è un testimone, non un verdetto. Una citazione file:riga si apre e si verifica in un minuto; un semplice «Critico» no. Nei nostri fascicoli la gravità è un output del gradino di evidenza, mai un input per il marketing. I testimoni ormai sono gratis. L'edizione critica no. Un rilievo non è un verdetto →
Quattro passi. Conoscete il perimetro prima di pagare, e il fascicolo resta a voi dopo.
Un primo incarico non deve coprire tutto ciò che spedite. Un perimetro piccolo e ben scelto — un modulo, un confine di fiducia — produce lo stesso fascicolo difendibile in una dimensione che potete valutare, e può essere il primo elemento di prova ai sensi della parte II, punto 3, che un fabbricante deposita.
La fluidità non è un segno di qualità. È la modalità di guasto.
Quando una persona scrive una riga di codice, ne dubita. Sa che stava tirando a indovinare — e quel dubbio è un dispositivo di sicurezza, perché è ciò che la spinge ad andare a provare la cosa.
Un modello scrive la stessa riga con fluidità, esattamente con la voce che usa per le righe corrette. Per chi legge, la fluidità si legge come competenza. Un ingegnere junior vi consegna qualcosa di visibilmente grezzo e voi lo controllate. Un modello vi consegna duecento righe levigate con una ragione sicura per ciascuna, e voi non lo fate.
La trappola non è che i modelli sbaglino più spesso delle persone. È che le loro risposte sbagliate arrivano con la stessa voce di quelle giuste — indistinguibili dall'esterno, perché sono indistinguibili dall'interno.
Poi lo stesso processo scrive il test che certifica il codice, e il commento che lo spiega. I tre concordano, perché tutti e tre vengono dallo stesso posto. Quella concordanza si legge come tre conferme indipendenti. È una.
«Le loro risposte sbagliate arrivano con la stessa voce di quelle giuste.»
Quindi la domanda utile non è se un modello sappia scrivere buon codice — sa farlo, con un metodo intorno. È che cosa stia davvero misurando il vostro processo di revisione quando tutto ciò che ispeziona proviene dalla stessa fonte: il codice, il test, la spiegazione e, sempre più, lo strumento che avete costruito per controllarli. Fatto bene, il risultato è buono. Fatto male, si legge esattamente uguale.
Una revisione trova ciò che il suo revisore sa trovare.
Fate girare un modello su una base di codice e un breve rapporto vi dice qualcosa di stretto: quel modello, in quell'imbracatura, quel giorno, ha fatto emergere questi. Ciò che non ha fatto emergere non è nel rapporto, e per costruzione non può esserci.
Quanto ciò conti dipende da quanto si sovrappongano i punti ciechi di revisori diversi — cosa che, per la revisione del codice, nessuno ha misurato. La ricerca sugli errori correlati tra fornitori ha trovato sovrapposizioni sostanziali su benchmark a risposta multipla e su un compito di selezione di curriculum; che ciò si trasferisca alla scoperta di vulnerabilità non è dimostrato. Ciò che mostra: fornitori diversi non sono automaticamente indipendenti tra loro.
Diverse cose possono delimitare ciò che una singola passata ha mancato: una dimostrazione, una suite di test, un fuzzer, uno specialista, difetti seminati, o un revisore diverso dal primo. Ciò che non può delimitarlo: rileggere la stessa passata con più fiducia.
Non abbiamo dimostrato che la revisione multi-revisore catturi più difetti reali — l'esperimento che avevamo progettato per verificarlo è stato ritirato prima di essere eseguito, e lo diciamo pubblicamente. Il punto più stretto è quello che difendiamo: una passata pulita di un revisore è un risultato delimitato, e leggerla come un certificato di pulizia è un'inferenza che quel risultato non regge. L'argomento completo (in inglese) →
Abbiamo messo per iscritto l'argomento lungo, compreso dove stanno i limiti del nostro stesso metodo e ciò che non abbiamo dimostrato: un'introduzione in linguaggio piano, e l'articolo completo dietro di essa, pubblicato come preprint sotto doi:10.5281/zenodo.22030516 (CC BY 4.0), in inglese. Non è sottoposto a revisione paritaria, e lo dichiara.
Potreste far girare gli stessi modelli. Non potete essere indipendenti.
Far girare più modelli di IA sul vostro stesso codice replica i nostri strumenti e perde la proprietà che conta. Il vostro team sceglie che cosa vedono i revisori, inquadra le domande e giudica le risposte — e ognuna di quelle scelte riporta le vostre assunzioni dritte dentro la revisione. Non è un difetto di disciplina; è strutturale. L'autore di un sistema non può esserne l'arbitro.
Perciò anche una revisione interna impeccabile resta la vostra parola sul vostro stesso codice. Ciò che comprano è un terzo disposto a firmare. Non siamo un organismo notificato e non certifichiamo la conformità; produciamo l'evidenza indipendente che sostiene la vostra valutazione ed è strutturata per essere riesaminata da quella di chiunque altro.
Al metodo non importa chi — o che cosa — abbia scritto il vostro codice. L'indipendenza manca al codice scritto da umani con la stessa frequenza. Il codice scritto dalle macchine rende soltanto il divario impossibile da ignorare.
Lo scoprireste comunque. Meglio sentirlo da noi.
CounterProof fa parte di un gruppo che costruisce infrastrutture di pagamento e di custodia di asset digitali. È lì che questo metodo è stato forgiato — e significa che, se costruite in quei mercati, la nostra affiliata può esservi adiacente, o essere in concorrenza con voi.
Quindi: prima di qualsiasi incarico, vi diciamo per iscritto esattamente che cosa costruisce il gruppo e dove opera. Decidete voi se è accettabile, e lo decidete prima di averci pagato qualsiasi cosa. Se non è accettabile, è una risposta legittima e preferiamo sentirla all'inizio.
Che cosa copre e non copre la nostra rivendicazione di indipendenza, con precisione: non emettiamo alcuna valutazione su codice scritto da CounterProof o da qualsiasi società del nostro gruppo. Quel confine è strutturale. È un'affermazione su di chi è il codice che esaminiamo, non la pretesa di non avere interessi commerciali in nessun luogo vicino al vostro settore. I nostri sono indicati sopra, e voi decidete se sono accettabili prima di averci pagato alcunché.
Tre persone, con nome, agli atti.
Una valutazione firmata significa che il nome di qualcuno c'è sopra. Queste sono le persone — e quale nome porta che cosa.
Siamo una practice familiare — padre, figlio e figlia — e il banco di revisione è composto da due persone. Entrambi sono fatti che un team di due diligence scopre da solo, quindi preferiamo dirli qui: un banco di due revisori accetta meno incarichi di una società, declina tutto ciò che esce dal proprio dominio e non può nascondere una passata debole dietro un marchio. Questo è lo scambio, ed è la ragione per cui il metodo è scritto e meccanizzato invece di essere portato nella testa di qualcuno.
Che cosa stiamo leggendo, e che cosa stiamo verificando.
Trovare è diventato economico; il resto del ciclo di vita no. Un percorso fase per fase (identificare, giudicare, decidere, correggere, segnalare, conservare) con ciò che il Cyber Resilience Act europeo richiede in ciascuna, e il punto in cui si colloca una revisione adversariale indipendente: nelle fasi successive alla prima.
Il Jev di TypeSafe AI è un modello di tipo nuovo: non scrive mai testo, restituisce soltanto decisioni tipizzate con probabilità. Il suo banco di prova lo valuta contro la media di altri due modelli di IA. Abbiamo aperto i casi che TypeSafe pubblica e abbiamo contato. In 8 dei 19 casi in cui entrambi i valutatori hanno risposto, i valutatori divergevano tra loro. Ciascuno dei quattro casi che TypeSafe pubblica sotto l'etichetta «tutti e tre mancano il riferimento» è un caso in cui il riferimento era esso stesso contestato. Una nota in linguaggio piano su cosa questo significhi per il modo in cui giudichiamo l'IA.
L'espressione copre ormai quattro pratiche, dal prompt critico alla casa di persone con mentalità d'attacco. Ciascuna fornisce l'inquadramento dell'attaccante; nessuna fornisce da sola un fascicolo firmato da revisori indipendenti dall'autore del vostro codice, graduato secondo la prova raggiunta da ciascun rilievo. Cosa consegniamo, cosa un secondo modello non può produrre, e cosa vi diciamo prima dell'acquisto.
Parlateci prima che lo faccia la scadenza.
Le richieste di informazioni vanno a Elenora Soons, account manager: