L’équipe de sécurité produit InfoSec d’Elastic a construit un agent d’IA générative utilisant Elastic Agent Builder qui rédige des avis de sécurité CVE complets (classification CWE, méthodologie CAPEC, notation CVSS et directives d’atténuation) directement à partir des rapports bruts de vulnérabilité. L’agent utilise RAG contre les catalogues MITRE CWE et CAPEC indexés dans Elasticsearch, ce qui base sa sortie sur des données faisant autorité et empêche les identifiants de classification hallucinés. ESA-2026-01 est déjà en production comme exemple de production qui a été transmise par ce pipeline. Voici comment nous l’avons construit.
Comment les avis de sécurité sont rédigés manuellement (et pourquoi c’est lent)
Chez Elastic, nous gérons le cycle de vie des vulnérabilités des produits à l’aide du PSIRT Service Framework, qui définit quatre étapes : découverte, triage, remédiation et divulgation. Chaque avis de sécurité commence par un rapport de vulnérabilité reçu lors de la phase de découverte, et la qualité de ces rapports varie considérablement — les traduire en contenus que les clients peuvent consommer prend du temps. Nous rédigeons l’avis de sécurité pendant la phase de divulgation, avant la sortie prévue du produit contenant la correction. L’avis est ensuite publié sous forme d’Avis de sécurité Elastic (ESA), avec un identifiant CVE attribué, sur le forum Annonces de sécurité Elastic , où toute personne peut examiner les vulnérabilités divulguées et les mesures d’atténuation associées.
Chaque divulgation est également publiée dans le programme CVE, d’où les bases de données nationales et régionales en aval l’intègrent automatiquement, y compris la US National Vulnerability Database (NIST), la European Vulnerability Database de l’UE (ENISA) et les Japan Vulnerability Notes (JPCERT/CC) du Japon.
Pour maintenir notre production cohérente, nous suivons le modèle standard de description des vulnérabilités et expositions communes (CVE) :
[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]Le type de problème est identifié à l’aide d’une entrée Common Weakness Enumeration (CWE), et le Vector est décrit à l’aide d’une entrée CAPEC (Common Attack Pattern Enumeration and Classification ).
En remplaçant les CWE et CAPEC corrects pour chaque vulnérabilité, le modèle devient :
[Common Weakness Enumeration] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [Common Attack Pattern Enumeration and Classification]La majeure partie de l’effort manuel est consacrée à condenser un long rapport de vulnérabilité, souvent techniquement dense, en un avis concis et précis, avec une évaluation claire de l’impact pour les clients. Identifier les bonnes classifications CWE et CAPEC en plus de cela rend le processus compliqué et long. C’est là que l’automatisation a le plus à offrir.
Automatisation des brouillons de conseils de sécurité avec Elastic Agent Builder et RAG
Pour simplifier ce processus, notre équipe de sécurité produit InfoSec a développé une solution utilisant un LLM pour générer automatiquement la phrase standardisée des avis de sécurité. Cette solution comprend deux étapes clés :
-
Ingestion des données de catégorisation des vulnérabilités : L’hallucination est un mode de défaillance bien documenté pour les LLM fonctionnant sans mise à la terre autoritaire. Le Top 10 OWASP pour les applications LLM (LLM09) le classe comme une catégorie de risque majeur, et c’était la motivation initiale pour la génération augmentée par la récupération. Nous l’avons vu directement dans nos premières expériences : lorsqu’on nous a demandé d’attribuer des identifiants CWE et CAPEC sans aide, le modèle produisait fréquemment des entrées plausibles mais inexistantes. Pour éviter cela, nous avons utilisé l’Elastic Crawler pour extraire les sites web CWE et CAPEC et intégrer les données dans deux indices Elasticsearch :
web-crawl-mitre-cwe-softwareetweb-crawl-mitre-capec-software. -
Construire l’agent d’IA générative : Nous avons utilisé Elastic Agent Builder pour créer un agent personnalisé qui utilise un LLM pour générer le texte d’avis basé sur les données ingérées.
Étape 1 : Indexation des données MITRE CWE et CAPEC dans Elasticsearch
La première étape a été d’intégrer les données CWE et CAPEC dans Elasticsearch. Pour cela, nous avons lancé une instance Elastic Serverless , noté les détails de la connexion, et généré une clé API. Nous avons ensuite créé les configurations pour Elastic Crawler afin de visiter les sites web de MITRE et d’extraire les informations pertinentes. Les mêmes configurations de crawlers sont exécutées selon un calendrier continu, de sorte que les indices restent à jour lorsque MITRE publie les nouvelles entrées CWE et CAPEC. Cela permet de garder les données ancrées de l’agent fraîches sans intervention manuelle.
Configuration du crawler CWE
Voici la configuration des données CWE utilisées pour ancrer notre agent IA dans des données de vulnérabilités faisant autorité. Le robot d’exploration partit de la vue des faiblesses logicielles de CWE, suit les liens correspondant au schéma /data/definitions/ , et extrait des champs structurés de chaque page de faiblesse, incluant descriptions, atténuations, conséquences et exemples observés prêts à être recherchés sémantique 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: .*Configuration du crawler CAPEC
Nous appliquons la même approche pour le catalogue MITRE CAPEC, en semant à partir de la vue des patterns d’attaque logiciels et en extrayant des champs structurés de chaque page de pattern, incluant les descriptions d’attaque, le flux d’exécution, les prérequis, les compétences requises et les mitigations, le tout indexé dans Elasticsearch aux côtés des données 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: .*Une fois les configurations du crawler configurées, nous avons ensuite exécuté les commandes docker run suivantes pour initier deux conteneurs afin d’exécuter le processus d’exploration des données sur chaque catalogue :
Cette commande lance le rampeur CWE.
docker run --rm \
-v "$(pwd)":/config \
-it docker.elastic.co/integrations/crawler:latest jruby \
bin/crawler crawl /config/crawl-config-mitre-cwe.ymlCette commande lance le crawler CAPEC.
docker run --rm \
-v "$(pwd)":/config \
-it docker.elastic.co/integrations/crawler:latest jruby \
bin/crawler crawl /config/crawl-config-mitre-capec-software.ymlMaintenant que les deux conteneurs ont réussi à fonctionner, on peut voir qu’ils ont exploré les pages web et indexé à la fois les données CWE et CAPEC (exemple de résultat ci-dessous). Nous sommes prêts à passer à l’étape suivante.
---- 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Étape 2 : Création de l’agent IA de conseil de sécurité
Avec les catalogues CWE et CAPEC indexés dans Elasticsearch, l’étape suivante a été de construire un agent capable de s’en servir pour rédiger le texte de l’avis de sécurité — CWE pour la cause principale, CAPEC pour la méthodologie d’attaque. Nous avons utilisé Elastic Agent Builder pour créer un agent personnalisé avec Claude Opus, qui produisait systématiquement un texte précis de consigne de sécurité et une adhésion aux modèles.
Quels outils utilise Elastic Agent Builder Agent Agent
Mise à la terre dans les données CWE et CAPEC
Trois outils forment le cœur de la boucle RAG, permettant à l’agent de trouver et de récupérer des données de classification faisant autorité à partir de nos catalogues indexés :
-
platform.core.search— Elasticsearch en texte intégral et recherche structurée. La recherche principale lorsque l’agent recherche des entrées candidates CWE ou CAPEC correspondant à une vulnérabilité donnée. -
platform.core.get_document_by_id— récupère un document complet par index et identifiant. Une foissearcha réduit les candidats, cela extrait l’enregistrement CWE ou CAPEC complet afin que l’agent ne raisonne pas sur chaque champ structuré — description, atténuations, exemples observés, schémas apparentés — et pas seulement un extrait de recherche. -
platform.core.execute_esql— exécute un ES|Requête QL et renvoie les résultats tabulaires. Utilisé lorsque l’agent a besoin d’un filtrage plus précis que ce que la recherche en texte intégral peut offrir.
Découverte d’index et de schéma
Deux outils de découverte d’index et de schéma permettent à l’agent de déterminer quelles données sont disponibles plutôt que de se fier à des noms codés en dur dans la demande :
-
platform.core.list_indices— liste les indices, alias et flux de données auxquels l’utilisateur actuel peut accéder. Utile lorsque l’agent doit confirmer quels indices existent avant de construire une requête. -
platform.core.get_index_mapping— récupère les correspondances pour un index spécifique. Permet à l’agent de voir les champs disponibles avant d’écrire une requête sur lui. -
platform.core.index_explorer— découverte d’index en langage naturel. L’agent peut demander « quel index contient le catalogue CWE ? » et obtenir une liste classée avec des mappages, sans que cela soit intégré dans la consigne.
Contexte spécifique au produit
Lorsque l’agent remplit les sections Configurations et Solutions et Mitigations affectées de l’avis, il doit vérifier les paramètres par défaut des fonctionnalités et le comportement spécifique au déploiement par des sources autoritaires plutôt que de deviner :
-
platform.core.product_documentation— recherche dans la documentation produit Elastic à travers la pile. -
code.search_kibana_code,code.search_kibana_documentation, etcode.fetch_kibana_documentation— Accès à la source et à la documentation spécifique à Kibana, exercé lorsque l’avis concerne Kibana. Cela donne à l’agent accès au code lui-même, pas seulement aux documents publiés, ce qui est important pour confirmer des comportements subtils que la documentation ne précise pas toujours.
Capacités de récupération de secours
documentation.tavily_extract— un défenseur qui récupère directement la page canonique de MITRE. Avec un crawling continu en place, les catalogues indexés restent à jour, ce qui déclenche rarement ; Il est là pour s’assurer que l’agent n’est pas bloqué.
Les outils ne sont pas appelés dans un ordre libre. L’invite demande à l’agent d’épuiser d’abord le catalogue indexé — platform.core.search pour trouver les candidats, puis platform.core.get_document_by_id pour récupérer l’enregistrement complet, avant de revenir à l’outil de récupération externe. Cet ordre est important : il empêche l’agent de substituer silencieusement du contenu externe non vérifié par des données contre lesquelles nous avons explicitement mis en terre.
Comment nous avons ajusté la consigne système pour une génération précise des conseils
Le prompt lui-même est là où la plupart de l’itération s’est déroulée. Plusieurs comportements que nous avons intégrés méritent d’être signalés, car chacun vient de quelque chose que nous avons vu l’agent faire et que nous ne voulions pas voir se répéter :
-
Vérification de la sécurité de la mémoire. Au début des tests, l’agent a suggéré des CWEs de corruption de mémoire (par exemple, CWE-119) pour des vulnérabilités dans nos Beats basés sur Go, qui ne s’appliquent pas dans un langage sûr de mémoire. L’invite a été réglée pour détecter désormais le langage du composant concerné et interdire les CWE et CAPEC de corruption mémoire lorsque le langage est Go, Rust, Java, TypeScript ou un autre environnement d’exécution sûr en mémoire.
-
Liste de contrôle minimale pour la divulgation. Les avis doivent décrire les vulnérabilités sans produire de preuve de concept. Une liste de contrôle dans l’invite scanne le brouillon à la recherche de noms de fonctions, chemins de fichiers, chemins de terminaison, noms de paramètres, numéros de port et détails d’implémentation similaires, les remplaçant par des équivalents abstraits (« un composant interne spécifique », « un champ d’entrée fourni par l’utilisateur ») avant que le brouillon ne soit finalisé.
-
Le CAPEC est une méthodologie, pas une conséquence. Le CAPEC peut être mal choisi comme une technique d’impact (« Refus de Service ») plutôt qu’une technique d’attaque (« Épuisement des ressources »). L’invite interdit explicitement cet anti-motif et demande à l’agent d’omettre complètement le CAPEC si aucune entrée ne décrit précisément la méthodologie — la précision plutôt que la complétude.
-
« Ne jamais demander, toujours produire. » L’agent est chargé de rédiger un avis complet à partir des informations reçues, en utilisant son propre jugement pour les domaines que l’entrée ne couvre pas, plutôt que de revenir à l’opérateur avec des questions de clarification. L’opérateur reçoit toujours un brouillon complet à examiner.
-
Des garde-fous de pointage CVSS. Certains schémas de notation ne se traduisent pas bien entre les produits, comme les expédiateurs de logs ne devraient pas être notés
Attack Vector: Networkà moins que l’exploitation en ligne ne soit explicitement démontrée. Les niveaux de privilèges correspondent également directement aux rôles intégrés d’Elastic dans l’invite : tout rôle authentifié tel quevieweroueditor→ Privilèges requis : Faible ; des rôles administratifs tels quesuperuser,kibana_adminouingest_admin→ Privilèges requis : Élevé. -
Sans serveur. Elastic Cloud Serverless applique des patchs continus, de sorte que les avis pour les produits proposant une offre Serverless comportent un blocage spécifique confirmant que la vulnérabilité a déjà été corrigée avant la divulgation publique.
Gestion des vulnérabilités de première et de tierce partie
Toutes les vulnérabilités ne sont pas des bugs Elastic de première partie. Certains sont des problèmes liés aux dépendances tierces — environnements d’exécution du langage, bibliothèques, paquets transitifs. L’invite gère les deux cas avec des modèles différents : un chemin de première partie qui correspond à une paire CWE + CAPEC, et un chemin de dépendance basé sur CWE-1395 (Dependance sur un composant tiers vulnérable) qui relie le(s) CVE(s) en amont et le nom de la dépendance. Le chemin de dépendance donne également à l’agent accès à documentation.tavily_search pour consulter le contexte de conseil en amont, tandis que les vulnérabilités de première partie restent ancrées uniquement dans nos catalogues indexés CWE/CAPEC.
Ce que l’agent produit : rédige-conseil et raisonnement
La réponse de l’agent se compose toujours de deux parties : le projet d’avis de sécurité et une section distincte sur le raisonnement. Le raisonnement oblige l’agent à justifier chaque choix — quel CWE a été sélectionné et pourquoi, quel CAPEC a été choisi (ou pourquoi aucun ne s’appliquait), quels privilèges sont nécessaires pour exploiter le problème, et une justification en une phrase pour chaque métrique CVSS. La Liste de contrôle de divulgation qui retire les détails de la mise en œuvre de l’avis de sécurité public ne s’applique délibérément pas à la section Raisonnement, afin que le relecteur voie la réflexion complète de l’agent, et non la version abstraite. Cela donne au critique ce dont il a besoin : il lit le raisonnement, décide si l’analyse est solide, puis prend la décision sur le texte de conseil.
Générateur d’avis de sécurité élastique
Nous avons construit l’agent dans Agent Builder et l’avons nommé Elastic Security Advisory Generator, un agent personnalisé avec les outils et la demande décrits ci-dessus. La capture d’écran ci-dessous montre qu’il est configuré dans l’interface Agent Builder, avec le modèle, les outils connectés et l’invite système tous en place :
L’extrait ci-dessous est une version sûre à publier de la consigne qui anime l’agent. Nous avons omis la demande de production complète, qui contient des instructions spécifiques à l’implémentation et des détails opérationnels internes non nécessaires pour comprendre la conception. Pour la consulter, consultez ce dépôt public sur 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.Le résultat : des brouillons de conseil CVE plus rapides et cohérents
Pour utiliser l’agent, nous prenons un rapport de sécurité (généralement de notre programme de bug bounty) et collons le contenu dans la fenêtre de conversation du Constructeur d’Agents. Ce contenu est généralement libre : une description de la vulnérabilité, le composant et la version concernés, les étapes de reproduction, et la vision du chercheur sur l’impact.
L’agent effectue le RAG par rapport aux indices CWE et CAPEC, applique les règles et les garde-fous de la consigne, et produit la sortie en deux parties décrite ci-dessus : un projet d’avis de sécurité et une section Raisonnement expliquant ses choix.
Avant que le projet ne soit soumis à la publication, le relecteur de la sécurité produit effectue un court passage de validation :
-
Confirmez les sélections CWE et CAPEC contre MITRE. La section Raisonnement indique les entrées choisies et pourquoi. Le relecteur vérifie que chaque ID correspond à l’entrée officielle MITRE et que la sélection correspond à la vulnérabilité réelle.
-
Vérifiez la raison du raisonnement de la métrique CVSS. Le raisonnement expose une justification en une phrase par mesure. Le critique conteste tout ce qui ne découle pas du rapport.
-
Scannez pour voir s’il y a un surplus ou un sous-partage. La liste de contrôle de divulgation retire les détails de l’implémentation et les remplace par un langage abstrait. Le relecteur scanne l’avis à la recherche de détails qui ont pu passer inaperçus, ainsi que tout ce qui devrait être inclus mais qui ne l’a pas été. Le paragraphe doit suffire à comprendre le problème sans servir de preuve de concept.
-
Vérifiez les configurations et les sections d’atténuation affectées. L’agent lit la documentation produit pour formuler les sections « Configurations affectées » et « Mitigations ». Ces sections sont transmises à l’équipe d’ingénierie qui possède le produit pour vérification avant la publication de l’avis — mais elles disposent de la véracité sur les défauts de fonctionnalités et sur la conformité d’une solution de contournement indiquée sur les versions concernées.
Le score CVSS est explicitement indiqué brouillon dans la sortie de l’agent — l’équipe d’ingénierie responsable du produit et l’équipe Sécurité Produit InfoSec approuvent le score final avant publication. En pratique, la plupart des brouillons nécessitent une relecture légère plutôt qu’une réécriture ; L’agent maîtrise la bonne structure, et le relecteur vérifie les jugements et le comportement spécifique au produit.
L’exemple de résultats ci-dessous est celui produit par l’agent pour ESA-2026-01, un avis que nous avons publié pour Metricbeat.
Et ensuite : boucler la boucle avec les flux de travail élastiques
Combiner l’IA générative avec le RAG face à des catalogues MITRE autoritaires a transformé ce qui était autrefois une tâche manuelle et chronophage en une partie cohérente et rapide de notre processus de conseil. Le pipeline produit déjà des projets qui passent en production — ESA-2026-01, illustré ci-dessus, en est un exemple.
La plus grande réussite est la partie la plus lente de l’ancien processus : prendre un long rapport de vulnérabilité — souvent de qualité variable et riche en détails techniques — et le distiller en un conseil concis et précis, avec une évaluation claire de l’impact pour les clients. Cette distillation, ainsi que le templage CVE, la cartographie CWE/CAPEC et le raisonnement métrique CVSS, est désormais rédigée par l’agent. L’effort de notre équipe se concentre sur les parties qui nécessitent un jugement humain : le comportement spécifique au produit et l’impact score.
L’étape suivante consiste à refermer la boucle de bout en bout. Aujourd’hui, l’agent est invoqué manuellement ; Un analyste colle le rapport de vulnérabilité dans la fenêtre de conversation. Nous voulons intégrer cela directement à l’étape de triage, en utilisant quelque chose comme les flux de travail élastiques: une fois qu’une vulnérabilité est confirmée et acceptée pour divulgation, le flux de travail invoque automatiquement l’agent et produit un brouillon d’avis. À partir de là, la Sécurité de l’Info et l’Ingénierie collaborent sur un seul document, remplaçant les transferts manuels entre triage, rédaction et révision.
Ce qui a fait fonctionner ce rôle, c’est la combinaison de données stables et autoritaires pour ancrer l’agent et une étape de revue stricte. Les deux comptent. Le même schéma peut s’appliquer à toute tâche de rédaction structurée avec un modèle de sortie défini et une source de données fiable. Pour en savoir plus sur la création de vos propres solutions d’IA générative avec Elastic, consultez la documentation Elastic Agent Builder.