Paul McCann

从漏洞报告到 CVE 草案，只需几分钟：Elastic 如何利用人工智能实现安全公告自动化

Elastic 的安全团队如何利用 RAG 针对 MITRE 的 CWE 和 CAPEC 目录构建 AI 代理，从原始漏洞报告（包括完整的提示和爬虫配置）中起草 CVE 建议。

阅读时间：11 分钟Generative AI, Enablement

Elastic 的信息安全产品安全团队使用 Elastic Agent Builder 构建了一个生成式 AI 代理，该代理直接从原始漏洞报告中生成完整的 CVE 安全公告（CWE 分类、CAPEC 方法、CVSS 评分和缓解指南）。该代理使用 RAG 对 Elasticsearch 中索引的 MITRE CWE 和 CAPEC 目录进行分类，从而使其输出基于权威数据，并防止出现虚假的分类 ID。ESA-2026-01 已投入生产，它是通过该流程产生的输出示例。以下是我们搭建它的方法。

安全公告是如何手动撰写的（以及为什么速度很慢）

在 Elastic，我们使用PSIRT 服务框架管理产品漏洞的生命周期，该框架定义了四个阶段：发现、分类、修复和披露。每份安全公告都源于发现阶段收到的漏洞报告，而这些报告的质量参差不齐——将它们转化为客户可以使用的内容非常耗时。我们在披露阶段起草安全公告，早于包含修复程序的计划产品发布。然后，该安全公告将以Elastic 安全公告 (ESA)的形式发布在Elastic 安全公告论坛上，并分配一个 CVE ID，任何人都可以查看已披露的漏洞和相关的缓解措施。

每次披露都会发布到CVE 计划中，下游国家和地区数据库会自动接收这些披露信息，包括美国国家漏洞数据库(NIST)、欧盟欧洲漏洞数据库(ENISA) 和日本日本漏洞注释(JPCERT/CC)。

为了保持输出的一致性，我们遵循标准的通用漏洞披露 (CVE) 描述模板：

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

使用通用弱点枚举(CWE) 条目识别问题类型，并使用通用攻击模式枚举和分类(CAPEC) 条目描述攻击向量。

将每个漏洞对应的 CWE 和 CAPEC 替换为正确的代码后，模板变为：

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

大部分人工工作量都花在了将冗长且技术性很强的漏洞报告提炼成简洁、准确的建议，并向客户提供清晰的影响评估。在此基础上确定正确的 CWE 和 CAPEC 分类，使得整个过程变得复杂而漫长。这正是自动化能够发挥最大作用的地方。

使用 Elastic Agent Builder 和 RAG 实现安全咨询草案的自动化

为了简化这一流程，我们的信息安全产品安全团队开发了一种解决方案，该方案使用 LLM 自动生成安全公告的标准化语句。该解决方案包含两个关键步骤：

  1. 摄入漏洞分类数据：幻觉是 LLM 在没有权威基础的情况下运行的一种有据可查的故障模式。OWASP Top 10 for LLM Applications (LLM09) 将其列为顶级风险类别，这也是检索增强生成技术的最初动机。我们在早期的实验中直接看到了这一点：当要求模型在不借助任何帮助的情况下分配 CWE 和 CAPEC ID 时，该模型经常生成看起来很合理但实际上不存在的条目。为了防止这种情况发生，我们使用Elastic Crawler抓取 CWE 和 CAPEC 网站，并将数据导入两个 Elasticsearch 索引： web-crawl-mitre-cwe-software和web-crawl-mitre-capec-software 。

  2. 构建生成式 AI 代理：我们使用Elastic Agent Builder创建了一个自定义代理，该代理使用 LLM 根据摄入的数据生成建议文本。

步骤 1：在 Elasticsearch 中建立 MITRE CWE 和 CAPEC 数据索引

