Automação de avisos de segurança com o Elastic Agent Builder

A equipe de Segurança de Produtos InfoSec da Elastic criou um agente de IA generativo usando o Elastic Agent Builder que elabora avisos de segurança CVE completos (classificação CWE, metodologia CAPEC, pontuação CVSS e orientações de mitigação) diretamente a partir de relatórios de vulnerabilidades brutos. O agente utiliza o RAG em relação aos catálogos MITRE CWE e CAPEC indexados no Elasticsearch, o que fundamenta sua saída em dados confiáveis e evita IDs de classificação incorretos. O ESA-2026-01 já está em produção como exemplo de produto que passou por esse processo. Eis como o construímos.

Como os avisos de segurança são elaborados manualmente (e por que isso é lento)

Na Elastic, gerenciamos o ciclo de vida das vulnerabilidades de produtos usando o PSIRT Service Framework, que define quatro etapas: descoberta, triagem, remediação e divulgação. Cada aviso de segurança começa com um relatório de vulnerabilidades recebido durante a fase de descoberta, e esses relatórios variam muito em qualidade — traduzi-los para algo que os clientes possam compreender é demorado. Elaboramos o aviso de segurança durante a fase de divulgação, antes do lançamento planejado do produto que contém a correção. O aviso é então publicado como um Aviso de Segurança da Elastic (ESA, na sigla em inglês), com um ID CVE atribuído, no fórum de Anúncios de Segurança da Elastic , onde qualquer pessoa pode revisar as vulnerabilidades divulgadas e as mitigações associadas.

Cada divulgação também é publicada no Programa CVE, de onde é automaticamente absorvida por bancos de dados nacionais e regionais, incluindo o Banco de Dados Nacional de Vulnerabilidades dos EUA (NIST), o Banco de Dados Europeu de Vulnerabilidades da UE (ENISA) e o Japan Vulnerability Notes (JPCERT/CC).

Para manter a consistência dos nossos resultados, seguimos o modelo padrão de descrição de Vulnerabilidades e Exposições Comuns (CVE):

[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]

O TIPO DE PROBLEMA é identificado usando uma entrada de Enumeração de Fraquezas Comuns (CWE, na sigla em inglês), e o Vetor é descrito usando uma entrada de Enumeração e Classificação de Padrões de Ataque Comuns (CAPEC, na sigla em inglês).

Substituindo os valores corretos de CWE e CAPEC para cada vulnerabilidade, o modelo fica assim:

[Common Weakness Enumeration] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [Common Attack Pattern Enumeration and Classification]

A maior parte do trabalho manual consiste em condensar um relatório de vulnerabilidades longo e frequentemente complexo em um aviso conciso e preciso, com uma avaliação de impacto clara para os clientes. Identificar as classificações corretas de CWE e CAPEC, além disso, torna o processo complexo e demorado. É aqui que a automação tem mais a oferecer.

Automatizando rascunhos de avisos de segurança com o Elastic Agent Builder e o RAG.

Para agilizar esse processo, nossa Equipe de Segurança de Produtos de Informação desenvolveu uma solução que utiliza um Modelo de Liderança de Liderança (LLM) para gerar automaticamente a frase padronizada para avisos de segurança. Esta solução envolve duas etapas principais:

Ingestão de dados de categorização de vulnerabilidades: Alucinações são um modo de falha bem documentado para sistemas de gerenciamento de vida (LLMs) que operam sem uma base confiável. O OWASP Top 10 para aplicações LLM (LLM09) lista isso como uma categoria de risco principal, e foi a motivação original para a Geração Aumentada por Recuperação. Observamos isso diretamente em nossos primeiros experimentos: quando solicitado a atribuir IDs CWE e CAPEC sem auxílio, o modelo frequentemente produzia entradas de aparência plausível, mas inexistentes. Para evitar isso, usamos o Elastic Crawler para extrair os sites CWE e CAPEC e ingerir os dados em dois índices Elasticsearch: web-crawl-mitre-cwe-software e web-crawl-mitre-capec-software.
Construindo o agente de IA generativo: Utilizamos o Elastic Agent Builder para criar um agente personalizado que usa um LLM para gerar o texto de aconselhamento com base nos dados ingeridos.

