Un rilievo non è un verdetto

In circa 108 ore di tempo macchina, nell’agosto 2026, una sola campagna di volontari ha fatto passare un modello a pesi aperti su 501 progetti open source dell’ecosistema Bitcoin e ha registrato 7 958 rilievi di sicurezza potenziali, 1 280 dei quali classificati alti o critici. Di quella campagna — e del regolamento con cui collide — abbiamo scritto in Le macchine stanno leggendo il codice. Questa nota riguarda la cifra in sé.

Perché un fornitore di sicurezza ha pubblicato un benchmark che mette tre sistemi di revisione del codice basati sull’IA contro un’applicazione di test privata: uno ha trovato 68 delle 89 vulnerabilità impiantate, un altro 60, un terzo 58. I fornitori ora competono su quel rapporto — più rilievi, a costo minore. Trovare è diventato una merce in una guerra di prezzi.

Vale dunque la pena dire chiaramente che cosa sia davvero un rilievo — perché il conteggio misura la cosa sbagliata.

Un rilievo è un testimone, non un verdetto

La filologia ha risolto la questione cinque secoli fa, e la sua parola è esatta.

Quando un testo antico sopravvive in molti manoscritti copiati a mano, nessuna copia è il testo. Ciascuna è un testimone: un documento derivato che porta l’originale — più le sviste, le abitudini e la deriva ereditata del suo copista. Che tre manoscritti concordino può significare che la lezione è genuina — o che tutti e tre discendono dallo stesso esemplare difettoso. La disciplina che dirime tutto questo produce un’edizione critica: il testo per quanto stabilibile, con sotto un apparato che registra ogni testimone soppesato, ogni variante, ogni giudizio editoriale e le sue ragioni.

Un rilievo di vulnerabilità generato dall’IA è un testimone esattamente in questo senso. Non è il difetto. È il resoconto di un modello su un difetto — le proprietà reali del codice, mescolate alle abitudini del modello, alla sua discendenza di addestramento e al prompt che lo ha prodotto. Che due scanner concordino può significare che il bug è reale — o che entrambi condividono gli stessi punti ciechi e gli stessi modelli. Addestrati in gran parte sullo stesso corpus pubblico, spesso è così. La concordanza di testimoni correlati è evidenza sui testimoni, non sul codice.

E la regola più faticosamente conquistata dei filologi si trasferisce intatta: la lezione fluida è quella sospetta. I copisti spianano un passo difficile in un cliché comodo, e la versione liscia è più spesso il miglioramento del copista che le parole dell’autore. Un rapporto di vulnerabilità ha un genere fisso: titolo, classe di debolezza, gravità, una citazione, un paragrafo «un attaccante potrebbe…». Un modello linguistico produce quella forma in modo convincente — che il difetto esista o no. La lucidatura non porta informazione sulla verità. In questo genere la fluidità non è una credenziale. È la cosa da verificare.

Ecco perché il conteggio è l’unità sbagliata. Conta testimoni e li riporta come verdetti.

La gravità è il punto dove i rapporti esagerano

L’inflazione non è uniforme. Si concentra in un punto, per una ragione strutturale che merita un nome.

«Questa funzione confronta un timestamp in millisecondi con una colonna a precisione di secondi» è un’affermazione che cita qualcosa — un file, una riga, un commit. Si può aprire e dirimere in un minuto. «Critico» non cita nulla. Non esiste una riga di codice su cui sia scritto Critico. La gravità è un giudizio su raggiungibilità, sfruttabilità e raggio d’impatto — e proprio perché non ha ancoraggio nel sorgente, è esattamente il punto in cui un generatore fluido deriva verso l’alto senza freni. La lettura drammatica è la più facile; ogni incentivo della catena di segnalazione premia la cifra più grande; e nulla nell’artefatto resiste.

Quindi, quando una campagna riporta 1 280 rilievi «alti o critici», la lettura onesta è: 1 280 rilievi che un generatore ha etichettato così. L’etichetta è il campo meno verificabile del documento — ed è quella che regge il titolo.

Sono sfruttabili? Nessuno lo ha ancora detto

Tra un rilievo e un difetto c’è un passaggio che il conteggio salta: la valutazione — decidere quali rilievi sono reali, quali raggiungibili, quali contano. Quel passaggio è ancora umano, e non scala con la generazione.

La misura pubblica più chiara di cosa accade quando lo si salta viene da curl. Il suo team di sicurezza volontario di sette persone ha visto la quota di segnalazioni di vulnerabilità confermate scendere da oltre il 15 % a meno del 5 % con l’arrivo degli invii assistiti dall’IA — mentre ogni segnalazione infondata continuava a costare ore di confutazione. Una è arrivata completa di sessioni GDB e dump dei registri per un exploit HTTP/3 in una funzione che in curl non esiste. Il suo maintainer ha descritto il carico di triage come «equivalente a un DDoS» («tantamount to a DDoS»), e alla fine il progetto ha chiuso il proprio programma di bug bounty — dichiarando di non aver visto una sola segnalazione di sicurezza valida prodotta con l’aiuto dell’IA.