第一步是将 CWE 和 CAPEC 数据导入 Elasticsearch。为此，我们启动了一个Elastic Serverless实例，记下了连接详细信息，并生成了一个 API 密钥。然后我们创建了Elastic Crawler的配置，使其能够访问 MITRE 网站并提取相关信息。相同的爬虫配置按持续计划运行，因此随着 MITRE 发布新的 CWE 和 CAPEC 条目，索引保持最新。这样可以确保代理的底层数据保持最新状态，而无需人工干预。

CWE爬虫配置

以下是用于将我们的 AI 代理与权威漏洞数据关联起来的 CWE 数据配置。爬虫程序从 CWE 的软件弱点视图中抓取种子，跟踪与/data/definitions/模式匹配的链接，并从每个弱点页面中提取结构化字段，包括描述、缓解措施、后果和观察到的示例，以便进行语义搜索或 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: .*

CAPEC 爬行器配置

我们对 MITRE CAPEC 目录采用相同的方法，从软件攻击模式视图中获取种子数据，并从每个模式页面中提取结构化字段，包括攻击描述、执行流程、先决条件、所需技能和缓解措施，所有这些都与 CWE 数据一起索引到 Elasticsearch 中。

# 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: .*

爬虫配置完成后，我们运行了以下docker run命令来启动两个容器，以便对每个目录运行数据爬取过程：

此命令启动 CWE 爬虫。

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

此命令启动 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

现在两个容器都已成功运行，我们可以看到它们已经抓取了网页并索引了 CWE 和 CAPEC 数据（示例输出如下）。我们已准备好进入下一步。

---- 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

步骤 2：构建安全咨询 AI 代理

在 Elasticsearch 中建立 CWE 和 CAPEC 目录索引后，下一步是构建一个代理，该代理可以利用这些目录来起草安全咨询文本——CWE 用于根本原因，CAPEC 用于攻击方法。我们使用Elastic Agent Builder ，利用 Claude Opus 创建了一个自定义代理，该代理能够持续生成准确的安全公告文本并符合模板要求。

Elastic Agent Builder 代理使用哪些工具

基于CWE和CAPEC数据的基础

RAG 循环的核心由三个工具构成，使代理能够从我们已索引的目录中查找和检索权威的分类数据：

  • platform.core.search — Elasticsearch 全文和结构化搜索。代理在搜索与给定漏洞匹配的候选 CWE 或 CAPEC 条目时的主要查找。

  • platform.core.get_document_by_id — 通过索引和 ID 检索完整文档。一旦search缩小了候选范围，它就会提取完整的 CWE 或 CAPEC 记录，以便代理能够针对每个结构化字段（描述、缓解措施、观察到的示例、相关模式）进行推理，而不仅仅是搜索片段。

  • platform.core.execute_esql — 执行 ES|QL 查询并返回表格结果。当代理需要比全文搜索更精确的筛选条件时，可以使用此功能。

索引和模式发现

两个索引和模式发现工具可以让代理程序自行确定哪些数据可用，而不是依赖提示信息中硬编码的名称：

  • platform.core.list_indices — 列出当前用户可以访问的索引、别名和数据流。当代理需要在构建查询之前确认存在哪些索引时，此功能非常有用。

  • platform.core.get_index_mapping — 获取特定索引的映射。允许代理在针对这些字段编写查询之前查看可用字段。

  • platform.core.index_explorer — 自然语言索引发现。代理人可以询问“哪个索引包含 CWE 目录？”并返回一个带有映射关系的排名列表，而无需将该关系嵌入到提示中。

产品特定背景

当代理程序填充安全建议的“受影响的配置”和“解决方案及缓解措施”部分时，它需要根据权威来源验证功能默认值和特定于部署的行为，而不是猜测：

  • platform.core.product_documentation — 搜索 Elastic 产品全栈文档。

  • code.search_kibana_codecode.search_kibana_documentation和code.fetch_kibana_documentation — Kibana 特有的源代码和文档访问权限，当咨询涉及 Kibana 时执行。这让代理能够访问代码本身，而不仅仅是已发布的文档，这对于确认文档中未必总是明确说明的细微行为非常重要。