Etapa 1: Indexação dos dados MITRE CWE e CAPEC no Elasticsearch

O primeiro passo foi inserir os dados CWE e CAPEC no Elasticsearch. Para isso, criamos uma instância do Elastic Serverless , anotamos os detalhes da conexão e geramos uma chave de API. Em seguida, criamos as configurações para que o Elastic Crawler visitasse os sites da MITRE e extraísse as informações relevantes. As mesmas configurações de rastreadores são executadas em um cronograma contínuo, de modo que os índices permaneçam atualizados à medida que a MITRE publica novas entradas CWE e CAPEC. Isso mantém os dados do agente atualizados sem intervenção manual.

Configuração do rastreador CWE

Aqui está a configuração dos dados CWE usados para fundamentar nosso agente de IA em dados de vulnerabilidade confiáveis. O rastreador inicia sua busca na visualização de vulnerabilidades de software do CWE, segue links que correspondem ao padrão /data/definitions/ e extrai campos estruturados de cada página de vulnerabilidade, incluindo descrições, mitigações, consequências e exemplos observados, prontos para busca semântica ou pipelines RAG.

# CWE Crawler Configuration (crawl-config-mitre-cwe.yml)

output_sink: elasticsearch
output_index: web-crawl-mitre-cwe-software

elasticsearch:
  host: "YOUR_ELASTIC_URL"
  port: 443
  api_key: "YOUR_API_KEY"
  pipeline_enabled: false

domains:
  - url: https://cwe.mitre.org
    seed_urls:
      - https://cwe.mitre.org/data/definitions/699.html

    extraction_rulesets:
      - url_filters:
          - type: "regex"
            pattern: "/data/definitions/[0-9]+\\.html"
        rules:
          # 1. Capture the Full URL in a custom field
          - action: "extract"
            field_name: "cwe_source_url"
            selector: ".*" # Match everything in the URL
            join_as: "string"
            source: "url"

          # 2. Extract Just the ID Number from the URL (e.g., 79)
          - action: "extract"
            field_name: "cwe_id"
            selector: "definitions/([0-9]+)" # Capturing group isolates the digits
            join_as: "string"
            source: "url"

          # 3. Full Title
          - action: "extract"
            field_name: "cwe_full_title"
            selector: "h2"
            join_as: "string"
            source: "html"

          # 4. Description Section
          - action: "extract"
            field_name: "description"
            selector: "#Description .detail"
            join_as: "string"
            source: "html"

          # 5. Extended Description
          - action: "extract"
            field_name: "extended_description"
            selector: "#Extended_Description .detail"
            join_as: "string"
            source: "html"

          # 6. Alternate Terms (Array)
          - action: "extract"
            field_name: "alternate_terms"
            selector: "#Alternate_Terms .detail tr"
            join_as: "array"
            source: "html"

          # 7. Common Consequences (Array)
          - action: "extract"
            field_name: "common_consequences"
            selector: "#Common_Consequences .detail tr"
            join_as: "array"
            source: "html"

          # 8. Potential Mitigations (Array)
          - action: "extract"
            field_name: "potential_mitigations"
            selector: "#Potential_Mitigations .detail tr"
            join_as: "array"
            source: "html"

          # 9. Background Details
          - action: "extract"
            field_name: "background_details"
            selector: "#Background_Details .detail"
            join_as: "string"
            source: "html"

          # 10. Modes of Introduction (Array)
          - action: "extract"
            field_name: "modes_of_introduction"
            selector: "#Modes_Of_Introduction .detail tr"
            join_as: "array"
            source: "html"

          # 11. Applicable Platforms (Array)
          - action: "extract"
            field_name: "applicable_platforms"
            selector: "#Applicable_Platforms .detail tr"
            join_as: "array"
            source: "html"

          # 12. Likelihood of Exploit
          - action: "extract"
            field_name: "likelihood_of_exploit"
            selector: "#Likelihood_Of_Exploit .detail"
            join_as: "string"
            source: "html"

          # 13. Demonstrative Examples
          - action: "extract"
            field_name: "demonstrative_examples"
            selector: "#Demonstrative_Examples .detail"
            join_as: "string"
            source: "html"

          # 14. Observed Examples (Array)
          - action: "extract"
            field_name: "observed_examples"
            selector: "#Observed_Examples .detail tr"
            join_as: "array"
            source: "html"

          # 15. Taxonomy Mappings (Array)
          - action: "extract"
            field_name: "taxonomy_mappings"
            selector: "#Taxonomy_Mappings .detail tr"
            join_as: "array"
            source: "html"

          # 16. Related Attack Patterns (Array)
          - action: "extract"
            field_name: "related_attack_patterns"
            selector: "#Related_Attack_Patterns .detail tr"
            join_as: "array"
            source: "html"

          # 17. References (Array)
          - action: "extract"
            field_name: "references"
            selector: "#References .detail tr"
            join_as: "array"
            source: "html"

    crawl_rules:
      - policy: allow
        type: begins
        pattern: "/data/definitions/"
      - policy: deny
        type: contains
        pattern: "/history"
      - policy: deny
        type: regex
        pattern: .*

