La cybersecurity entra in una fase in cui il fattore tempo diventa il vero terreno di scontro. Gli attaccanti usano l’intelligenza artificiale per individuare vulnerabilità, costruire catene di exploit e comprimere in poche ore operazioni che in passato richiedevano giorni o settimane. In questo scenario, la gestione tradizionale delle vulnerabilità, basata su analisi manuali, liste di alert e processi di remediation distribuiti tra security team e sviluppatori, non basta più.
Google Cloud risponde con Google AI Threat Defense, una piattaforma autonoma e sempre attiva pensata per aiutare le aziende a prevedere i percorsi d’attacco, prioritizzare i rischi reali e accelerare la correzione delle vulnerabilità prima che possano essere sfruttate. Il punto non è semplicemente usare un modello AI per trovare difetti nel codice o generare nuovi avvisi. La proposta di Google Cloud punta a collegare l’identificazione delle esposizioni alla valutazione del rischio, alla generazione delle correzioni, alla verifica delle patch e al monitoraggio continuo dell’ambiente.
È un cambio di impostazione rilevante perché sposta la difesa da una logica reattiva a un modello operativo in cui l’intelligenza artificiale lavora su più livelli: analizza, simula, valida, corregge e controlla. Google AI Threat Defense nasce infatti dall’integrazione tra Gemini, Wiz, CodeMender, Mandiant e Google Security Operations, con l’obiettivo dichiarato di portare la gestione delle vulnerabilità e della risposta cyber a una velocità compatibile con quella degli attacchi automatizzati.
Intelligenza artificiale e cybersecurity, perché un solo modello non basta più
Il presupposto tecnico alla base di Google AI Threat Defense è netto: nella cybersecurity moderna non basta un singolo modello, né un singolo agente. Le minacce alimentate dall’AI richiedono più passaggi, più modelli e una capacità continua di incrociare segnali diversi. Alcuni modelli possono essere più efficaci nell’analisi della logica applicativa, altri nella configurazione cloud, nell’analisi binaria, nella validazione dell’exploitability o nella generazione di fix. Nessun modello, da solo, intercetta l’intero insieme delle vulnerabilità che altri modelli possono individuare.
Da qui nasce la strategia multi-AI della piattaforma. I modelli più leggeri e veloci possono essere usati per una copertura ampia e continua, mentre i modelli frontier vengono riservati agli asset più critici, alle applicazioni esposte verso Internet, ai servizi customer-facing, ai flussi di dati sensibili, ai sistemi con privilegi elevati e alle aree in cui il rischio di business è maggiore. La logica è anche economica: usare sempre e ovunque i modelli più potenti sarebbe costoso e inefficiente; usarli dove il contesto di rischio lo giustifica consente invece di ottimizzare copertura, profondità di analisi e costo operativo.
Wiz ha un ruolo centrale in questo modello perché fornisce il contesto di esposizione, vulnerabilità, identità, accesso ai dati sensibili e segnali runtime. In pratica, la piattaforma non si limita a dire che esiste una vulnerabilità, ma cerca di stabilire se quella vulnerabilità è raggiungibile, sfruttabile, collegata ad asset critici e rilevante per l’azienda. È qui che Google Cloud prova a differenziare la propria proposta rispetto a soluzioni che generano grandi quantità di alert senza una gerarchia operativa chiara.
Da Mandiant a Wiz, Google Cloud mette insieme intelligence, contesto e remediation
Google AI Threat Defense si appoggia su diversi elementi dell’ecosistema di sicurezza di Google Cloud. Gemini porta capacità di ragionamento e generazione di codice. Wiz contribuisce con la mappatura continua dell’esposizione cloud, applicativa, identitaria e runtime. CodeMender entra nella fase di correzione del codice e generazione delle patch. Mandiant fornisce competenza di threat intelligence, incident response e pianificazione operativa. Google Security Operations estende il modello al SOC, con capacità agentiche per rilevamento, triage, investigazione e hunting.
Il risultato è un’architettura che prova a unire due mondi spesso separati: il rilevamento delle vulnerabilità e la loro effettiva risoluzione. Nelle organizzazioni complesse, infatti, il problema non è solo sapere che un rischio esiste. Il vero collo di bottiglia è capire quale rischio vada affrontato per primo, chi ne sia responsabile, quali sistemi siano coinvolti, quali dipendenze vadano considerate, quale patch sia sicura da applicare e come verificare che la correzione non introduca nuovi problemi.
Google Cloud sostiene che l’intelligenza artificiale debba intervenire proprio in questa catena decisionale. Non per sostituire del tutto il controllo umano, ma per ridurre drasticamente il tempo necessario a passare dall’analisi all’azione. La formula è quella dell’autonomia sotto supervisione: agenti e modelli accelerano discovery, validazione e fix, mentre i team mantengono il controllo strategico sui processi, sulle priorità e sull’adozione delle correzioni.
La fase Prepare riduce l’esposizione prima ancora della patch
Il primo passaggio del framework di Google AI Threat Defense è Prepare. L’obiettivo è rafforzare le fondamenta dell’ambiente aziendale prima che una nuova vulnerabilità urgente costringa i team a inseguire l’emergenza. In questa fase la priorità non è soltanto correggere i bug noti, ma ridurre ciò che è inutilmente raggiungibile, validare ciò che può essere realmente sfruttato e costruire processi di risposta che non dipendano da triage manuali lenti.
Il principio è semplice: asset sensibili, applicazioni critiche, servizi esposti e percorsi non affidabili non dovrebbero essere accessibili da Internet o da canali non controllati se non è strettamente necessario. Anche una vulnerabilità non ancora corretta può essere meno pericolosa se il sistema interessato non è raggiungibile o se l’accesso è confinato da controlli appropriati. La riduzione della superficie d’attacco diventa quindi una misura preventiva, non una semplice attività di hardening secondaria.
Wiz viene usato per creare una mappa viva delle esposizioni, includendo applicazioni, infrastruttura, API, identità e ambienti runtime. Il suo agente di AI pen-testing contestuale simula possibili attacchi per identificare e validare percorsi complessi di compromissione, compresi quelli che nascono dall’interazione tra applicazioni, permessi, configurazioni, business logic e identità. È un punto importante: non tutte le vulnerabilità vivono nel codice. Molte emergono da come sistemi diversi si combinano in produzione.
Scan and prioritize porta l’analisi AI sui rischi davvero critici
La seconda fase è Scan and prioritize. Qui Google AI Threat Defense passa dalla mappatura dell’esposizione all’analisi profonda dei rischi, con un approccio che combina scansioni ampie e analisi AI più costose ma più sofisticate. Le verifiche superficiali non bastano più, perché gli attaccanti possono concatenare difetti apparentemente minori, trovare falle logiche, sfruttare dipendenze vulnerabili o abusare di confini di fiducia mal progettati.
I modelli frontier possono aiutare a individuare vulnerabilità complesse, errori nella logica applicativa, API esposte, dipendenze rischiose e catene di problemi che, prese singolarmente, potrebbero non sembrare prioritarie ma che insieme diventano sfruttabili. Tuttavia, queste scansioni richiedono più risorse e non sono sempre sostenibili su ogni asset in modo continuo. Per questo la piattaforma usa il contesto di Wiz per decidere dove concentrare l’analisi più profonda.
Quando viene scoperto un difetto nel codice, Google AI Threat Defense arricchisce il finding con il contesto architetturale e runtime. Una lista grezza di vulnerabilità diventa così una mappa dei rischi effettivi, con enfasi su ciò che è raggiungibile, esposto, collegato a dati sensibili o rilevante per il business. Per gli sviluppatori questo significa poter vedere anche dipendenze tra librerie sorgente e binari, capire quali modifiche debbano essere coordinate e valutare se il comportamento o la firma di componenti specifici debbano cambiare insieme.
Mandiant aggiunge a questa fase una dimensione operativa. Le sue competenze servono a costruire piani di risposta azionabili, gestire improvvisi picchi di criticità, definire strategie per dismettere prodotti legacy e supportare l’introduzione di patch generate dall’AI senza travolgere i team di ingegneria.
CodeMender accelera la remediation dal finding alla patch verificata
La terza fase è Remediate, ed è probabilmente quella in cui Google Cloud vuole marcare di più la distanza dalle soluzioni limitate al rilevamento. Dopo l’identificazione delle vulnerabilità, l’obiettivo è ridurre il tempo di remediation da settimane a minuti, generando fix, prioritizzandoli e verificandoli prima della messa in produzione.
CodeMender lavora direttamente nei flussi degli sviluppatori, attraverso IDE o CLI, e sfrutta le capacità di Gemini per proporre correzioni, sostituire codice vulnerabile, riscrivere porzioni legacy in linguaggi memory-safe e analizzare dipendenze librarie per rollout coordinati. L’integrazione con Antigravity e Wiz serve a connettere il lavoro sul codice con il contesto di rischio reale dell’ambiente aziendale.
Un passaggio chiave è la verifica automatica delle patch. Prima che una correzione venga applicata, la piattaforma genera test per validare il fix. Una volta completata la remediation, le librerie vengono tracciate sia nel source control sia negli ambienti di produzione. Questo consente di vedere quale modello sia stato usato per generare determinate patch, quando siano state create e dove siano state distribuite.
Il tema della tracciabilità non è un dettaglio. In un modello in cui l’AI contribuisce direttamente alla modifica del codice, le aziende devono poter mantenere controllo, auditabilità e governance. Sapere quale agente o modello ha generato una patch, con quali evidenze e in quale contesto, diventa parte integrante della sicurezza del software development lifecycle.
La protezione dei dati entra nella valutazione del rischio
Google AI Threat Defense non limita la remediation alla correzione del codice. La piattaforma guarda anche ai percorsi attraverso cui sistemi vulnerabili potrebbero accedere a dati sensibili. Questo aspetto è cruciale perché una vulnerabilità non ha lo stesso impatto se riguarda un workload isolato o un sistema in grado di raggiungere servizi con dati critici.
Consolidare la visibilità sull’intero data estate consente di identificare servizi contenenti dati sensibili raggiungibili da workload rischiosi e di prioritizzare controlli come cifratura, identità, segmentazione di rete e monitoraggio dell’esfiltrazione. In parallelo, la visibilità sul ciclo di sviluppo permette di controllare meglio come software e configurazioni vengono modificati e distribuiti.
È una lettura più matura del rischio cyber: non basta assegnare una gravità tecnica a una CVE. Bisogna capire dove si trova, chi può raggiungerla, che cosa protegge, quali identità può coinvolgere, quali dati può esporre e quali conseguenze operative o regolatorie può generare.
Monitor sposta il SOC verso detection e risposta a velocità macchina
La quarta fase è Monitor. Anche un ambiente rafforzato e continuamente corretto resta esposto a minacce attive. Le pipeline di scansione del codice sono fondamentali per intercettare difetti prima del deployment, ma non possono bloccare da sole un exploit in corso. Per questo Google AI Threat Defense estende il modello alla detection runtime e alla risposta attiva.
La piattaforma usa agenti autonomi per supportare hunting, investigazione di attività sospette e risposta agli attacchi in tempo reale. Le capacità agentiche di Google Security Operations contribuiscono ad automatizzare rilevamenti, triage, investigazioni e ricerca di anomalie emergenti su telemetria di rete, identità e applicazioni. L’obiettivo è costruire una capacità di monitoraggio continuo che aiuti le aziende a scoprire vulnerabilità e comportamenti anomali prima che lo facciano gli avversari.
Il monitoraggio si lega anche alla preparazione operativa. Google Cloud insiste sulla necessità di framework di risposta provati, ownership definite e risultati misurabili. In altre parole, la difesa a velocità macchina non può essere solo una questione di modelli: richiede processi, ruoli e playbook già pronti.
La piattaforma include anche un livello di sicurezza di base sugli ambienti, con container image rafforzate, firmate e verificate quotidianamente. È un modo per ridurre la superficie d’attacco fin dall’infrastruttura, non soltanto nel codice applicativo.
Partner e CISO Community estendono il modello nelle aziende
Google Cloud affida un ruolo esplicito anche all’ecosistema. Partner come Accenture, Deloitte, Netenrich, PwC e TENEX.AI vengono indicati come soggetti in grado di supportare le aziende nella valutazione delle architetture cloud, nell’integrazione delle capacità di AI Threat Defense nelle pipeline di sviluppo e nella costruzione di workflow di sicurezza personalizzati.
Il punto è pratico: introdurre una piattaforma autonoma di difesa non significa solo accendere un nuovo servizio. Le aziende devono adattare processi DevSecOps, policy di remediation, controlli di compliance, ruoli dei team e modalità di gestione del rischio. I partner possono quindi aiutare a tradurre la tecnologia in modelli operativi specifici per settore, architettura e maturità organizzativa.
Accanto all’ecosistema dei partner, Google Cloud richiama anche la propria CISO Community, che include manager di aziende come Morgan Stanley, MSCI, TELUS e Thales. L’idea è usare il confronto con i responsabili della sicurezza di grandi organizzazioni per trasformare esigenze reali in soluzioni operative e orientare l’evoluzione della difesa AI.
Per Google Cloud la vulnerabilità gestita a velocità umana non è più sostenibile
Il messaggio di fondo è chiaro: la finestra di exploit si sta comprimendo e la gestione delle vulnerabilità a velocità umana non è più una strategia sostenibile per il rischio enterprise. Se gli attaccanti usano l’AI per automatizzare discovery, analisi e sfruttamento, i difensori devono usare l’AI non solo per osservare, ma anche per decidere, prioritizzare, correggere e monitorare.
Google AI Threat Defense rappresenta quindi un tassello importante nella trasformazione della sicurezza aziendale verso modelli più autonomi e continui. La promessa è ambiziosa: passare da backlog di vulnerabilità difficili da governare a una pipeline in cui esposizione, rischio, remediation e monitoraggio sono collegati in modo dinamico.
Resta un punto da non sottovalutare. L’autonomia, in cybersecurity, non elimina la complessità organizzativa. Le aziende dovranno comunque definire soglie di intervento, responsabilità, policy di approvazione, audit delle patch generate dall’AI e integrazione con strumenti già presenti. Ma la direzione indicata da Google Cloud è coerente con l’evoluzione del threat landscape: quando l’attacco accelera grazie all’intelligenza artificiale, anche la difesa deve uscire dalla logica manuale e frammentata.
In questo senso Google AI Threat Defense non è solo un nuovo prodotto di sicurezza. È la formalizzazione di un modello in cui cloud security, sviluppo software, threat intelligence, AI agentica e operations convergono in una piattaforma pensata per ridurre il tempo tra la scoperta del rischio e la sua neutralizzazione. Per le imprese, la questione non sarà più se adottare l’AI nella difesa cyber, ma come governarla senza perdere controllo, tracciabilità e responsabilità.