备用检索能力

  • documentation.tavily_extract — 一个直接获取 MITRE 官方页面的防御性后盾。由于持续爬取功能已启用，索引目录保持最新状态，因此这种情况很少发生；它的作用是确保代理不会被阻止。

这些工具的调用顺序并非随意安排。提示指示代理首先穷尽索引目录—— platform.core.search查找候选记录，然后platform.core.get_document_by_id检索完整记录，最后才回退到外部检索工具。这种排序很重要：它可以防止代理悄悄地用未经核实的外部内容替换我们已经明确核实的数据。

我们如何调整系统提示以实现准确的建议生成

大部分迭代都耗费在了提示本身。我们内置的几种行为值得特别指出，因为每一种行为都源于我们观察到智能体做出的某些我们不希望重复的行为：

  • 内存安全验证。在测试初期，该代理针对我们基于 Go 的 Beats 中的漏洞提出了内存损坏 CWE（例如 CWE-119），但这些漏洞并不适用于内存安全的语言。提示符经过调整，现在可以检测受影响组件的语言，并且只要该语言是 Go、Rust、Java、TypeScript 或其他内存安全的运行时，就会禁止内存损坏 CWE 和 CAPEC。

  • 最低信息披露清单。安全公告应描述漏洞，而无需提供概念验证。提示中的检查清单会扫描草稿中的函数名、文件路径、端点路径、参数名、端口号和类似的实现细节，并在草稿定稿前将其替换为抽象的等效项（“特定的内部组件”、“用户提供的输入字段”）。

  • CAPEC是一种方法论，而非结果。CAPEC 可能被错误地选作一种影响（“拒绝服务”），而不是一种攻击技术（“资源耗尽”）。提示明确禁止这种反模式，并告诉代理，如果没有条目准确描述方法，则完全省略 CAPEC——准确性比完整性更重要。

  • “永远不要问，要用行动说话。”代理人被指示根据收到的任何输入起草一份完整的咨询报告，对于输入中未涵盖的领域，则运用自己的判断，而不是向操作员提出澄清问题。操作员总能收到完整的草稿进行审阅。

  • CVSS评分准则。有些评分模式在不同产品之间转换效果不佳，例如，除非明确证明存在面向互联网的攻击，否则不应给原木运输商评分Attack Vector: Network 。权限级别也直接映射到 Elastic 的内置角色：任何经过身份验证的角色，例如viewer或editor → 所需权限：低；管理员级别的角色，例如superuser 、 kibana_admin或ingest_admin → 所需权限：高。

  • 无服务器架构。Elastic Cloud Serverless 会持续进行修补，因此，对于提供 Serverless 服务的产品，其安全公告中会包含一个专门的说明，确认该漏洞在公开披露之前就已经得到修复。

处理第一方和第三方漏洞

并非所有漏洞都是 Elastic 本身的漏洞。有些问题是第三方依赖项（语言运行时、库、传递包）造成的。提示符使用不同的模板处理这两种情况：第一方路径映射到 CWE + CAPEC 对，依赖项路径以 CWE-1395（依赖于易受攻击的第三方组件）为键，链接到上游 CVE 和依赖项名称。依赖路径还允许代理访问documentation.tavily_search以获取上游建议上下文，而第一方漏洞仅存在于我们索引的 CWE/CAPEC 目录中。

代理输出：建议草案和推理过程

代理人的回应总是包含两部分：安全建议草案和单独的理由部分。推理过程迫使代理对每个选择进行辩护——选择哪个 CWE 以及为什么选择，选择哪个 CAPEC（或者为什么没有选择任何 CAPEC），利用该问题需要哪些权限，以及对每个 CVSS 指标的一句话解释。披露清单故意从面向公众的安全公告中剔除了实施细节，但并不适用于推理部分，因此审查人员可以看到代理的完整思路，而不是抽象版本。这样一来，审阅者就能获得他们所需的信息：他们阅读理由，判断分析是否合理，然后对建议文本做出决定。

弹性安全咨询生成器

