Elastic Automates CVE Advisory Writing with RAG on MITRE Data

Elastic Security Labs has put into production an AI pipeline that generates complete CVE advisory drafts with CWE, CAPEC, and CVSS, grounding data in continuously indexed MITRE catalogs via Elasticsearch.

On June 23, 2026, Elastic Security Labs disclosed the internal architecture of a generative AI agent that produces complete CVE security advisory drafts from raw vulnerability reports. The system, already operational with advisory ESA-2026-01, cuts drafting time from a process described as "convoluted and drawn-out" to a duration measured in minutes. The key is grounding: a RAG cycle that draws on MITRE CWE and CAPEC catalogs continuously indexed in Elasticsearch, preventing the model from inventing plausible but non-existent identifiers.

Key Takeaways

Elastic built the agent with Elastic Agent Builder and deployed it in production with ESA-2026-01, the first advisory generated through this pipeline.
The system uses RAG on two dedicated Elasticsearch indices, web-crawl-mitre-cwe-software and web-crawl-mitre-capec-software, updated automatically by Elastic Crawler.
Without retrieval of MITRE data, the model generated "plausible but non-existent" CWE and CAPEC IDs: hallucination is documented as a concrete risk that has been overcome.
The output covers the full disclosure stack: CWE classification, CAPEC methodology, CVSS scoring, and mitigation guidance, inside the standardized CVE template.

How the Pipeline Works: From Raw Report to CVE Draft

The flow begins with ingestion of a vulnerability report in the format used by Elastic's PSIRT team. The company follows the FIRST PSIRT framework in four phases — discovery, triage, remediation, disclosure — and the AI agent intervenes in the final phase, transforming internal technical notes into a document structured according to the canonical CVE template: "[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]".

The architectural core is retrieval. Before generation, the system queries the Elasticsearch indices hosting the MITRE catalogs: one for weaknesses (CWE, index web-crawl-mitre-cwe-software) and one for attack patterns (CAPEC, index web-crawl-mitre-capec-software). Data is acquired via Elastic Crawler with dedicated YAML configurations, run "on a continuous schedule" to keep indices aligned with MITRE publications. The connection runs on an Elastic Serverless instance, authenticated via API key.

Only after retrieving authoritative references does the model generate the advisory text. Elastic explicitly documents that in initial tests, "when asked to assign CWE and CAPEC IDs unaided, the model frequently produced plausible-looking but non-existent entries." RAG solves the problem by constraining output to real identifiers, citing OWASP LLM09 as the reference framework for managing hallucination risk in generative AI systems.

"ESA-2026-01 is already in production as an example of output that went through this pipeline" — Elastic InfoSec Product Security Team

The Concrete Case: ESA-2026-01 and Downstream Databases

Advisory ESA-2026-01 is evidence that the system is not a proof of concept but a process in operation. Once published, Elastic advisories (ESA) enter the CVE program and propagate to downstream databases: NIST NVD, ENISA EU Vulnerability Database, and JPCERT/CC Japan Vulnerability Notes. The CVE program counts over 345,000 records according to cve.org, and every new advisory integrates into this global distribution chain.

The relevant point is the quality of the transmitted data. An erroneous CVE advisory in CWE classification or CVSS score is not an internal malfunction: it is information that feeds prioritization systems, vulnerability management tools, and patch policies across the supply chain. Elastic chooses to publicly document the architecture, with verifiable technical configurations — including YAML snippets with redacted fields like "YOUR_ELASTIC_URL" — rather than present the result as a black box.

Action Items for PSIRT Teams and Analysts

For PSIRT teams managing vulnerability disclosure, the Elastic case offers three operational lessons. First: indexing reference catalogs like MITRE CWE and CAPEC in an internal search engine, with continuous updates via scheduled crawlers, is the necessary condition for using generative LLMs without generating false identifiers. Second: the standardized CVE template — "[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]" — must be embedded in the prompt or generation system, not left to the model's free composition. Third: RAG grounding verification must be part of the workflow, not a post-hoc check; Elastic documents that hallucination on MITRE IDs was systematic before retrieval was introduced.

For analysts evaluating security vendors, the question to ask is whether the RAG architecture is replicable with tools already in use. Elastic uses proprietary components (Elastic Agent Builder, Elastic Crawler, Elasticsearch Serverless) but the pattern — LLM + retrieval on authoritative sources + structured template — is platform-independent. The limitation is availability: the configurations shown are partial and the document does not declare external access to the pipeline.

Why This Matters

The value of the documented case lies in the method, not in missing metrics. Elastic does not quantify average time savings or increased throughput compared to the manual process, described only as "time-consuming." It is not documented which LLM is employed (model, version, provider), nor whether the pipeline is available to external customers or reserved for internal use. Accuracy metrics are missing: error rates, false positives or negatives in automatic classification.

It is unclear whether other security vendors use similar approaches, and the document does not claim pioneering status. The most significant limitation is reliance on a single primary source. None of the contextual sources (FIRST, cve.org, NVD) corroborate the main claim about the architecture or the production of ESA-2026-01. The entire technical description derives exclusively from the Elastic Security Labs document, with the risk of marketing bias inherent in vendors documenting their own systems.

This does not diminish the relevance of the problem addressed. In an ecosystem with 345,000+ CVE records, the speed and accuracy of disclosure are collective security variables. A PSIRT workflow accelerated with generative AI, anchored to authoritative and verifiable sources, is a model other teams can adapt — provided they replicate the grounding, not just the generation.

Information is based on the cited source and current as of publication.

Sources

Sources and references