Configuração do rastreador CPEC

Aplicamos a mesma abordagem ao catálogo MITRE CAPEC, partindo da visualização de padrões de ataque de software e extraindo campos estruturados de cada página de padrão, incluindo descrições de ataque, fluxo de execução, pré-requisitos, habilidades necessárias e mitigações, todos indexados no Elasticsearch juntamente com os dados do CWE.

# CAPEC Crawler Configuration (crawl-config-mitre-capec-software.yml)
output_sink: elasticsearch
output_index: web-crawl-mitre-capec-software

elasticsearch:
  host: "YOUR_ELASTIC_URL"
  port: 443
  api_key: "YOUR_API_KEY"
  pipeline_enabled: false

domains:
  - url: https://capec.mitre.org
    seed_urls:
      - https://capec.mitre.org/data/definitions/513.html # The "Software" Category View

    extraction_rulesets:
      - url_filters:
          - type: "regex"
            pattern: "/data/definitions/[0-9]+\\.html"
        rules:
          # 1. Capture the Full Source URL
          - action: "extract"
            field_name: "capec_source_url"
            selector: ".*"
            join_as: "string"
            source: "url"

          # 2. CAPEC ID (isolates just the number from the URL, e.g., 63)
          - action: "extract"
            field_name: "capec_id"
            selector: "definitions/([0-9]+)"
            join_as: "string"
            source: "url"

          # 3. Full Title (e.g., CAPEC-63: Cross-Site Scripting)
          - action: "extract"
            field_name: "capec_full_title"
            selector: "h2"
            join_as: "string"
            source: "html"

          # 4. Description Section
          - action: "extract"
            field_name: "description"
            selector: "#Description .indent"
            join_as: "string"
            source: "html"

          # 5. Likelihood Of Attack
          - action: "extract"
            field_name: "likelihood_of_attack"
            selector: "#Likelihood_Of_Attack .detail"
            join_as: "string"
            source: "html"

          # 6. Typical Severity
          - action: "extract"
            field_name: "typical_severity"
            selector: "#Typical_Severity .detail"
            join_as: "string"
            source: "html"

          # 7. Relationships (Array of table rows)
          - action: "extract"
            field_name: "relationships"
            selector: "#Relationships .tabledetail tr"
            join_as: "array"
            source: "html"

          # 8. Execution Flow
          - action: "extract"
            field_name: "execution_flow"
            selector: "#Execution_Flow .detail"
            join_as: "string"
            source: "html"

          # 9. Prerequisites
          - action: "extract"
            field_name: "prerequisites"
            selector: "#Prerequisites .detail tr"
            join_as: "array"
            source: "html"

          # 10. Skills Required
          - action: "extract"
            field_name: "skills_required"
            selector: "#Skills_Required .detail tr"
            join_as: "array"
            source: "html"

          # 11. Resources Required
          - action: "extract"
            field_name: "resources_required"
            selector: "#Resources_Required .detail tr"
            join_as: "array"
            source: "html"

          # 12. Mitigations
          - action: "extract"
            field_name: "mitigations"
            selector: "#Mitigations .detail tr"
            join_as: "array"
            source: "html"

          # 13. Example Instances
          - action: "extract"
            field_name: "example_instances"
            selector: "#Example_Instances .detail"
            join_as: "string"
            source: "html"

          # 14. Related Weaknesses (CWE Mappings)
          - action: "extract"
            field_name: "related_weaknesses"
            selector: "#Related_Weaknesses .tabledetail tr"
            join_as: "array"
            source: "html"

          # 15. Taxonomy Mappings
          - action: "extract"
            field_name: "taxonomy_mappings"
            selector: "#Taxonomy_Mappings .tabledetail tr"
            join_as: "array"
            source: "html"

          # 16. References
          - action: "extract"
            field_name: "references"
            selector: "#References .detail tr"
            join_as: "array"
            source: "html"

    crawl_rules:
      # Allow the seed page and any pattern definition
      - policy: allow
        type: begins
        pattern: "/data/definitions/"

      # Deny navigational noise
      - policy: deny
        type: contains
        pattern: "/history"
      - policy: deny
        type: regex
        pattern: .*

