Un exploit zero-day assistito da intelligenza artificiale ha fatto il suo debutto nel maggio 2026, documentato dal Google Threat Intelligence Group. Lo script Python aggirava l’autenticazione a due fattori su un diffuso strumento open source di amministrazione di sistema, sfruttando credenziali già disponibili. Non era un errore di memoria o un input non validato: la falla nasceva da una logica di fiducia predefinita nel codice, un’assunzione rigida che fuzzer e analizzatori statici avrebbero facilmente ignorato. Un modello linguistico, invece, può setacciare le interazioni tra permessi, funzioni e comportamenti attesi, trovando contraddizioni logiche che non lasciano tracce tecniche vistose.

Il caso non è isolato. Nel 2025 Google aveva già contato 90 zero-day sfruttati in rete, contro i 78 dell’anno precedente, con i software enterprise e gli appliance a coprire il 48% dei casi. La pressione si sposta però su un altro piano: la scoperta sta diventando più rapida per entrambe le parti, ma la vera frizione arriva dopo.

Quando una vulnerabilità viene resa pubblica, il primo ostacolo è capire dove giri esattamente il componente difettoso. Negli ambienti a container, un’immagine può trascinarsi pacchetti di sistema, librerie applicative e dipendenze ereditate dall’immagine base, spesso senza relazione con il carico di lavoro visibile. Un componente può annidarsi diversi strati sotto l’applicazione e comparire in decine di immagini senza che l’organizzazione lo abbia mai aggiunto direttamente. Log4Shell lo ha insegnato nel 2021: ottenere la patch era solo l’inizio; individuare ogni server, applicazione e container con la versione vulnerabile ha richiesto settimane.

Le distinte base software (SBOM) e le immagini minimali riducono il problema non perché eliminino le vulnerabilità sconosciute, ma perché restringono l’area di ricerca. Meno pacchetti da ispezionare, meno punti di esposizione possibile, meno codice da sostituire o ritestare una volta nota la falla.

Lo stesso vale per le correzioni generate dall’AI. Sistemi come CodeMender di Google DeepMind hanno contribuito 72 fix a progetti open source in sei mesi, ma ogni patch veniva riesaminata da umani per evitare regressioni. Il problema vero non è produrre la modifica, è sapere quali immagini la contengano. In un ambiente scarsamente documentato, ricostruire l’inventario può richiedere più tempo che scrivere la correzione.

Qui si consuma un ribaltamento strutturale. Negli ultimi anni la corsa agli strumenti di detection ha assorbito investimenti e attenzione. Ora il vantaggio si sposta su chi ha la disciplina operativa per mantenere un inventario aggiornato, ridurre la superficie delle immagini e ricostruire rapidamente i container quando una dipendenza cambia. Non serve l’ultimo modello di AI; basta sapere esattamente cosa gira. Chi adotta registri accurati e pipeline di rebuild automatizzate chiude la finestra di esposizione in ore, mentre altri la tengono aperta per giorni senza neppure saperlo. In un contesto in cui la velocità di scoperta dei difetti aumenta per tutti, il differenziale competitivo non è più chi trova prima, ma chi corregge prima — e questo dipende quasi interamente da scelte fatte mesi prima su software inventory, composizione delle immagini e processi di build.