# Un rilievo non è un verdetto

> L'IA può ormai generare migliaia di rilievi di vulnerabilità in un pomeriggio. Un rilievo è un testimone, non un verdetto — e l'unico campo che nessuno può verificare è quello che tutti gonfiano. Ecco come leggere la piena senza annegarci.

Source: https://counterproof.io/it/notes/un-rilievo-non-e-un-verdetto/ · Published 25 August 2026 · CounterProof è una practice di Clavestra Capital Limited (Malta, C 113987).


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*](https://counterproof.io/it/notes/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](https://counterproof.io/notes/we-withdrew-our-own-number/) (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](https://research.counterproof.io/)
(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.*