// 3 ZERO-DAY · 5 CVE · 6 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
L'Agentic Vulnerability Discovery Harness di Google Mandiant ha scoperto oltre 100 vulnerabilità critiche verificate in repository aziendali rubati in soli due

Il 18 agosto 2026 Google Threat Intelligence Group ha reso pubblica l'architettura dell'Agentic Vulnerability Discovery Harness (AVDH), un sistema multi-agent basato su modelli linguistici di grandi dimensioni che ha identificato oltre 100 vulnerabilità critiche verificate in repository di codice sorgente aziendale rubato nel corso di un singolo incident response durato due giorni. Il sistema è operativo internamente a Mandiant da dieci mesi e ha generato decine di migliaia di finding su decine di milioni di linee di codice, con 12 CVE già assegnati in web extension e progetti open-source e altrettanti in disclosure attiva.

Punti chiave
  • AVDH ha scoperto oltre 100 vulnerabilità critiche verificate in due giorni di analisi su codice sorgente aziendale rubato, durante un incident response specifico non ulteriormente dettagliato.
  • L'architettura utilizza Google Agent Development Kit (ADK) per orchestrare una pipeline sequenziale di agenti specializzati: Explorer, Threat Model Synthesis, Discovery, Enrichment, Access Control, Data Flow Analysis e Validation.
  • Ogni threat model richiede approvazione umana prima di procedere; i finding confermati passano a consulenti Mandiant per validazione manuale con proof-of-concept.
  • Mandiant ha costruito codebase sintetiche vulnerabili per benchmark interni, evitando dataset pubblici potenzialmente inclusi nel training dei modelli LLM.

Perché AVDH rompe il paradigma della code review tradizionale

La rivelazione di AVDH interrompe una convenzione consolidata: che la review del codice sorgente rimanesse un processo intrinsecamente umano, eventualmente assistito da scanner statici. I ricercatori Mandiant Alex Tselevich e Michael Maturi, citati da Help Net Security, hanno espresso questa rottura in termini espliciti: la revisione manuale non riesce a stare al passo con l'intelligenza artificiale, e i motori di scanning tradizionali mancano sistematicamente lo spettro completo delle vulnerabilità nascoste nel software moderno.

La risposta di Mandiant non è stato un singolo modello generico, ma un harness architetturale: una struttura di contenimento e orchestrazione che impone discipline specifiche a componenti altrimenti indeterminati. L'ADK, l'Agent Development Kit di Google, funge da strato deterministico che garantisce l'esecuzione sequenziale degli agenti e impedisce derive autonome non autorizzate. La pipeline è progettata per simulare, non sostituire, il ragionamento di un ricercatore esperto: ogni fase produce output vincolato per la successiva, con checkpoint di validazione incrociata a temperatura elevata tra agenti indipendenti.

"Manual source code review can't keep pace with AI, and traditional scanning engines consistently miss the broad spectrum of vulnerabilities hidden in modern software" — Alex Tselevich e Michael Maturi, ricercatori Mandiant

Come funziona la pipeline: dall'esplorazione al handoff umano

L'architettura AVDH si compone di sette agenti con compiti distinti, non di un unico modello generalista. L'Explorer agent mappa il codebase target; il Threat Model Synthesis agent costruisce modelli di minaccia; i Discovery agent identificano entry point potenziali; l'Enrichment agent contestualizza ogni finding; gli agenti Access Control e Data Flow Analysis verificano rispettivamente i controlli di autorizzazione e i flussi dati sensibili; infine i Validation agent eseguono verifiche incrociate a temperatura elevata per ridurre la coerenza illusoria dei singoli LLM.

Un vincolo architetturale rigido permea ogni fase: nessun threat model procede senza approvazione umana. Questo non è un aggiustamento post-hoc, ma un requisito strutturale dell'harness. I finding che superano la validazione automatica incrociata vengono trasmessi a consulenti Mandiant per verifica manuale con proof-of-concept e risk rating finale. Il processo, documentato nel blog ufficiale Google Cloud, include esplicitamente lo scarto dei finding che falliscono questa validazione umana. La fonte non quantifica la percentuale di falsi positivi filtrati a questo stadio.

Il problema della contaminazione dei training set

