L'AI ha cambiato la scoperta delle vulnerabilità: ma c'è un gap OT da non ignorare

La scoperta automatica di vulnerabilità ha appena fatto un salto generazionale. I modelli AI di ultima generazione non si limitano più a suggerire dove guardare: trovano falle sconosciute in autonomia, riproducono exploit e lo fanno su una scala che fino a ieri richiedeva interi team di ricercatori. È una buona notizia per chi difende. Ma c'è un divario che il settore industriale non può permettersi di ignorare.

Cosa è cambiato davvero

Gli annunci recenti parlano chiaro. I nuovi sistemi raggiungono tassi di successo intorno all'83% su benchmark di riproduzione delle vulnerabilità, scoprono zero-day in autonomia su sistemi operativi e browser diffusi, e in un caso hanno individuato un bug rimasto nascosto in OpenBSD per 27 anni.

Il punto non è il singolo numero, ma il cambio di paradigma: la scoperta di vulnerabilità sta diventando industrializzata. Quando una capacità del genere si scala, scala per tutti.

Il gap: questi strumenti parlano IT, non OT

Le iniziative che oggi mettono in campo questi modelli si concentrano su sistemi operativi, browser, piattaforme cloud e software open source. Tutti ambiti dove il patching è una pratica consolidata e la remediation può essere rapida.

Il mondo OT/ICS funziona secondo regole diverse:

Dimensione	IT	OT/ICS
Patching	aggiornamenti standard	richiede fermi pianificati, spesso impraticabile
Conseguenze	solo digitali	impatti sul mondo fisico
Hardware	x86 con OS standard	PLC con protocolli proprietari e legacy
Protocolli	standard moderni	Modbus, DNP3, EtherNet/IP, IEC 61850
Accesso	solo software	spesso richiede interazione fisica con l'hardware

Valutare una vulnerabilità OT non significa solo capire il software: significa capire come l'hardware interagisce con il mondo fisico. È competenza di dominio che gli strumenti pensati per l'IT non hanno.

Il rischio dual-use

Qualsiasi tecnologia che industrializza la scoperta di vulnerabilità avvantaggia sia chi difende sia chi attacca. Chi è già attrezzato per agire sui risultati ottiene un vantaggio asimmetrico.

Per le infrastrutture critiche lo squilibrio è concreto: se gli attaccanti acquisiscono capacità di discovery potenziate dall'AI mentre i difensori OT non dispongono di strumenti tarati sul proprio ambiente, il rischio cresce proprio dove le conseguenze sono più gravi.

Perché la remediation in OT è un altro mestiere

Una vulnerabilità trovata in un sistema SCADA o in un sistema strumentato di sicurezza non si chiude con un aggiornamento. Bisogna ragionare su:

• il raggio d'azione di un eventuale sfruttamento (la blast radius)
• quali controlli compensativi esistono già in campo
• come intervenire senza fermare la produzione né compromettere la sicurezza funzionale

Sono considerazioni assenti dai flussi di lavoro IT standard, ma decisive in ambiente industriale.

Cosa serve adesso

L'OT e la sicurezza delle infrastrutture critiche non possono essere un ripensamento rispetto a dove sta andando questa tecnologia.

La direzione è chiara: portare la competenza OT dentro la progettazione di questi strumenti, non aggiungerla dopo. I difensori industriali hanno bisogno di capacità calibrate sugli ambienti specifici e poco indulgenti in cui operano, dove il comportamento inatteso non è accettabile e dove il mondo fisico è sempre a valle di quello digitale.

Il punto di vista MON5

È esattamente il terreno su cui lavoriamo. La visibilità sugli asset OT, la correlazione delle vulnerabilità con il contesto reale dell'impianto e il monitoraggio delle anomalie senza fermare la produzione sono i presupposti per trasformare la potenza dell'AI in difesa concreta, anche per chi gestisce reti industriali.

L'AI ha cambiato per sempre la scoperta delle vulnerabilità. Resta da decidere se l'industria lascerà l'OT un passo indietro o lo metterà al centro.

---

Analisi e commento a cura di MON5 su ricerca e dati di pubblico dominio del settore OT/ICS.