Exploit Validation: l'evidenza batte la stima, ma di chi è il cloud che la calcola?

Il 23 marzo 2026 Qualys — il vendor che di fatto ha inventato lo scanner di vulnerabilità moderno — ha rilasciato Agent Val, un agente AI che prova a sfruttare davvero una vulnerabilità per capire se è raggiungibile. Nel comunicato una frase fa tutto il lavoro. Il CISO scelto per il lancio la descrive come un passaggio "da una postura reattiva basata su punteggi CVSS teorici a un modello disciplinato, basato su evidenza."

È un'ammissione notevole, da parte dell'azienda il cui business è stato costruito proprio su quei punteggi. Per due decenni l'intera industria del vulnerability management ha ordinato il rischio per stima — severità CVSS, peso del threat intel, probabilità EPSS — e il leader di mercato ha appena detto ai suoi clienti che la stima non è mai stata abbastanza. Era sempre stata un'ipotesi travestita da numero.

Hanno ragione. La domanda interessante è cosa viene dopo l'ammissione, perché "basato su evidenza" non è una cosa sola. Esiste una gerarchia della prova, e dove si colloca un prodotto — e soprattutto dove viene calcolata quella prova — è tutto il gioco.

Il problema della stima: dare un voto a 35.000 cose che quasi mai accadono

Partiamo dal perché la prioritizzazione per stima era condannata in partenza. Nel primo semestre 2026 sono stati pubblicati 35.364 CVE. Ognuno riceve una severità CVSS. Una fetta enorme supera 7.0: ecco come ci si ritrova un backlog di remediation da decine di migliaia di finding "high" e "critical" che nessun team al mondo può smaltire.

Ora sovrapponi la realtà. Di quei 35.364 CVE del primo semestre, solo 85 — lo 0,24% — sono finora comparsi nel catalogo Known Exploited Vulnerabilities della CISA. Il numero crescerà con l'invecchiamento della coorte, perché KEV registra lo sfruttamento con mesi di ritardo, ma la forma è stabile negli anni: lo State of Exploitation di VulnCheck ha rilevato che circa l'1% dei CVE del 2025 è stato sfruttato in the wild entro fine anno. Ordinare per punteggio significa spendere il 99% dello sforzo su cose che non verranno mai toccate, mentre l'1% che conta è sepolto sotto lo stesso identico rosso.

E quell'1% corre. VulnCheck ha registrato che il 28,96% dei KEV del 2025 è stato sfruttato il giorno stesso della pubblicazione del CVE o prima — in crescita dal 23,6% del 2024. Quando una scansione trimestrale si ripete e un ticket viene triageato, la finestra che contava si è già chiusa. È lo stesso schema che i nostri articoli continuano a incontrare dall'altra direzione: CitrixBleed 3 patchato a marzo è diventato un'emergenza a giugno; SharePoint CVE-2026-45659 patchato a maggio e sfruttato a luglio. Uno scanner che riporta "patchato" sta rispondendo a una domanda diversa da "raggiungibile".

Quindi Qualys fa bene a muoversi. Il problema è che "abbiamo trovato un bug, ecco il suo punteggio" non è mai stato azionabile. "Abbiamo dimostrato che questo specifico asset può essere compromesso, e questi controlli lo hanno fermato" lo è. È la direzione giusta. Ora siamo precisi su quanto lontano arriva davvero.

Tre livelli di exploit validation — e solo uno è prova

Ogni prodotto che tocca questo terreno sta su uno di tre gradini. Il marketing li confonde, quindi fissiamoli:

• Livello 1 — Stima. Un punteggio di severità o probabilità legato a un CVE. CVSS, EPSS, un risk score proprietario come TruRisk. Ti dice cosa potrebbe essere sfruttabile su una popolazione. È una previsione, calcolata da metadati, mai dal tuo ambiente. Lo fa ogni scanner.
• Livello 2 — Validazione "safe". Un agente verifica se un percorso di exploit noto, preso da una libreria curata, è aperto contro il tuo asset — usando il contesto di business per capire se un controllo lo blocca. Agent Val di Qualys, alimentato da TruConfirm, copre oltre 1.600 CVE così, e dichiara un taglio del rumore di remediation superiore al 90%. Pentera e Horizon3 hanno inventato la categoria; i grandi vendor di scanner ora la stanno rincorrendo. È progresso reale. Risponde a "questo percorso è aperto adesso?" per i percorsi che qualcuno ha già catalogato.
• Livello 3 — Prova eseguita. Una catena di exploit nuova viene generata per il target specifico, eseguita contro di esso, e l'esito è catturato come artefatto firmato e a prova di manomissione di ciò che è realmente accaduto. Non "questo CVE è probabilmente raggiungibile". Non "un payload noto per questo CVE non è bloccato". Il record letterale di una compromissione avvenuta, ripetibile e verificabile.

Il Livello 2 è dove il mercato si sta spostando rumorosamente, e merita credito per aver lasciato il Livello 1 alle spalle. Ma porta con sé due assunzioni che pesano enormemente a seconda di chi sei.

Cosa assume in silenzio la validazione "safe"