Un dettaglio dell'architettura rivela una consapevolezza insolita dei limiti circolari dei modelli LLM: Mandiant ha costruito codebase sintetiche vulnerabili per benchmark e validazione interna, evitando deliberatamente i dataset pubblici di vulnerabilità. Il motivo, implicito ma non oscuro, è che questi dataset sono probabilmente già inclusi nel training dei modelli di frontiera, rendendo inaffidabili i test basati su essi per misurare capacità di generalizzazione reale.

Questa scelta architettonica ha conseguenze che escono dal perimetro di Google. Se i difensori non possono più fidarsi dei benchmark pubblici per valutare strumenti di vulnerability discovery basati su LLM, ogni team di sicurezza che voglia replicare approcci simili deve investire in dataset proprietari sintetici. Il costo di ingresso per l'automazione agentica della sicurezza del codice sale di conseguenza, favorendo actor con risorse di ricerca e sviluppo significative.

Perché è importante

Il dossier non specifica la natura dei dati esposti nei repository rubati oggetto dell'analisi in 48 ore, né identifica il cliente o il settore coinvolto nell'incidente. Non è quantificata la percentuale di falsi positivi o falsi negativi di AVDH nel suo complesso, e non è chiaro se il sistema sarà rilasciato come prodotto commerciale o rimarrà strumento interno con sola blueprint architetturale condivisa.

I record NVD confermano l'esistenza di CVE-2026-13242 (CVSS 6.5 MEDIUM) e CVE-2026-55803 (CVSS 5.9 MEDIUM), entrambi relativi a prodotti Drupal, ma non menzionano AVDH o Google Mandiant nel loro campo descrizione. Il collegamento tra questi identificatori e la pipeline AVDH resta pertanto non verificato su fonti primarie indipendenti; le fonti Google e Help Net Security li citano come esempi di CVE assegnati nel programma più ampio di Mandiant, senza attestazione diretta di scoperta tramite agenti AI.

Il modello LLM esatto utilizzato non è dichiarato nelle fonti primarie, con una sola eccezione parziale: il blog Google Cloud menziona Gemini Flash Lite per i Discovery agents, lasciando indeterminati gli altri componenti della pipeline. Questo limite di disclosure incide sulla replicabilità dell'architettura da parte di team esterni con modelli differenti.

L'annuncio dei ricercatori: automazione con arbitro umano

I ricercatori Tselevich e Maturi hanno formulato il claim centrale del programma con una citazione diretta riportata da Help Net Security: il successo dell'harness dimostra che i difensori possono recuperare vantaggio contro l'AI avversaria, incapsulando modelli di frontiera entro un harness definito da esperti per automatizzare la scoperta delle vulnerabilità di routine. La stessa fonte riporta la raccomandazione esplicita ai difensori di rete che considerino implementazioni simili: validare manualmente i finding, un'indicazione operativa che riproduce il vincolo strutturale già descritto nell'architettura AVDH.

Questa raccomandazione non è generica: è coerente con il design del sistema reso pubblico, dove l'handoff umano non è opzionale ma integrato. La differenza tra un modello LLM libero di analizzare codice e un harness agentico risiede proprio in questa integrazione deterministico-probabilistica: l'orchestrazione ADK fornisce la struttura, i modelli forniscono la ricerca pattern, l'operatore fornisce la decisione finale sul rischio.

FAQ

AVDH è disponibile come prodotto commerciale?

No. Al momento Google ha rilasciato solo la blueprint architetturale del sistema. Non emergono nella documentazione pubblica roadmap di commercializzazione o licenze per utilizzo esterno.

I CVE citati sono confermati come scoperti da AVDH?

I record NVD per CVE-2026-13242 e CVE-2026-55803 non menzionano AVDH né Google Mandiant. Le fonti primarie li citano come esempi di CVE assegnati nel programma Mandiant, senza attestazione diretta di scoperta tramite la pipeline agentica.

Qual è il ruolo dell'operatore umano nel sistema?

Gli operatori umani approvano ogni threat model prima che la pipeline proceda, e validano manualmente con proof-of-concept ogni finding confermato dall'ultima fase automatica. Non è documentata alcuna modalità di esecuzione completamente autonoma.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. gbhackers.com
  2. helpnetsecurity.com
  3. cloud.google.com
  4. itwire.com
  5. nvd.nist.gov