Leggete quella cifra nel verso giusto. Non prova che i rilievi dell’IA siano senza valore — prova che la fluidità di un rilievo e la sua validità sono indipendenti, e che togliendo il passaggio di valutazione il rapporto segnale-rumore collassa. Le segnalazioni sono diventate più numerose e più sicure di sé; la frazione che sopravviveva alla verifica è scesa.

La piena è un problema di sicurezza, non una seccatura

È tentante archiviare «troppi rilievi» tra i fastidi. Sarebbe un errore. Quando la generazione supera la valutazione, il rilievo vero non scompare — resta sepolto in coda dietro duecento plausibili, e una coda che nessuno riesce a smaltire è una coda che nasconde le cose. La parola di curl — DDoS — è il registro giusto. Un team che annega in segnalazioni sicure di sé non è più sicuro di un team senza segnalazioni; è un team la cui attenzione si è esaurita su testimoni mai sottoposti a controinterrogatorio.

Tenere separati i due allarmi

Qui si confondono due affermazioni, e separarle è l’intera disciplina.

In aggregato, il pericolo è reale. Esistono genuinamente enormi quantità di difetti non corretti nel codice vecchio, e un cercatore economico e instancabile ne farà emergere alcuni. Liquidare l’intera categoria come montatura è sbagliato.

Per singolo rilievo, la criticità dichiarata è sistematicamente sovrastimata — verso l’alto, perché l’unico campo che nessuno può verificare è quello che tutti gonfiano. Trattare ogni allarme come un verdetto è sbagliato anch’esso — nella direzione opposta.

L’errore è rispondere alla domanda dell’una con l’allarme dell’altra. «Da qualche parte in questo ecosistema esistono molti bug veri» non rende questo rilievo sulla vostra riga sfruttabile. E «la maggior parte di questi specifici allarmi è rumore» non significa che la vostra base di codice sia pulita.

Che cosa vede attraverso

L’editore medievale non poteva decontaminare l’intera tradizione. Ciò che poteva fare: legare condizioni a ogni lezione e rendere esplicite le condizioni. La stessa mossa funziona qui. Quando vi porgono un rilievo, chiedete:

1. Quale gradino di evidenza raggiunge davvero? Tracciato nel sorgente, compilato, testato o riprodotto in esecuzione — non sono la stessa affermazione. Un rilievo non dovrebbe mai indossare una certezza superiore al lavoro che lo sostiene.
2. È raggiungibile nella vostra build, o raggiungibile in linea di principio? Una gravità senza argomento di raggiungibilità è uno stato d’animo, non una misura.
3. È stato valutato, o mediato? Che tre strumenti concordino non fa tre conferme se gli strumenti condividono un punto cieco. Un rilievo di minoranza merita una verifica-oracolo economica — eseguire il test, leggere la specifica, percorrere il cammino — non una votazione.
4. È già corretto, o già noto? Un rilievo che i maintainer hanno chiuso il mese scorso è un testimone della storia, non del vostro rischio.

Niente di tutto ciò è esotico. È ciò che un’edizione critica fa con una pila di manoscritti: collazionare i testimoni, valutarli contro un’evidenza più forte di un’ennesima opinione, e conservare l’apparato — i giudizi, l’incertezza, le lezioni considerate e respinte.

Non tutti i rilievi morti sono morti della stessa morte

La maggior parte dei rilievi non sopravvive. È normale, ed è il punto — ma come un rilievo è morto è informazione, e una revisione che li rovescia tutti in un unico secchio marcato «scartati» ha buttato via quell’informazione.

La filologia distingue i casi, e la distinzione è abbastanza antica da avere un nome. Un manoscritto di cui si dimostra che è stato copiato da un altro manoscritto conservato viene espunto dal conteggio per intero — eliminatio codicum descriptorum — non perché sia sbagliato, ma perché non aggiunge alcuna testimonianza indipendente. La sua concordanza non è mai stata evidenza.

Tre morti, e non significano la stessa cosa:

• Ridondante. Più strumenti hanno prodotto lo stesso rilievo. Dove quegli strumenti non sono indipendenti — e condividendo dati di addestramento e modelli spesso non lo sono — la loro concordanza è una lezione in tre copie anziché tre conferme, e contarla tre volte è il modo in cui si fabbrica la falsa fiducia. Espungete i duplicati, ma registrate l’assunzione di indipendenza invece di darla per scontata: la concordanza di revisori genuinamente indipendenti non è niente.
• Falso. Il rilievo dice che il codice fa qualcosa che il codice non fa. Si dirime aprendo il file. È l’unica categoria che la maggior parte ha in mente quando dice «falso positivo».
• Vero, ma su un testo che non esiste più. Il rilievo è accurato — su una revisione da allora corretta. Il testimone è onesto; il codice si è mosso sotto di lui. Un difetto chiuso a una revisione upstream fissata non è un falso positivo per quella revisione e non dovrebbe essere registrato come tale. Ciò vale solo se il rilievo dice quale revisione ha letto: un rapporto che non sa nominare la propria revisione non è un testimone onesto di un testo superato — è un’affermazione scaduta sul testo attuale.