Com as configurações do rastreador definidas, executamos os seguintes comandos docker run para iniciar dois contêineres para executar o processo de rastreamento de dados em cada catálogo:

Este comando inicia o rastreador CWE.

docker run --rm \
  -v "$(pwd)":/config \
  -it docker.elastic.co/integrations/crawler:latest jruby \
  bin/crawler crawl /config/crawl-config-mitre-cwe.yml

Este comando inicia o rastreador CAPEC.

docker run --rm \
  -v "$(pwd)":/config \
  -it docker.elastic.co/integrations/crawler:latest jruby \
  bin/crawler crawl /config/crawl-config-mitre-capec-software.yml

Agora que ambos os contêineres foram executados com sucesso, podemos ver que eles rastrearam as páginas da web e indexaram os dados CWE e CAPEC (exemplo de saída abaixo). Estamos prontos para prosseguir para a próxima etapa.

---- Crawl Stats ----
- Pages visited: 575
- URLs allowed: 574
- URLs denied
  - Already seen: 2817
  - Domain filter: 9936
- Crawl duration (seconds): 146
- Crawling time (seconds): 106.245
- Average response time (seconds): 0.18477391304347826

---- Elasticsearch Ingestion Stats ----
- Completed
  - Documents upserted: 574
  - Volume (bytes): 9626811
- Failed
  - Number of documents that failed to index: 0
  - Volume (bytes): 0

Etapa 2: Construindo o agente de IA de aconselhamento de segurança

Com os catálogos CWE e CAPEC indexados no Elasticsearch, o próximo passo foi construir um agente que pudesse utilizá-los para redigir o texto do aviso de segurança — CWE para a causa raiz e CAPEC para a metodologia de ataque. Utilizamos o Elastic Agent Builder para criar um agente personalizado usando o Claude Opus, que produziu consistentemente textos de avisos de segurança precisos e em conformidade com o modelo.

Quais ferramentas o agente do Elastic Agent Builder utiliza?

Fundamentação em dados CWE e CAPEC

Três ferramentas formam o núcleo do ciclo RAG, permitindo que o agente encontre e recupere dados de classificação confiáveis de nossos catálogos indexados:

