Das InfoSec Product Security Team von Elastic hat einen generativen KI-Agenten mit Elastic Agent Builder entwickelt, der vollständige CVE-Sicherheitshinweise (CWE-Klassifikation, CAPEC-Methodik, CVSS-Bewertung und Mitigation Advisors) direkt aus rohen Schwachstellenberichten erstellt. Der Agent verwendet RAG gegen die MITRE CWE und CAPEC-Kataloge, die in Elasticsearch indexiert sind, was seine Ausgabe auf autoritativen Daten stützt und halluzinierte Klassifikations-IDs verhindert. ESA-2026-01 ist bereits in Produktion als Beispiel für die Produktion, die durch diese Pipeline gegangen ist. So haben wir es gebaut.
Wie Sicherheitshinweise manuell verfasst werden (und warum sie langsam sind)
Bei Elastic verwalten wir den Lebenszyklus von Produktschwachstellen mit dem PSIRT Service Framework, das vier Stufen definiert: Entdeckung, Triage, Behebung und Offenlegung. Jede Sicherheitswarnung beginnt mit einem Schwachstellenbericht, der während der Discovery-Phase eingeht, und diese Berichte variieren stark in ihrer Qualität – sie in etwas zu übersetzen, das Kunden konsumieren können, ist zeitaufwendig. Wir entwerfen die Sicherheitswarnung während der Offenlegungsphase, vor einer geplanten Produktveröffentlichung, die die Lösung enthält. Die Warnung wird dann als Elastic Security Advisory (ESA) mit einer zugewiesenen CVE-ID im Forum Elastic Security Announcements veröffentlicht, wo jeder die offengelegten Schwachstellen und die damit verbundenen Minderungsmaßnahmen einsehen kann.
Jede Offenlegung wird auch im CVE-Programm veröffentlicht, aus dem nachgelagerte nationale und regionale Datenbanken sie automatisch aufnehmen, darunter die US National Vulnerability Database (NIST), die European Vulnerability Database (ENISA) der EU und Japan Vulnerability Notes (JPCERT/CC).
Um unsere Ergebnisse konsistent zu halten, folgen wir der Standardvorlage Common Vulnerabilities and Exposures (CVE)-Beschreibung:
[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]Der PROBLEMTYP wird durch einen Common Weakness Enumeration (CWE)-Eintrag identifiziert, und der Vektor wird mit einem Common Attack Pattern Enumeration and Classification (CAPEC)-Eintrag beschrieben.
Setzt man für jede Schwachstelle das richtige CWE und CAPEC ein, ergibt sich die Vorlage:
[Common Weakness Enumeration] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [Common Attack Pattern Enumeration and Classification]Der Großteil des manuellen Aufwands fließt darin, einen langen, oft technisch komplexen Schwachstellenbericht zu einer prägnanten, genauen Beratung mit klarer Wirkungsanalyse für Kunden zu destillieren. Die Identifizierung der korrekten CWE- und CAPEC-Klassifikationen macht den Prozess umständlich und langwierig. Hier bietet Automatisierung am meisten.
Automatisierung von Sicherheitsratschlägen mit Elastic Agent Builder und RAG
Um diesen Prozess zu optimieren, hat unser InfoSec Product Security Team eine Lösung entwickelt, die ein LLM nutzt, um automatisch die standardisierten Sätze für Sicherheitshinweise zu generieren. Diese Lösung umfasst zwei zentrale Schritte:
-
Erfassung von Schwachstellen-Kategorisierungsdaten: Halluzinationen sind ein gut dokumentierter Ausfallmodus für LLMs, die ohne autoritative Erdung arbeiten. Die OWASP Top 10 für LLM-Anwendungen (LLM09) listet sie als Top-Risiko-Kategorie auf, und sie war die ursprüngliche Motivation für Retrieval-Augmented Generation. Wir sahen es direkt in unseren frühen Experimenten: Wenn man sie bat, CWE- und CAPEC-IDs unbeaufsichtigt zuzuweisen, lieferte das Modell häufig plausibel aussehende, aber nicht existierende Einträge. Um dies zu verhindern, nutzten wir den Elastic Crawler , um die Websites CWE und CAPEC zu scrapen und die Daten in zwei Elasticsearch-Indizes einzulesen:
web-crawl-mitre-cwe-softwareundweb-crawl-mitre-capec-software. -
Aufbau des generativen KI-Agenten: Wir haben den Elastic Agent Builder verwendet, um einen benutzerdefinierten Agenten zu erstellen, der ein LLM verwendet, um den Beratungstext auf Basis der eingetragenen Daten zu generieren.
Schritt 1: Indexierung von MITRE CWE- und CAPEC-Daten in Elasticsearch
Der erste Schritt war, die CWE- und CAPEC-Daten in Elasticsearch zu bringen. Dafür haben wir eine Elastic Serverless-Instanz eingerichtet, die Verbindungsdetails notiert und einen API-Schlüssel generiert. Anschließend erstellten wir die Konfigurationen für Elastic Crawler, um die MITRE-Webseiten zu besuchen und die relevanten Informationen zu extrahieren. Die gleichen Crawler-Konfigurationen werden kontinuierlich durchgeführt, sodass die Indizes aktuell bleiben, während MITRE neue CWE- und CAPEC-Einträge veröffentlicht. Das hält die geerdeten Daten des Agenten frisch, ohne manuelles Eingreifen.
CWE Crawler-Konfiguration
Hier ist die Konfiguration für CWE-Daten, die verwendet werden, um unseren KI-Agenten in autoritativen Schwachstellendaten zu verankern. Der Crawler-Seed aus der Software-Schwächenansicht von CWE folgt Links, die dem /data/definitions/ -Muster entsprechen, und extrahiert strukturierte Felder von jeder Schwächenseite, einschließlich Beschreibungen, Abmilderungen, Konsequenzen und beobachteten Beispielen, die für semantische Suche oder RAG-Pipelines bereit sind.
# 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-Crawler-Konfiguration
Wir wenden denselben Ansatz für den MITRE CAPEC-Katalog an, indem wir aus der Software-Angriffsmusteransicht Seeding und strukturierte Felder aus jeder Musterseite extrahieren, einschließlich Angriffsbeschreibungen, Ausführungsablauf, Voraussetzungen, erforderlichen Fähigkeiten und Minderungsmaßnahmen, die alle zusammen mit den CWE-Daten in Elasticsearch indiziert sind.
# 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: .*Nachdem die Crawler-Konfigurationen eingerichtet waren, führten wir dann folgende docker run Befehle aus, um zwei Container zu initiieren, die den Datencrawling-Prozess in jedem Katalog ausführen:
Dieser Befehl startet den CWE Crawler.
docker run --rm \
-v "$(pwd)":/config \
-it docker.elastic.co/integrations/crawler:latest jruby \
bin/crawler crawl /config/crawl-config-mitre-cwe.ymlDieser Befehl startet den CAPEC-Krabbler.
docker run --rm \
-v "$(pwd)":/config \
-it docker.elastic.co/integrations/crawler:latest jruby \
bin/crawler crawl /config/crawl-config-mitre-capec-software.ymlDa beide Container nun erfolgreich ausgeführt wurden, sehen wir, dass sie die Webseiten gecrawlt und sowohl die CWE- als auch die CAPEC-Daten indexiert haben (Beispielausgabe unten). Wir sind bereit, zum nächsten Schritt überzugehen.
---- 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): 0Schritt 2: Aufbau des sicherheitsberatenden KI-Agenten
Mit den in Elasticsearch indexierten CWE- und CAPEC-Katalogen bestand der nächste Schritt darin, einen Agenten zu erstellen, der auf diese zurückgreifen konnte, um den Sicherheitsratschlag zu entwerfen – CWE als Ursache, CAPEC für die Angriffsmethodik. Wir haben den Elastic Agent Builder genutzt, um mit Claude Opus einen individuellen Agenten zu erstellen, der durchgehend genaue Sicherheitshinweise und Vorlageneinhaltung lieferte.
Welche Werkzeuge verwendet der Elastic Agent Builder Agent
Verankerung in CWE- und CAPEC-Daten
Drei Werkzeuge bilden den Kern der RAG-Schleife und ermöglichen es dem Agenten, autoritative Klassifikationsdaten aus unseren indexierten Katalogen zu finden und abzurufen:
-
platform.core.search— Elasticsearch Volltext und strukturierte Suche. Die primäre Suche, wenn der Agent nach Kandidaten-CLE- oder CAPEC-Einträgen sucht, die einer gegebenen Schwachstelle entsprechen. -
platform.core.get_document_by_id— ruft ein vollständiges Dokument per Index und ID ab. SobaldsearchKandidaten eingegrenzt hat, zieht dies den vollständigen CWE- oder CAPEC-Datensatz, sodass der Agent gegen jedes strukturierte Feld – Beschreibung, Abmilderungen, beobachtete Beispiele, verwandte Muster – und nicht nur einen Suchschnipsel argumentiert. -
platform.core.execute_esql— führt ein ES| ausQL-Abfrage und liefert tabellarische Ergebnisse zurück. Wird verwendet, wenn der Agent eine präzisere Filterung benötigt, als die Volltextsuche bieten kann.
Index- und Schema-Entdeckung
Zwei Index- und Schema-Discovery-Tools ermöglichen es dem Agenten herauszufinden, welche Daten verfügbar sind, anstatt sich auf fest kodierte Namen im Prompt zu verlassen:
-
platform.core.list_indices— listet die Indizes, Aliase und Datenströme auf, auf die der aktuelle Benutzer zugreifen kann. Nützlich, wenn der Agent bestätigen muss, welche Indizes existieren, bevor er eine Abfrage erstellt. -
platform.core.get_index_mapping— ruft Abbildungen für einen bestimmten Index ab. So kann der Agent die verfügbaren Felder sehen, bevor er eine Abfrage darauf schreibt. -
platform.core.index_explorer— Entdeckung des natürlichen Sprachindexes. Der Agent kann fragen: "Welcher Index enthält den CWE-Katalog?" Und bekomme eine Rangliste mit Mappings zurück, ohne dass diese in die Eingabeaufforderung eingearbeitet ist.
Produktspezifischer Kontext
Wenn der Agent die Bereiche Betroffene Konfigurationen sowie Lösungen und Mitigationen der Warnung ausfüllt, muss er die Standardfunktionen und das bereitstellungsspezifische Verhalten mit autoritativen Quellen überprüfen, anstatt zu raten:
-
platform.core.product_documentation— durchsucht die Elastic-Produktdokumentation im gesamten Stack. -
code.search_kibana_code,code.search_kibana_documentation, undcode.fetch_kibana_documentation— Kibana-spezifischer Quell- und Dokumentenzugriff, der genutzt wird, wenn die Warnung Kibana betrifft. Diese geben dem Agenten Zugriff auf den Code selbst, nicht nur auf die veröffentlichten Dokumente, was wichtig ist, um subtile Verhaltensweisen zu bestätigen, die die Dokumentation nicht immer ausspricht.
Rückzugsfähigkeiten zur Rückholung
documentation.tavily_extract– ein defensiver Backstop, der direkt die kanonische MITRE-Seite abholt. Mit kontinuierlichem Kriechen bleiben die indexierten Kataloge aktuell, sodass dies selten zündet; Es ist da, um sicherzustellen, dass der Agent nicht blockiert wird.
Die Werkzeuge werden nicht in freier Reihenfolge aufgerufen. Der Prompt weist den Agenten an, zuerst den indexierten Katalog auszuschöpfen – platform.core.search Kandidaten zu finden, dann platform.core.get_document_by_id , den vollständigen Datensatz abzurufen, bevor er auf das externe Abrufwerkzeug zurückgreift. Diese Reihenfolge ist entscheidend: Sie verhindert, dass der Agent unverifizierte externe Inhalte stillschweigend durch Daten ersetzt, gegen die wir uns explizit gestützt haben.
Wie wir den Systemprompt für eine genaue Ratgebung abgestimmt haben
Der Prompt selbst ist der Ort, an den der Großteil der Iteration geführt wurde. Mehrere Verhaltensweisen, die wir eingebaut haben, sind hervorzuheben, denn jedes davon stammt aus etwas, das wir beim Agenten gesehen haben und das wir nicht wiederholen wollten:
-
Speichersicherheitsverifikation. Früh im Test schlug der Agent Speicherbeschädigungs-CWEs (z. B. CWE-119) für Schwachstellen in unseren Go-basierten Beats vor, die in einer speichersicheren Sprache nicht gelten. Die Eingabeaufforderung wurde so abgestimmt, dass sie nun die Sprache der betroffenen Komponente erkennt und Speicherbeschädigungs-CWEs und CAPECs verbietet, wann immer die Sprache Go, Rust, Java, TypeScript oder eine andere speichersichere Laufzeit ist.
-
Checkliste für minimale Offenlegung. Advisories sollten Schwachstellen beschreiben, ohne einen Proof-of-Concept vorzulegen. Eine Checkliste im Prompt durchsucht den Entwurf nach Funktionsnamen, Dateipfaden, Endpunktpfaden, Parameternamen, Portnummern und ähnlichen Implementierungsdetails und ersetzt sie durch abstrakte Äquivalente ("eine spezifische interne Komponente", "ein vom Benutzer bereitgestelltes Eingabefeld"), bevor der Entwurf fertiggestellt wird.
-
CAPEC ist Methodik, nicht Konsequenz. CAPEC kann fälschlicherweise als Impact ("Denial of Service") statt als Angriffstechnik ("Resource Exhaustion") gewählt werden. Der Prompt verbietet dieses Anti-Pattern ausdrücklich und fordert den Agenten auf, den CAPEC vollständig wegzulassen, wenn kein Eintrag die Methodik genau beschreibt – Genauigkeit statt Vollständigkeit.
-
"Nie fragen, immer produzieren." Der Agent wird angewiesen, eine vollständige Warnung aus den erhaltenen Eingaben zu verfassen und dabei sein eigenes Urteil für Felder zu verwenden, die die Eingabe nicht abdeckt, anstatt mit klärenden Fragen an den Bediener zurückzukehren. Der Betreiber bekommt immer einen vollständigen Entwurf zur Prüfung.
-
CVSS erzielt Leitplanken. Manche Wertungsmuster lassen sich nicht gut über Produkte hinweg übertragen, wie zum Beispiel sollten Loglieferanten nicht bewertet werden,
Attack Vector: Networkes sei denn, es wird explizit internetbezogene Ausnutzung nachgewiesen. Privilegienstufen werden auch direkt auf die eingebauten Rollen von Elastic im Prompt abgebildet: jede authentifizierte Rolle wieviewerodereditor→ Erforderliche Privilegien: Niedrig; Admin-Rollen wiesuperuser,kibana_adminoderingest_admin→ erforderliche Privilegien: Hoch. -
Serverlos. Elastic Cloud Serverless patcht kontinuierlich, sodass Hinweise für Produkte mit einem Serverless-Angebot eine bestimmte Sperre enthalten, die bestätigt, dass die Schwachstelle dort bereits vor der Veröffentlichung behoben wurde.
Umgang mit First-Party- und Third-Party-Schwachstellen
Nicht jede Schwachstelle ist ein First-Party-Elastic-Bug. Einige sind Probleme in Drittanbieterabhängigkeiten – Sprachlaufzeiten, Bibliotheken, transitiven Paketen. Der Prompt behandelt beide Fälle mit unterschiedlichen Vorlagen: einen First-Party-Pfad, der auf ein CWE + CAPEC-Paar abgebildet ist, und einen Abhängigkeitspfad, der auf CWE-1395 (Dependency on Vulnerable Third-Party Component) basiert und mit den vorgelagerten CVE(s) und dem Abhängigkeitsnamen verknüpft. Der Abhängigkeitspfad verschafft dem Agenten außerdem Zugang zu documentation.tavily_search , um den Upstream-Beratungskontext abzurufen, während First-Party-Schwachstellen nur in unseren indexierten CWE/CAPEC-Katalogen verankert bleiben.
Was der Agent ausgibt: Entwurf von Beratung und Argumentation
Die Antwort des Agenten besteht immer aus zwei Teilen: dem Entwurf eines Sicherheitshinweises und einem separaten Abschnitt zum Argumentieren. Das Reasoning zwingt den Agenten, jede Entscheidung zu rechtfertigen – welcher CWE ausgewählt wurde und warum, welcher CAPEC ausgewählt wurde (oder warum keines anwandte), welche Privilegien erforderlich sind, um das Problem auszunutzen, und eine ein-Satz-Begründung für jede CVSS-Metrik. Die Offenlegungscheckliste, die Implementierungsdetails aus dem öffentlich zugänglichen Sicherheitshinweis entfernt, gilt absichtlich nicht für den Abschnitt Argumentation, sodass der Prüfer das vollständige Denken des Agenten sieht und nicht die abstrahierte Version. Das gibt dem Gutachter das, was er braucht: Er liest die Argumentation, entscheidet, ob die Analyse stichhaltig ist, und trifft dann die Entscheidung zum Beratungstext.
Elastischer Sicherheitsberater
Wir haben den Agent in Agent Builder erstellt und ihn Elastic Security Advisory Generator genannt, einen individuellen Agent mit den oben beschriebenen Tools und Prompt. Der untenstehende Screenshot zeigt die Konfiguration in der Agent Builder-Benutzeroberfläche, mit Modell, verkabelten Werkzeugen und Systemprompt alle vorhanden:
Der untenstehende Auszug ist eine veröffentlichungssichere Version des Prompts, der den Agenten antreibt. Wir haben den vollständigen Produktionsprompt weggelassen, der implementierungsspezifische Anweisungen und interne Betriebsdetails enthält, die nicht nötig sind, um das Design zu verstehen. Um es zu überprüfen, siehe dieses öffentliche GitHub-Repository.
## 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.Das Ergebnis: schnellere, konsistente CVE-Beratungsentwürfe
Um den Agent zu verwenden, nehmen wir einen Sicherheitsbericht (typischerweise aus unserem Bug-Bounty-Programm) und fügen den Inhalt in das Agent Builder-Gesprächsfenster ein. Dieser Inhalt ist meist frei: eine Beschreibung der Schwachstelle, die betroffene Komponente und Version, Reproduktionsschritte und die Einschätzung der Auswirkungen durch den Forscher.
Der Agent führt RAG gegen die CWE- und CAPEC-Indizes durch, wendet die Regeln und Schutzmechanismen im Prompt an und erstellt die oben beschriebenen zweiteiligen Ausgaben: einen Entwurf für Sicherheitshinweis und einen Abschnitt zum Argumentieren, der seine Entscheidungen erklärt.
Bevor der Entwurf zur Veröffentlichung vorgelegt wird, durchläuft der Product Security-Prüfer einen kurzen Validierungsdurchgang:
-
Bestätigen Sie die Auswahl von CWE und CAPEC gegen MITRE. Der Abschnitt Argumentation nennt die ausgewählten Einträge und warum. Der Prüfer überprüft, ob jede ID mit dem offiziellen MITRE-Eintrag übereinstimmt und dass die Auswahl mit der tatsächlichen Schwachstelle übereinstimmt.
-
Vernunft – überprüfe die CVSS-Metrik-Argumentation. Das Reasoning legt eine Ein-Satz-Rechtfertigung pro Metrik vor. Der Gutachter stellt alles in Frage, was nicht aus dem Bericht folgt.
-
Scanne nach Über- oder Unterteilen. Die Offenlegungscheckliste entfernt Implementierungsdetails und ersetzt sie durch abstrakte Sprache. Der Gutachter durchsucht den Advisory nach Details, die möglicherweise durchgerutscht sind, und ebenso nach allem, was enthalten sein sollte, aber nicht enthalten ist. Der Absatz sollte ausreichen, um das Thema zu verstehen, ohne ein Proof of Concept zu sein.
-
Überprüfen Sie die Abschnitte zu betroffenen Konfigurationen und Minderungsmaßnahmen. Der Mitarbeiter liest aus der Produktdokumentation, um die Abschnitte "Betroffene Konfigurationen" und "Minderungen" zu formulieren. Diese Abschnitte gehen an das Entwicklerteam, das das Produkt besitzt, zur Verifizierung vor der Veröffentlichung der Warnung – nur sie haben Wahrheit zu Funktionsfehlern und ob ein angegebener Workaround tatsächlich bei den betroffenen Releases funktioniert.
Der CVSS-Score wird im Output des Agenten ausdrücklich als Entwurf bezeichnet – das für das Produkt zuständige Engineering-Team und das InfoSec Product Security Team unterzeichnen die endgültige Bewertung vor der Veröffentlichung. In der Praxis benötigen die meisten Entwürfe leichte Überarbeitungen statt Überarbeitungen; Der Agent bekommt die Struktur richtig, und der Gutachter prüft Urteile und produktspezifisches Verhalten.
Das untenstehende Beispielergebnis zeigt das, was der Agent für ESA-2026-01 erstellt hat, eine Empfehlung, die wir für Metricbeat veröffentlicht haben.
Was als Nächstes kommt: Die Schleife mit Elastic Workflows schließen
Die Kombination generativer KI mit RAG und autoritativen MITRE-Katalogen hat aus einer früher manuellen, zeitaufwändigen Aufgabe einen konsistenten und schnelleren Teil unseres Beratungsprozesses gemacht. Die Pipeline produziert bereits Entwürfe, die in die Produktion gehen – ESA-2026-01, oben gezeigt, ist ein Beispiel.
Der größte Erfolg ist der langsamste Teil des alten Prozesses: einen langen Schwachstellenbericht – oft unterschiedlich in der Qualität und mit technischen Details reich – zu nehmen und in eine prägnante, genaue Beratung mit klarer Wirkungsanalyse für Kunden zu destillieren. Diese Zusammenfassung, zusammen mit dem CVE-Templating, CWE/CAPEC-Mapping und CVSS-Metrik-Argumentation, wird nun vom Agenten entworfen. Unser Team konzentriert sich auf die Bereiche, die menschliches Urteilsvermögen erfordern: produktspezifisches Verhalten und Impact Scoring.
Der nächste Schritt ist, die Schleife von Ende zu Ende zu schließen. Heute wird der Agent manuell aufgerufen; Ein Analyst fügt den Schwachstellenbericht in das Gesprächsfenster ein. Wir wollen dies direkt in den Triage-Schritt einbinden, zum Beispiel mit Elastic Workflows: Sobald eine Schwachstelle bestätigt und zur Offenlegung akzeptiert wurde, ruft der Workflow den Agenten automatisch auf und erstellt einen Entwurf einer Empfehlung. Von dort aus arbeiten InfoSec und Engineering gemeinsam an einem einzigen Dokument, das die manuellen Übergaben zwischen Triage, Entwurf und Überprüfung ersetzt.
Was das zum Funktionieren brachte, war die Kombination aus stabilen, autoritativen Daten, an denen der Agent gestützt wurde, und einem strengen Überprüfungsschritt. Beides ist wichtig. Das gleiche Muster kann für jede strukturierte Entwurfsaufgabe mit einer definierten Ausgabevorlage und einer vertrauenswürdigen Datenquelle gelten. Um mehr über den Aufbau eigener generativer KI-Lösungen mit Elastic zu erfahren, schauen Sie sich die Elastic Agent Builder-Dokumentation an.