Solo la seconda è un errore della lezione in sé; il caso non fissato della terza è un errore della catena che l’ha riportata. Un fascicolo che dice quale morte è morta ciascun rilievo può essere verificato da qualcuno che non era presente. Un rapporto numerico — «abbiamo triato duecento rilievi fino a sei» — non può, e non è nemmeno un segnale di qualità: una catena pigra raggiunge quel rapporto generando scarti e buttandoli. L’eliminazione non è il prodotto. L’evidenza dietro i sopravvissuti lo è.

A che cosa serve un’edizione

La ragione per costruire un’edizione anziché un elenco è che qualcuno deve arrivare a un verdetto, e non sarà il revisore.

Un maintainer decide se applicare la patch. Un fabbricante decide che cosa entra nel fascicolo tecnico. Il team di sicurezza di un cliente enterprise decide se firmare. Ciascuno di loro raggiunge un verdetto, e a ciascuno sarà chiesto più tardi — da qualcuno meno amichevole, con più tempo — di mostrare come lo ha raggiunto. Ciò di cui hanno bisogno da un revisore non è un’opinione in più da soppesare. È l’evidenza, disposta in modo che la loro stessa decisione sopravviva alla domanda.

In Europa questo sta passando da buona pratica a requisito di legge. Il Cyber Resilience Act esige che i fabbricanti «effettu[i]no prove e riesami efficaci e periodici della sicurezza del prodotto con elementi digitali» (allegato I, parte II, punto 3)), e la documentazione tecnica deve contenere «le relazioni delle prove effettuate per verificare la conformità …» (allegato VII, punto 6)) — conservate per almeno dieci anni dall’immissione sul mercato, o per il periodo di assistenza se superiore (articolo 13, paragrafo 13). La notifica ai sensi dell’articolo 14 delle vulnerabilità attivamente sfruttate e degli incidenti gravi inizia l'11 settembre 2026; il regolamento si applica integralmente dall'11 dicembre 2027.

Leggete che cosa viene chiesto davvero. Non una scansione pulita, e non una cifra bassa. Una relazione delle prove effettuate, conservata un decennio, leggibile da qualcuno che non era nella stanza. Un elenco di rilievi con gravità sicure di sé, senza apparato sotto e senza registro di che cosa è stato respinto e perché, non sopravvive a quella lettura. Un’edizione sì — perché ogni affermazione nomina l’evidenza che la sostiene, ogni lezione eliminata è registrata con la sua ragione, e ogni correzione avviene per iscritto.

Gli obblighi gravano sul fabbricante, non su un revisore esterno. Una revisione esterna del tipo qui descritto sostiene la documentazione tecnica che voi componete; non è il fascicolo completo, e non sostituisce la valutazione della conformità di un organismo notificato dove il regolamento ne richiede una. Ma è la parte di quel fascicolo più difficile da produrre sul proprio stesso lavoro — perché l’unica proprietà che deve portare è che l’ha scritta qualcuno diverso da voi.

Perché ci riguarda

In CounterProof pratichiamo la revisione avversariale di codice scritto dalle macchine, e queste domande per noi non sono teoriche — sono le nostre regole operative. I rilievi vengono valutati anziché mediati; ogni affermazione nomina il gradino di evidenza raggiunto, e nessuno superiore; un rilievo già corretto upstream viene ritirato anziché contato; e quando una nostra affermazione non sopravvive, la ritrattiamo per iscritto, pubblicamente (in inglese). Non vendiamo un numero di rilievi, e vi consiglieremmo di non comprare su quella base. Gli scanner sono copisti, e lo scriptorium ormai lavora giorno e notte per pochi spiccioli. La cosa scarsa non è mai stata la copia. È l’edizione.

L’argomento più lungo — compresa la forma condizionale di ogni affermazione qui sopra e i limiti del nostro stesso metodo — è nel nostro working paper sulla collazione e la provenienza del testo generato dalle macchine, leggibile per intero qui (in inglese). È una bozza di preprint, non sottoposta a revisione paritaria, e lo dichiara.

Le cifre qui sopra hanno una fonte: la campagna sui 501 progetti è documentata nella nostra nota precedente; i rapporti del benchmark dei tre sistemi provengono dal post pubblicato dal fornitore; il tasso di conferma di curl, la segnalazione della funzione fantasma e la chiusura del suo programma di bounty sono riportati da The New Stack, BleepingComputer e The Register. Le citazioni del Cyber Resilience Act rinviano al regolamento (UE) 2024/2847 nella versione linguistica italiana ufficiale — le stesse disposizioni che portiamo sulla nostra homepage. Dove un’affermazione è nostra inferenza anziché un rilievo citato — che la gravità si gonfia verso l’alto, che fluidità e validità sono indipendenti — lo abbiamo detto. Questa pagina è una traduzione dell’originale inglese; in caso di divergenza prevale l’originale. Se qualcosa qui è errato, lo correggeremo per iscritto su questa pagina.