platform.core.search — Pesquisa de texto completo e estruturada no Elasticsearch. A consulta principal ocorre quando o agente procura por entradas candidatas de CWE ou CAPEC que correspondam a uma determinada vulnerabilidade.
platform.core.get_document_by_id — recupera um documento completo por índice e ID. Uma vez que search tenha restringido os candidatos, isso extrai o registro CWE ou CAPEC completo para que o agente raciocine com base em cada campo estruturado — descrição, mitigações, exemplos observados, padrões relacionados — e não apenas em um trecho de pesquisa.
platform.core.execute_esql — executa uma consulta ES|QL e retorna resultados tabulares. Utilizado quando o agente precisa de uma filtragem mais precisa do que a pesquisa de texto completo pode oferecer.

Descoberta de índice e esquema

Duas ferramentas de descoberta de índice e esquema permitem que o agente determine quais dados estão disponíveis, em vez de depender de nomes predefinidos no prompt:

platform.core.list_indices — lista os índices, aliases e fluxos de dados aos quais o usuário atual pode acessar. Útil quando o agente precisa confirmar quais índices existem antes de construir uma consulta.
platform.core.get_index_mapping — recupera mapeamentos para um índice específico. Permite que o agente veja os campos disponíveis antes de escrever uma consulta para eles.
platform.core.index_explorer — descoberta de índices em linguagem natural. O agente pode perguntar "qual índice contém o catálogo CWE?" e obter uma lista classificada com mapeamentos, sem que isso esteja embutido no prompt.

Contexto específico do produto

Quando o agente preenche as seções Configurações Afetadas e Soluções e Mitigações do aviso, ele precisa verificar os valores padrão dos recursos e o comportamento específico da implantação em fontes oficiais, em vez de fazer suposições:

platform.core.product_documentation — pesquisa a documentação de produtos da Elastic em toda a sua pilha.
code.search_kibana_code, code.search_kibana_documentation e code.fetch_kibana_documentation — acesso à fonte e à documentação específicas do Kibana, exercido quando o aviso envolve o Kibana. Isso dá ao agente acesso ao código em si, e não apenas à documentação publicada, o que é importante para confirmar comportamentos sutis que a documentação nem sempre explica.

capacidades de recuperação de contingência

documentation.tavily_extract — uma proteção defensiva que busca diretamente a página canônica do MITRE. Com a indexação contínua em funcionamento, os catálogos indexados permanecem atualizados, portanto, esse erro raramente ocorre; ele serve para garantir que o agente não seja bloqueado.

As ferramentas não são chamadas em uma ordem aleatória. O prompt instrui o agente a esgotar primeiro o catálogo indexado — platform.core.search para encontrar candidatos, depois platform.core.get_document_by_id para recuperar o registro completo, antes de recorrer à ferramenta de recuperação externa. Essa ordem é importante: ela impede que o agente substitua silenciosamente conteúdo externo não verificado por dados que definimos explicitamente como base.

Como ajustamos o prompt do sistema para gerar recomendações precisas

A maior parte das iterações ocorreu na própria pergunta inicial. Diversos comportamentos que implementamos merecem destaque, pois cada um deles surgiu de algo que observamos o agente fazer e que não queríamos que se repetisse:

Verificação de segurança da memória. Logo no início dos testes, o agente sugeriu CWEs de corrupção de memória (por exemplo, CWE-119) para vulnerabilidades em nossos Beats baseados em Go, que não se aplicam a uma linguagem com segurança de memória. O prompt foi ajustado para detectar a linguagem do componente afetado e impedir CWEs e CAPECs que causam corrupção de memória sempre que a linguagem for Go, Rust, Java, TypeScript ou outro ambiente de execução com segurança de memória.
Lista de verificação de divulgação mínima. Os avisos devem descrever as vulnerabilidades sem apresentar uma prova de conceito. Uma lista de verificação no prompt examina o rascunho em busca de nomes de funções, caminhos de arquivos, caminhos de endpoints, nomes de parâmetros, números de portas e detalhes de implementação semelhantes, substituindo-os por equivalentes abstratos ("um componente interno específico", "um campo de entrada fornecido pelo usuário") antes que o rascunho seja finalizado.
CAPEC é metodologia, não consequência. O CAPEC pode ser erroneamente escolhido como um impacto ("Negação de Serviço") em vez de uma técnica de ataque ("Exaustão de Recursos"). O aviso proíbe explicitamente esse antipadrão e instrui o agente a omitir completamente o CAPEC caso nenhuma entrada descreva a metodologia com precisão — priorizando a precisão em detrimento da completude.
"Nunca pergunte, sempre produza." O agente recebe instruções para elaborar um parecer completo a partir de quaisquer informações recebidas, usando seu próprio julgamento para os campos que as informações não abrangem, em vez de retornar ao operador com perguntas para esclarecimento. O operador sempre recebe uma versão completa para revisão.
Diretrizes de pontuação CVSS. Alguns padrões de pontuação não se traduzem bem entre produtos, como por exemplo, os remetentes de logs não devem receber pontuação Attack Vector: Network a menos que a exploração exposta à internet seja explicitamente demonstrada. Os níveis de privilégio também mapeiam diretamente as funções integradas do Elastic no prompt: qualquer função autenticada, como viewer ou editor → Privilégios necessários: Baixo; funções de nível de administrador, como superuser, kibana_admin ou ingest_admin → Privilégios necessários: Alto.
Sem servidor. A Elastic Cloud Serverless aplica patches continuamente, portanto, os avisos para produtos com uma oferta Serverless contêm um bloco específico confirmando que a vulnerabilidade já havia sido corrigida antes da divulgação pública.

Tratamento de vulnerabilidades próprias e de terceiros

Nem toda vulnerabilidade é um bug próprio da Elastic. Alguns problemas estão relacionados a dependências de terceiros — ambientes de execução de linguagens, bibliotecas, pacotes transitivos. O prompt lida com ambos os casos com modelos diferentes: um caminho de primeira parte que mapeia para um par CWE + CAPEC e um caminho de dependência baseado em CWE-1395 (Dependência de Componente Vulnerável de Terceiros) que se vincula ao(s) CVE(s) upstream e ao nome da dependência. O caminho de dependência também dá ao agente acesso a documentation.tavily_search para obter contexto de aviso upstream, enquanto as vulnerabilidades de primeira parte permanecem ancoradas apenas em nossos catálogos indexados CWE/CAPEC.

O que o agente produz: rascunho de recomendações e raciocínio.

A resposta do agente é sempre composta por duas partes: a minuta do aviso de segurança e uma seção separada de Justificativa. O recurso de Raciocínio força o agente a justificar cada escolha — qual CWE foi selecionado e por quê, qual CAPEC foi selecionado (ou por que nenhum se aplicou), quais privilégios são necessários para explorar o problema e uma justificativa de uma frase para cada métrica CVSS. A Lista de Verificação de Divulgação, que omite detalhes de implementação do aviso de segurança público, não se aplica deliberadamente à seção de Justificativa, para que o revisor veja o raciocínio completo do agente, e não a versão abstrata. Isso fornece ao revisor o que ele precisa: ele lê o raciocínio, decide se a análise é sólida e, em seguida, emite a recomendação.

Gerador de Avisos de Segurança Elástico

Criamos o agente no Agent Builder e o nomeamos Elastic Security Advisory Generator, um agente personalizado com as ferramentas e o prompt descritos acima. A captura de tela abaixo mostra a configuração na interface do usuário do Agent Builder, com o modelo, as ferramentas conectadas e o prompt do sistema, tudo configurado corretamente:

O trecho abaixo é uma versão do prompt que controla o agente, adequada para publicação. Omitimos o prompt de produção completo, que contém instruções específicas de implementação e detalhes operacionais internos desnecessários para a compreensão do projeto. Para analisá-lo, consulte este repositório público do GitHub.