我们在 Agent Builder 中构建了代理，并将其命名为Elastic Security Advisory Generator ，这是一个具有上述工具和提示的自定义代理。下面的屏幕截图显示了在代理构建器用户界面中的配置情况，其中模型、连接的工具和系统提示都已就位：

以下摘录是驱动代理的提示的可发布版本。我们省略了完整的生产提示，其中包含特定于实施的说明和内部操作细节，而这些细节对于理解设计而言并非必要。如需查看，请参阅此公开的 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.

结果：更快、更一致的 CVE 咨询草案

要使用该代理，我们需要获取一份安全报告（通常来自我们的漏洞赏金计划），并将内容粘贴到代理构建器对话窗口中。该内容通常是自由格式的：漏洞描述、受影响的组件和版本、重现步骤以及研究人员对影响的看法。

该代理对 CWE 和 CAPEC 指数执行 RAG 操作，应用提示中的规则和防护措施，并生成上述两部分输出：一份安全建议草案，以及一个解释其选择的推理部分。

在草案提交发布之前，产品安全审核员会进行一次简短的验证：

  • 确认 CWE 和 CAPEC 的评选结果是否与 MITRE 一致。“理由”部分列出了所选条目及其原因。审核员会验证每个 ID 是否与 MITRE 官方条目相符，并且所选内容是否与实际漏洞相符。

  • 对 CVSS 指标的推理进行合理性检验。理由部分对每个指标都给出了一句话的解释。审阅者会对报告中任何不合逻辑的内容提出质疑。

  • 扫描是否存在过度或不足分享的情况。信息披露清单剔除了实现细节，并用抽象语言取而代之。审阅者仔细阅读咨询报告，查找可能遗漏的具体细节，以及应该包含但尚未包含的内容。这段文字应该足以让人理解这个问题，而无需进行概念验证。

  • 核实受影响的配置和缓解措施部分。代理会阅读产品文档，以制定“受影响的配置”和“缓解措施”部分。这些部分将提交给负责该产品的工程团队进行验证，然后再发布建议——只有他们才掌握功能默认值的真实情况，以及所说明的解决方法是否真的适用于受影响的版本。

代理的输出中明确标明 CVSS 评分为草稿——负责该产品的工程团队和信息安全产品安全团队会在发布前对最终评分进行审核。实际上，大多数草稿只需要稍加编辑，而不是重写；经纪人会把结构做好，审阅者会检查判断和产品的具体表现。

下面的示例输出是代理为ESA-2026-01生成的，这是我们为 Metricbeat 发布的一份咨询报告。

下一步：利用弹性工作流实现闭环

将生成式人工智能与 RAG 结合，并参考权威的 MITRE 目录，已将过去耗时费力的手动任务转变为我们咨询流程中持续且快速的一部分。该流程已经产生了可以投入生产的草案——如上所示的ESA-2026-01就是一个例子。

最大的胜利在于旧流程中最慢的部分：将冗长的漏洞报告（通常质量参差不齐，技术细节繁多）提炼成简洁、准确的建议，并向客户提供清晰的影响评估。该提炼过程，连同 CVE 模板、CWE/CAPEC 映射和 CVSS 指标推理，现在由代理程序起草。我们团队的精力集中在需要人工判断的部分：产品特定行为和影响评分。

下一步是完成端到端的闭环流程。目前，代理程序是手动调用的；分析人员将漏洞报告粘贴到对话窗口中。我们希望将此功能集成到分类步骤本身中，使用类似Elastic Workflows 的工具：一旦确认漏洞并接受披露，工作流就会自动调用代理并生成一份建议草案。之后，信息安全和工程部门可以合作编写一份文档，取代了分类、起草和审查之间的手动交接。

这项技术之所以奏效，是因为它结合了稳定、权威的数据作为代理的依据，以及严格的审查步骤。两者都很重要。同样的模式也适用于任何具有明确输出模板和可靠数据源的结构化绘图任务。要了解有关使用 Elastic 构建您自己的生成式 AI 解决方案的更多信息，请查看Elastic Agent Builder 文档。

分享这篇文章

XFacebookLinkedInReddit