Il 23 giugno 2026 Elastic Security Labs ha reso pubblica l'architettura interna di un agente AI generativo che produce bozze complete di advisory di sicurezza CVE partendo da report di vulnerabilità grezzi. Il sistema, già operativo con l'advisory ESA-2026-01, abbatte il tempo di redazione da un processo descritto come "convoluto and drawn-out" a una durata misurata in minuti. La chiave è il grounding: un ciclo RAG che attinge a cataloghi MITRE CWE e CAPEC indicizzati continuamente in Elasticsearch, impedendo al modello di inventare identificatori plausibili ma inesistenti.
- Elastic ha costruito l'agente con Elastic Agent Builder e lo ha messo in produzione con ESA-2026-01, primo advisory generato attraverso questa pipeline.
- Il sistema usa RAG su due indici Elasticsearch dedicati, web-crawl-mitre-cwe-software e web-crawl-mitre-capec-software, aggiornati in automatico da Elastic Crawler.
- Senza retrieval dei dati MITRE, il modello generava ID CWE e CAPEC "plausibili ma inesistenti": l'hallucination è documentata come rischio concreto superato.
- L'output copre l'intero stack di disclosure: classificazione CWE, metodologia CAPEC, punteggio CVSS e guida alle mitigazioni, dentro il template CVE standardizzato.
Come funziona la pipeline: dal report grezzo alla bozza CVE
Il flusso inizia con l'ingestion di un report di vulnerabilità nel formato usato dal team PSIRT di Elastic. L'azienda segue il framework FIRST PSIRT in quattro fasi — discovery, triage, remediation, disclosure — e l'agente AI interviene nella fase finale, trasformando le note tecniche interne in un documento strutturato secondo il template CVE canonico: "[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]".
Il nucleo architetturale è il retrieval. Prima della generazione, il sistema interroga gli indici Elasticsearch che ospitano i cataloghi MITRE: uno per le weakness (CWE, indice web-crawl-mitre-cwe-software) e uno per i pattern di attacco (CAPEC, indice web-crawl-mitre-capec-software). I dati sono acquisiti tramite Elastic Crawler con configurazioni YAML dedicate, eseguite "on a continuous schedule" così da mantenere gli indici allineati alle pubblicazioni MITRE. La connessione avviene su istanza Elastic Serverless, con autenticazione via API key.
Solo dopo il recupero dei riferimenti autorevoli il modello genera il testo dell'advisory. Elastic documenta esplicitamente che nelle prove iniziali, "when asked to assign CWE and CAPEC IDs unaided, the model frequently produced plausible-looking but non-existent entries". Il RAG risolve il problema vincolando l'output a identificativi reali, citando l'OWASP LLM09 come framework di riferimento per la gestione del rischio di hallucination nei sistemi di intelligenza artificiale generativa.
"ESA-2026-01 is already in production as an example of output that went through this pipeline" — Elastic InfoSec Product Security Team
Il caso concreto: ESA-2026-01 e i database downstream
L'advisory ESA-2026-01 è l'evidenza che il sistema non è una proof of concept ma un processo in esercizio. Una volta pubblicati, gli advisory Elastic (ESA) vengono inseriti nel programma CVE e propagati verso i database downstream: NIST NVD, ENISA EU Vulnerability Database e JPCERT/CC Japan Vulnerability Notes. Il programma CVE conta oltre 345.000 record secondo cve.org, e ogni advisory nuovo si integra in questa catena di distribuzione globale.
Il dato rilevante è la qualità del dato trasmesso. Un advisory CVE errato nella classificazione CWE o nel punteggio CVSS non è un malfunzionamento interno: è informazione che alimenta sistemi di prioritizzazione, tool di vulnerability management e policy di patch in tutta la filiera. Elastic sceglie di documentare pubblicamente l'architettura, con configurazioni tecniche verificabili — inclusi frammenti YAML con campi redatti come "YOUR_ELASTIC_URL" — piuttosto che presentare il risultato come scatola chiusa.
Cosa fare adesso
Per i team PSIRT che gestiscono disclosure di vulnerabilità, il caso Elastic offre tre insegnamenti operativi. Primo: indicizzare cataloghi di riferimento come MITRE CWE e CAPEC in un motore di ricerca interno, con aggiornamento continuo tramite crawler programmati, è la condizione necessaria per usare LLM generativi senza generare identificatori falsi. Secondo: il template CVE standardizzato — "[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]" — deve essere incorporato nel prompt o nel sistema di generazione, non delegato alla libera composizione del modello. Terzo: la verifica del grounding RAG deve essere parte del workflow, non un controllo a posteriori; Elastic documenta che l'hallucination su ID MITRE era sistematica prima dell'introduzione del retrieval.
Per gli analisti che valutano vendor di sicurezza, la domanda da porre è se l'architettura RAG sia replicabile con gli strumenti già in uso. Elastic usa componenti proprietari (Elastic Agent Builder, Elastic Crawler, Elasticsearch Serverless) ma il pattern — LLM + retrieval su sorgenti autorevoli + template strutturato — è indipendente dalla piattaforma. Il limite è la disponibilità: le configurazioni mostrate sono parziali e il documento non dichiara accesso esterno alla pipeline.
Perché è importante
Il valore del caso documentato sta nel metodo, non nelle metriche mancanti. Elastic non quantifica il risparmio temporale medio né il throughput aumentato rispetto al processo manuale, descritto solo come "time-consuming". Non è documentato quale LLM venga impiegato (modello, versione, provider), né se la pipeline sia disponibile per clienti esterni o riservata all'uso interno. Mancano metriche di accuratezza: tasso di errori, falsi positivi o negativi nella classificazione automatica.
Non è chiaro se altri vendor di sicurezza utilizzino approcci analoghi, e il documento non sostiene posizioni di pionierato. Il limite più significativo è la dipendenza da una sola fonte primaria. Nessuna delle fonti contestuali (FIRST, cve.org, NVD) corrobora la claim principale sull'architettura o sulla produzione di ESA-2026-01. L'intera descrizione tecnica deriva esclusivamente dal documento di Elastic Security Labs, con il rischio di bias di marketing proprio dei vendor che documentano i propri sistemi.
Ciò non diminuisce la rilevanza del problema affrontato. In un ecosistema con 345.000+ record CVE, la velocità e l'accuratezza della disclosure sono variabili di sicurezza collettiva. Un workflow PSIRT accelerato con AI generativa, ancorato a sorgenti autorevoli e verificabili, è un modello che altri team possono adattare — a patto di replicare il grounding, non solo la generazione.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://www.elastic.co/security-labs/security-advisory-automation-rag-elastic-agent-builder
- https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1
- https://www.cve.org/
- https://nvd.nist.gov/