## ROLE & OBJECTIVE

You are the Elastic Security Advisory Generator. Your task is to classify Elastic-specific vulnerabilities against approved industry taxonomies and draft a consistent public-facing security advisory.

Your goal is to produce a concise advisory that is accurate, reviewable, and grounded in authoritative source material, while minimizing unnecessary disclosure of exploit-enabling implementation detail.

---

## CORE BEHAVIOR

Produce a complete first draft from the information available in the vulnerability report.

- Use user-provided facts when they are present.
- Use approved internal reference data and product documentation to fill in missing context.
- Use best-effort judgment for non-critical narrative fields that are not explicitly provided.
- Leave placeholders only for identifiers that may genuinely be unavailable at draft time, such as the advisory number, CVE number, or final fixed version.

---

## INTAKE

Extract as many of the following fields as possible from the report:

1. Product name
2. Advisory identifier
3. CVE identifier
4. Fixed version or release
5. Affected versions
6. Deployment or configuration context

Include a Serverless remediation note only when the affected product has a Serverless offering or when applicability has been separately confirmed.

---

## GROUNDING AND SAFETY RULES

1. Use authoritative taxonomy data and product documentation as the primary sources of truth.
2. Prefer grounded retrieval over model inference when choosing weakness and attack-pattern classifications.
3. Keep the public advisory focused on what the issue is, who is affected, and how customers should respond.
4. Remove or generalize details that would make exploitation easier, including specific internal component names, file paths, endpoint paths, parameter names, port numbers, stack traces, and infrastructure identifiers.
5. For dependency vulnerabilities, include upstream dependency and CVE context only when that information is necessary to explain exposure.

---

## CLASSIFICATION GUARDRAILS

Before selecting taxonomy entries, identify the likely implementation language of the affected component.

- If the component is implemented in a memory-safe language, avoid memory-corruption classifications unless the report clearly indicates native-code involvement or low-level memory-corruption behavior.
- Select weakness classifications based on root cause.
- Select attack-pattern classifications based on methodology, not impact.
- If no attack-pattern entry accurately describes the method, omit it rather than forcing a weak match.

---

## MITIGATIONS AND SEVERITY

- Confirm affected configurations, deployment defaults, and workaround viability against product documentation before stating them.
- Distinguish between self-managed and hosted or managed deployment guidance when the mitigations differ.
- Produce only a draft CVSS assessment and justify each metric from the report details rather than from the vulnerability label alone.

---

## OUTPUT FORMAT

Return two clearly separated sections:

1. The Advisory
  - Subject line
  - One-line summary
  - Affected versions
  - Affected configurations
  - Solutions and mitigations
  - Indicators of compromise, when applicable
  - Serverless note, when applicable
  - Severity, CVE, problem type, and impact

2. Reasoning
  - Language assessment and safety guardrails applied
  - Rationale for selected taxonomy entries
  - Privilege assumptions
  - Draft CVSS metric reasoning

The public-facing advisory should stay high level. The Reasoning section may retain the additional context needed for internal validation.

O resultado: versões preliminares de recomendações sobre CVE mais rápidas e consistentes.

Para usar o agente, pegamos um relatório de segurança (normalmente do nosso programa de recompensas por bugs) e colamos o conteúdo na janela de conversa do Construtor de Agentes. Esse conteúdo geralmente é de formato livre: uma descrição da vulnerabilidade, o componente e a versão afetados, as etapas de reprodução e a visão do pesquisador sobre o impacto.

O agente executa o RAG (Análise de Risco e Garantia) nos índices CWE e CAPEC, aplica as regras e diretrizes indicadas no prompt e produz a saída em duas partes descrita acima: um rascunho de aviso de segurança e uma seção de Justificativa explicando suas escolhas.

Antes que a versão preliminar seja encaminhada para publicação, o revisor de Segurança do Produto realiza uma breve verificação de validação:

Confirme as seleções da CWE e da CAPEC em relação à MITRE. A seção de Justificativa lista as opções escolhidas e explica o porquê. O revisor verifica se cada ID corresponde à entrada oficial da MITRE e se a seleção está de acordo com a vulnerabilidade real.
Verifique a coerência do raciocínio por trás da métrica CVSS. O Raciocínio apresenta uma justificativa de uma frase para cada métrica. O revisor questiona tudo o que não decorre do relatório.
Verifique se há compartilhamento excessivo ou insuficiente. A lista de verificação de divulgação remove os detalhes de implementação e os substitui por uma linguagem abstrata. O revisor examina o Parecer em busca de detalhes específicos que possam ter passado despercebidos, bem como de qualquer elemento que devesse ser incluído, mas não foi. O parágrafo deve ser suficiente para entender a questão, sem ser uma prova de conceito.
Verifique as seções Configurações Afetadas e Mitigações. O agente lê a documentação do produto para formular as seções "Configurações Afetadas" e "Mitigações". Essas seções são encaminhadas para a equipe de engenharia responsável pelo produto para verificação antes da publicação do aviso — somente eles possuem informações confiáveis sobre os valores padrão dos recursos e se uma solução alternativa apresentada realmente funciona nas versões afetadas.

A pontuação CVSS é explicitamente rotulada como "rascunho" na saída do agente — a equipe de Engenharia responsável pelo produto e a equipe de Segurança da Informação do Produto aprovam a pontuação final antes da publicação. Na prática, a maioria dos rascunhos precisa de uma revisão leve em vez de uma reescrita completa; o agente acerta a estrutura, e o revisor verifica as decisões e o comportamento específico do produto.

O exemplo de saída abaixo é o que o agente produziu para o ESA-2026-01, um aviso que publicamos para o Metricbeat.

O que vem a seguir: fechando o ciclo com o Elastic Workflows.

A combinação de IA generativa com RAG em relação aos catálogos oficiais da MITRE transformou o que antes era uma tarefa manual e demorada em uma parte consistente e mais rápida do nosso processo de consultoria. O processo já está gerando versões preliminares que serão encaminhadas para produção — a ESA-2026-01, mostrada acima, é um exemplo.

A maior vantagem está na parte mais lenta do processo antigo: pegar um longo relatório de vulnerabilidades — frequentemente com qualidade variável e repleto de detalhes técnicos — e transformá-lo em um parecer conciso e preciso, com uma avaliação clara do impacto para os clientes. Essa síntese, juntamente com a modelagem CVE, o mapeamento CWE/CAPEC e o raciocínio da métrica CVSS, agora é elaborada pelo agente. O esforço da nossa equipe se concentra nas partes que exigem julgamento humano: comportamento específico do produto e avaliação de impacto.

O próximo passo é fechar o ciclo de ponta a ponta. Atualmente, o agente é acionado manualmente; um analista cola o relatório de vulnerabilidades na janela de conversa. Queremos integrar isso à própria etapa de triagem, usando algo como o Elastic Workflows: assim que uma vulnerabilidade for confirmada e aceita para divulgação, o fluxo de trabalho invoca o agente automaticamente e gera um rascunho de aviso. A partir daí, as equipes de Segurança da Informação e Engenharia colaboram em um único documento, substituindo as transferências manuais entre triagem, redação e revisão.

O que tornou isso possível foi a combinação de dados estáveis e confiáveis para fundamentar o agente e uma etapa de revisão rigorosa. Ambos importam. O mesmo padrão pode ser aplicado a qualquer tarefa de redação estruturada com um modelo de saída definido e uma fonte de dados confiável. Para saber mais sobre como criar suas próprias soluções de IA generativa com o Elastic, consulte a documentação do Elastic Agent Builder.

Do relatório de vulnerabilidade à minuta do CVE em minutos: como a Elastic automatizou os avisos de segurança com IA.