La prima assunzione è una libreria. Agent Val valida contro un insieme curato di CVE noti — molto ampio, ma finito e rivolto all'indietro. Funziona benissimo per l'ondata di n-day. Non fa nulla per la catena che nessuno ha ancora catalogato: la composizione inedita di due primitive banali, il difetto logico, la misconfigurazione che diventa critica solo a tre salti di distanza nella tua rete specifica.

Lo abbiamo visto accadere esattamente con l'HTTP/2 Bomb (CVE-2026-49975), dove un agente AI ha concatenato due primitive vecchie di dieci anni che nessun umano e nessuna libreria di exploit aveva mai composto. Un motore di validazione ancorato a una lista di CVE non può validare un attacco che un CVE ancora non ce l'ha. La generazione sì; una libreria no.

"Ma la nostra libreria copre 1.600 CVE." — E l'attaccante che ti compromette il prossimo trimestre sta scrivendo il 1.601° contro il tuo ambiente in particolare, a mano o con un modello, stanotte. Un red team che sa solo rieseguire un catalogo ti sta testando contro l'attaccante dell'anno scorso.

La seconda assunzione è quella che nessuno mette nella slide: dove viene calcolata la prova. Agent Val valida "nell'ambiente live", ma è orchestrato dalla piattaforma cloud di Qualys. Il tuo inventario asset, la topologia, la postura dei controlli e la telemetria di validazione confluiscono tutti in un SaaS multi-tenant per essere elaborati. Per la maggior parte delle aziende è un compromesso accettabile. Per un ministero della difesa, un operatore della rete elettrica nazionale, un servizio di intelligence, o chiunque gestisca un segmento OT air-gapped, è un no netto — e nessuna quantità di "basato su evidenza" lo sistema.

L'evidenza è sovrana solo se non lascia il tuo edificio

Ecco l'angolo scomodo della narrazione evidence-based. L'atto stesso di raccogliere l'evidenza è un'operazione di intelligence contro la tua stessa rete. Stai mappando ogni asset raggiungibile, ogni percorso aperto, ogni lacuna nei controlli — esattamente il documento per cui un avversario ucciderebbe. Se quella mappa è calcolata nel cloud di qualcun altro, dal modello di qualcun altro, la "prova" ottenuta è costata l'esportazione della tua superficie d'attacco verso l'infrastruttura e l'LLM di terzi.

Per una banca sotto DORA, un ospedale sotto NIS2 o un operatore di infrastruttura critica, quel compromesso fallisce il threat model prima ancora di iniziare. È anche il motivo per cui il gap dei CVE noti continua a comparire come primo rilievo d'audit: le organizzazioni più esposte sono spesso proprio quelle che non possono mandare la loro topologia a un validatore cloud, e quindi ripiegano sul pentest manuale annuale e sul backlog basato su stime. Il Livello 2 in cloud, semplicemente, non è disponibile per loro.

	Livello 1 — Stima	Livello 2 — Validazione safe	Livello 3 — Prova eseguita
Risponde a	Cosa potrebbe essere sfruttabile	Un percorso noto è aperto ora?	Questo asset è stato davvero compromesso?
Copertura	Ogni CVE, per metadati	Libreria curata (finita, n-day)	Generata per target, incl. catene inedite
Dove gira	Ovunque	Orchestrazione cloud del vendor	On-prem, air-gap possibile
Artefatto	Un punteggio	Un esito di validazione	Record firmato, a prova di manomissione
Sovrana?	N/A	No — la topologia lascia l'edificio	Sì — nulla lascia l'appliance

La riga che decide tutto per un operatore regolamentato è la terza. L'evidenza batte la stima — ma solo se generare l'evidenza non diventa a sua volta la violazione.

Prova che puoi tenere in mano, generata dove vivono i dati

È il divario per cui Zero Hunt è stato costruito. Il motore fa girare uno swarm coordinato di 10 agenti AI — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report sotto un AI Controller — che non riesegue un catalogo. Scrive un exploit generativo per il target specifico con un LLM locale, unico per quell'ambiente, poi lo esegue dentro un container Docker effimero irrobustito con gVisor, così l'attacco non tocca mai l'host. Ogni nuova skill offensiva è validata a ritroso nell'AI Gym contro i corpus Vulhub, NYU CTF Bench e Cybench prima di poter avvicinarsi a un asset di produzione. Questo è il Livello 3: la catena inedita che una libreria da 1.600 CVE strutturalmente non può raggiungere, eseguita e catturata.

E gira dove vivono i dati. Zero Hunt è un'appliance 100% on-premise — nessun callback verso il cloud, nessuna telemetria, nessuna API LLM esterna, air-gap supportato. La prova di compromissione è scritta in una catena di evidenze firmata crittograficamente e a prova di manomissione, con chain-of-custody, così un auditor o un tribunale può verificare cosa è successo senza fidarsi della parola di nessuno, e senza che la tua superficie d'attacco lasci mai l'edificio per produrla. L'industria della stima quest'anno ha ammesso che un punteggio non è una prova. La prossima ammissione — quella che l'architettura cloud non può fare — è che una prova che hai dovuto esportare non è mai stata del tutto tua.

Se vuoi vedere la prova eseguita generata dentro il tuo perimetro, contattaci o scopri com'è costruito il motore.