Elastic의 정보 보안 제품 보안 팀은 Elastic Agent Builder를 사용하여 취약점 보고서 원본에서 완전한 CVE 보안 권고(CWE 분류, CAPEC 방법론, CVSS 점수 및 완화 지침)를 직접 작성하는 생성형 AI 에이전트를 구축했습니다. 이 에이전트는 Elasticsearch에 색인된 MITRE CWE 및 CAPEC 카탈로그에 대해 RAG를 사용하므로 출력 결과가 신뢰할 수 있는 데이터에 기반하고 잘못된 분류 ID가 생성되는 것을 방지합니다. ESA-2026-01은 이미 이 파이프라인을 거친 결과물의 예시로서 상용화되었습니다. 이것이 우리가 만든 방법입니다.
보안 권고문이 수동으로 작성되는 방식(그리고 작성 속도가 느린 이유)
Elastic에서는 PSIRT 서비스 프레임워크를 사용하여 제품 취약점의 수명 주기를 관리합니다. 이 프레임워크는 발견, 분류, 해결 및 공개의 네 단계로 구성됩니다. 각 보안 권고는 취약점 발견 단계에서 접수된 보고서를 기반으로 작성되며, 이러한 보고서의 품질은 매우 다양합니다. 따라서 이러한 보고서를 고객이 활용할 수 있는 형태로 변환하는 데는 많은 시간이 소요됩니다. 저희는 수정 사항이 포함된 제품 출시 예정일보다 앞서, 공개 단계에서 보안 권고문을 작성합니다. 그런 다음 해당 권고 사항은 할당된 CVE ID와 함께 Elastic Security Announcements 포럼에 Elastic Security Advisory(ESA) 로 게시되며, 누구나 공개된 취약점과 관련 완화 조치를 검토할 수 있습니다.
각각의 취약점 공개는 CVE 프로그램 에 게시되며, 이를 통해 미국 국가 취약점 데이터베이스 (NIST), 유럽 연합의 유럽 취약점 데이터베이스(ENISA), 일본의 일본 취약점 정보 (JPCERT/CC)를 포함한 하위 국가 및 지역 데이터베이스에서 자동으로 정보를 수집합니다.
일관된 결과물을 제공하기 위해 표준적인 CVE(Common Vulnerabilities and Exposures) 설명 템플릿을 따릅니다.
[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]PROBLEMTYPE은 CWE( Common Weakness Enumeration ) 항목을 사용하여 식별되고, Vector는 CAPEC( Common Attack Pattern Enumeration and Classification ) 항목을 사용하여 설명됩니다.
각 취약점에 대해 올바른 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을 사용하여 보안 권고에 대한 표준화된 문장을 자동으로 생성하는 솔루션을 개발했습니다. 이 해결책은 두 가지 핵심 단계를 포함합니다.
-
취약성 분류 데이터 수집: 환각은 권위 있는 근거 없이 작동하는 LLM에서 흔히 발생하는 실패 모드입니다. OWASP Top 10 for LLM Applications (LLM09)에서는 이를 최고 위험 범주로 나열하고 있으며, 이것이 Retrieval-Augmented Generation의 원래 동기였습니다. 초기 실험에서 이를 직접 확인했습니다. CWE 및 CAPEC ID를 자체적으로 할당하도록 요청받았을 때, 모델은 종종 그럴듯해 보이지만 실제로는 존재하지 않는 항목을 생성했습니다. 이를 방지하기 위해 Elastic Crawler를 사용하여 CWE 및 CAPEC 웹사이트를 스크랩하고 데이터를 두 개의 Elasticsearch 인덱스(
web-crawl-mitre-cwe-software및web-crawl-mitre-capec-software에 수집했습니다. -
생성형 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): 02단계: 보안 자문 AI 에이전트 구축
CWE 및 CAPEC 카탈로그가 Elasticsearch에 색인화되었으므로 다음 단계는 이를 활용하여 보안 권고문을 작성할 수 있는 에이전트를 구축하는 것이었습니다. CWE는 근본 원인을, CAPEC는 공격 방법을 나타냅니다. 저희는 Elastic Agent Builder를 사용하여 Claude Opus 기반의 맞춤형 에이전트를 생성했으며, 이를 통해 정확한 보안 권고문 작성 및 템플릿 준수를 일관되게 달성했습니다.
Elastic Agent Builder 에이전트가 사용하는 도구는 무엇입니까?
CWE 및 CAPEC 데이터에 기반한 학습
RAG 루프의 핵심은 세 가지 도구로 구성되어 있으며, 이를 통해 에이전트는 색인화된 카탈로그에서 신뢰할 수 있는 분류 데이터를 찾고 검색할 수 있습니다.
-
platform.core.search— 엘라스틱서치 전문 검색 및 구조화 검색. 에이전트가 특정 취약점과 일치하는 후보 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_code,code.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를 금지하도록 조정되었습니다.
-
최소 정보 공개 체크리스트. 보안 권고문에는 취약점을 설명해야 하지만, 개념 증명(proof-of-concept)을 제시해서는 안 됩니다. 프롬프트의 체크리스트는 초안에서 함수 이름, 파일 경로, 엔드포인트 경로, 매개변수 이름, 포트 번호 및 유사한 구현 세부 정보를 검사하고, 초안을 최종 확정하기 전에 이러한 요소들을 추상적인 표현("특정 내부 구성 요소", "사용자가 제공하는 입력 필드")으로 대체합니다.
-
CAPEC은 방법론이지 결과가 아닙니다. CAPEC는 공격 기법("자원 고갈")이 아닌 영향("서비스 거부")으로 잘못 선택될 수 있습니다. 프롬프트는 그러한 안티 패턴을 명시적으로 금지하고, 어떤 항목도 방법론을 정확하게 설명하지 않는 경우 CAPEC를 완전히 생략하도록 에이전트에게 지시합니다. 즉, 완전성보다 정확성이 우선시됩니다.
-
"묻지 말고, 항상 보여줘라." 상담원은 접수된 모든 정보를 바탕으로 완전한 자문 보고서를 작성하도록 지시받으며, 보고서에 포함되지 않은 부분은 자체 판단에 따라 보완하고, 담당자에게 추가 질문을 하는 대신 필요한 정보를 보완해야 합니다. 운영자는 항상 검토할 수 있도록 전체 초안을 받습니다.
-
CVSS 점수 산정 기준. 일부 점수 패턴은 제품 간에 잘 적용되지 않습니다. 예를 들어, 인터넷에 노출된 악용 사례가 명시적으로 입증되지 않는 한 통나무 운송 용기는
Attack Vector: Network평가되어서는 안 됩니다. 권한 수준은 프롬프트에서 Elastic의 내장 역할에 직접 매핑됩니다.viewer또는editor와 같은 인증된 역할 → 필요한 권한: 낮음;superuser,kibana_admin또는ingest_admin와 같은 관리자 수준 역할 → 필요한 권한: 높음. -
서버리스. Elastic Cloud Serverless는 지속적으로 패치가 적용되므로, 서버리스 서비스를 제공하는 제품에 대한 권고 사항에는 해당 취약점이 공개되기 전에 이미 해결되었음을 확인하는 특정 문구가 포함됩니다.
자사 및 타사 취약점 처리
모든 취약점이 엘라스틱 자체의 버그는 아닙니다. 일부 문제는 타사 종속성(언어 런타임, 라이브러리, 전이적 패키지)과 관련이 있습니다. 프롬프트는 서로 다른 템플릿을 사용하여 두 가지 경우를 모두 처리합니다. 첫 번째 템플릿은 CWE + CAPEC 쌍에 매핑되는 자체 경로이고,두 번째 템플릿은 상위 CVE 및 종속성 이름에 연결되는 CWE-1395(취약한 타사 구성 요소에 대한 종속성)를 기준으로 하는 종속성 경로입니다. 종속성 경로를 통해 에이전트는 상위 권고 컨텍스트를 가져오기 위해 documentation.tavily_search 에 액세스할 수 있으며, 1차 취약점은 색인화된 CWE/CAPEC 카탈로그에만 기반을 두고 있습니다.
에이전트 출력 내용: 초안 자문 및 추론
담당자의 답변은 항상 두 부분으로 구성됩니다. 첫 번째는 보안 권고 초안이고, 두 번째는 별도의 근거 설명 부분입니다. 추론 기능은 에이전트가 각 선택에 대한 정당성을 제시하도록 요구합니다. 즉, 어떤 CWE를 선택했는지, 그 이유는 무엇인지, 어떤 CAPEC를 선택했는지(또는 적용되지 않는 이유가 있는지), 이슈를 악용하는 데 필요한 권한은 무엇인지, 그리고 모든 CVSS 지표에 대해 한 문장으로 된 정당성을 제시해야 합니다. 공개 보안 권고에서 구현 세부 정보를 제거하는 데 사용되는 공개 체크리스트는 의도적으로 추론 섹션에는 적용되지 않으므로 검토자는 추상화된 버전이 아닌 에이전트의 전체 사고 과정을 볼 수 있습니다. 그렇게 하면 검토자는 필요한 정보를 얻을 수 있습니다. 검토자는 추론 내용을 읽고 분석이 타당한지 판단한 다음 권고문에 대한 최종 결정을 내립니다.
탄력적인 보안 권고 생성기
우리는 Agent Builder를 사용하여 에이전트를 구축하고 Elastic Security Advisory Generator 라는 이름을 지정했습니다. 이 에이전트는 위에서 설명한 도구와 프롬프트를 갖춘 사용자 지정 에이전트입니다. 아래 스크린샷은 에이전트 빌더 UI에서 모델, 연결된 도구 및 시스템 프롬프트가 모두 구성된 모습을 보여줍니다.
아래 발췌문은 에이전트를 구동하는 프롬프트의 게시 가능한 버전입니다. 설계 이해에 필요하지 않은 구현 관련 지침 및 내부 운영 세부 정보가 포함된 전체 제작 안내문을 생략했습니다. 자세한 내용을 확인하려면 이 공개 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 점수는 '초안'으로 명시적으로 표시됩니다. 제품을 담당하는 엔지니어링 팀과 정보 보안 제품 보안 팀이 최종 점수를 승인한 후에 게시됩니다. 실제로 대부분의 초안은 재작성보다는 가벼운 편집만 필요합니다. 에이전트는 구조를 제대로 잡고, 검토자는 판단력과 제품별 특성을 확인합니다.
아래 예시 출력은 Metricbeat에 대해 게시한 권고 사항인 ESA-2026-01 에 대해 에이전트가 생성한 내용입니다.
다음 단계: Elastic Workflows를 사용하여 마무리 작업 진행
생성형 AI와 RAG를 권위 있는 MITRE 카탈로그와 결합함으로써, 이전에는 수작업으로 진행해야 했던 시간 소모적인 작업을 자문 프로세스의 일관되고 빠른 부분으로 전환할 수 있었습니다. 해당 파이프라인은 이미 실제 제품으로 이어지는 초안을 생성하고 있으며, 위에 보이는 ESA-2026-01이 그 예입니다.
가장 큰 성과는 기존 프로세스에서 가장 느린 부분, 즉 품질이 제각각이고 기술적 세부 정보가 빽빽하게 담긴 장문의 취약점 보고서를 간결하고 정확한 권고 사항과 명확한 영향 평가를 고객에게 제공하는 데 있습니다. 해당 요약 정보는 CVE 템플릿, CWE/CAPEC 매핑 및 CVSS 메트릭 추론과 함께 이제 에이전트에 의해 초안이 작성됩니다. 우리 팀은 인간의 판단이 필요한 부분, 즉 제품별 동작 분석 및 영향 평가에 노력을 집중합니다.
다음 단계는 전체 과정을 마무리하는 것입니다. 현재는 에이전트를 수동으로 호출합니다. 분석가가 취약점 보고서를 대화창에 붙여넣는 방식입니다. 우리는 Elastic Workflows 와 같은 것을 사용하여 이 기능을 취약점 분류 단계 자체에 통합하려고 합니다. 즉, 취약점이 확인되고 공개가 승인되면 워크플로가 에이전트를 자동으로 호출하여 권고안 초안을 생성하는 방식입니다. 이를 통해 정보 보안팀과 엔지니어링팀은 단일 문서에서 협업하여, 문제 분류, 초안 작성 및 검토 간의 수동적인 인수인계를 대체합니다.
이 시스템이 성공할 수 있었던 이유는 에이전트의 기반이 되는 안정적이고 권위 있는 데이터와 엄격한 검토 절차가 결합되었기 때문입니다. 둘 다 중요합니다. 이와 동일한 패턴은 명확한 출력 템플릿과 신뢰할 수 있는 데이터 소스를 갖춘 모든 구조화된 초안 작성 작업에 적용될 수 있습니다. Elastic을 사용하여 자체 생성형 AI 솔루션을 구축하는 방법에 대한 자세한 내용은 Elastic Agent Builder 문서를 참조하세요.