CVE Alert Fatigue? Để AI quyết định vulnerability nào thực sự nguy hiểm

TL;DR

• Vấn đề: Q1/2025 có hơn 25,000 CVEs mới, nhưng chỉ 5.2% thực sự exploitable - security teams đang chìm trong biển alerts vô nghĩa
• Giải pháp: VEX (Vulnerability Exploitability eXchange) cung cấp context để phân biệt "có vulnerability" và "vulnerability có thể exploit được"
• Cách tiếp cận mới: NVIDIA AI Blueprint sử dụng LLM với kiến trúc Plan-and-Execute để tự động generate VEX status
• Kết quả: Giảm thời gian triage từ hours/days xuống còn seconds, với accuracy đủ tốt để làm first-pass filter

1. Khi SBOM không còn đủ

Nếu bạn đã từng nhận được một vulnerability scan report với hàng trăm CVEs đỏ lòm và tự hỏi "bắt đầu từ đâu đây?", thì bạn không đơn độc. Theo số liệu từ NIST, chỉ riêng Q1/2025 đã có hơn 25,000 CVEs mới được thêm vào database, và con số này tiếp tục tăng mỗi năm. Nhưng đây mới là phần thú vị: nghiên cứu từ Endor Labs cho thấy chỉ khoảng 5.2% trong số đó thực sự exploitable trong môi trường production thực tế.

Vấn đề nằm ở chỗ SBOM (Software Bill of Materials) chỉ trả lời được câu hỏi "có gì trong hộp?" mà không cho biết "cái đó có nguy hiểm không?". Giống như việc bạn có một danh sách tất cả các thành phần trong căn nhà, bao gồm cả con dao trong bếp, nhưng danh sách đó không cho biết con dao có đang chĩa vào ai hay không. SBOM liệt kê dependencies, versions, licenses, nhưng khi một CVE được công bố cho một library trong stack của bạn, SBOM không thể trả lời: "CVE này có thực sự affect application của mình không?"

Đây chính là lúc VEX (Vulnerability Exploitability eXchange) bước vào cuộc chơi. VEX không thay thế SBOM mà bổ sung thêm một layer context quan trọng: exploitability. Và gần đây, NVIDIA đã release một AI Blueprint khá thú vị để tự động hóa việc generate VEX documents bằng LLM, giúp security teams thoát khỏi địa ngục alert fatigue. Bài viết này sẽ đi sâu vào cách approach này hoạt động, limitations của nó, và liệu đây có phải là tương lai của vulnerability management hay không.

2. VEX 101: Layer còn thiếu trong Vulnerability Management

Từ "có vulnerability" đến "vulnerability có thể exploit"

Hãy tưởng tượng scenario này: scanner báo rằng container image của bạn có CVE-2021-44228 (Log4Shell) vì nó chứa log4j-core 2.14.1. Panic mode activated. Nhưng khoan đã, sau vài giờ investigation, bạn phát hiện ra rằng application không hề sử dụng JNDI lookup feature, và thực tế thì vulnerable code path không bao giờ được execute. CVE vẫn ở đó, nhưng nó không exploitable trong context cụ thể của bạn.

Đây chính xác là loại context mà VEX cung cấp. Một VEX document cho phép software producers (hoặc security teams) tuyên bố: "Đúng, component này có CVE đó, nhưng đây là lý do tại sao nó không affect sản phẩm của chúng tôi."

Bốn trạng thái VEX cơ bản

VEX định nghĩa bốn trạng thái chính cho mỗi vulnerability:

1. Not Affected: Vulnerability không ảnh hưởng đến product. Kèm theo justification tại sao.
2. Affected: Product bị ảnh hưởng và cần action.
3. Fixed: Vulnerability đã được fix trong version này.
4. Under Investigation: Đang điều tra, chưa có kết luận.

Chín lý do "Not Affected" theo CycloneDX

Khi status là "Not Affected", VEX yêu cầu một justification cụ thể để giải thích tại sao vulnerability không ảnh hưởng. CycloneDX định nghĩa 9 justification categories (lưu ý: vulnerable là một status riêng, không phải justification):

Ngoài ra còn có component_not_present cho trường hợp scanner báo sai hoàn toàn (component không hề tồn tại trong product).

Battle of the Formats: CycloneDX vs CSAF vs OpenVEX

Hiện tại có ba VEX formats chính đang được sử dụng:

CycloneDX VEX được tích hợp trực tiếp vào CycloneDX SBOM format (từ version 1.4+). Ưu điểm là seamless integration với existing SBOM workflows, nhưng nhược điểm là less expressive hơn CSAF cho complex scenarios.

CSAF VEX (Common Security Advisory Framework) là OASIS standard, được thiết kế cho enterprise với rich metadata và regulatory compliance. Microsoft và nhiều large vendors đang adopt format này. Nó powerful nhưng implementation complexity cao hơn đáng kể.

OpenVEX là lightweight option, pure JSON, dễ generate và consume. Phù hợp cho teams muốn start simple mà không cần full CSAF complexity.

Theo OASIS industry report gần đây, enterprises nên target CSAF cho production do expressiveness và regulatory alignment, nhưng lighter-weight formats như OpenVEX vẫn có chỗ đứng cho engineering workflows hàng ngày.

Okay, VEX nghe có vẻ hữu ích. Nhưng ai sẽ tạo ra những VEX documents này? Và quan trọng hơn, làm sao để scale khi bạn có hàng nghìn CVEs cần evaluate?

3. Tại sao Manual VEX Triage không scale

Hãy tưởng tượng bạn là security engineer tại một công ty fintech với 80 microservices. Sáng thứ Hai, bạn mở dashboard và thấy vulnerability scanner vừa chạy weekend scan: 847 new CVEs across all containers. Cà phê chưa kịp nguội, manager đã ping hỏi "critical CVEs nào cần patch tuần này?". Bạn nhìn vào list và thấy 23 CVEs được mark là "Critical" hoặc "High". Okay, manageable. Nhưng để trả lời câu hỏi "cái nào thực sự cần patch?", bạn cần investigate từng cái một.

Với CVE đầu tiên, bạn mất 45 phút để đọc advisory, grep codebase tìm vulnerable function, trace call graph, và confirm rằng function đó chỉ được gọi trong một unit test file, không bao giờ chạy trong production. Not exploitable. Bạn document findings, move on. Còn 22 CVEs nữa. Và đây mới chỉ là những cái Critical/High, chưa kể 824 Medium/Low đang chờ trong backlog.

Process triage một CVE đúng cách thường bao gồm bốn bước: đọc CVE advisory để hiểu vulnerability mechanism, trace code paths trong application để xem vulnerable function có được gọi không, kiểm tra configurations và environment để xác định exploitation prerequisites, và cuối cùng là document findings với đủ detail để audit sau này. Mỗi bước có thể mất từ 15 phút đến vài giờ tùy complexity. Nhân số này lên với 50-100 CVEs per container image, rồi nhân tiếp với số containers trong infrastructure. Một organization với 100 microservices có thể đang nhìn vào 5,000-10,000 CVEs cần triage mỗi quarter. Không có security team nào đủ bandwidth để làm việc này manually mà không burn out.

Ngay cả Microsoft, với resources gần như unlimited, cũng acknowledge vấn đề này. Trong blog announcement về VEX adoption của họ, Microsoft mô tả approach "crawl, walk, run" khi bắt đầu chỉ với Azure Linux Distribution trước khi mở rộng ra các products khác. Nếu big tech còn phải cẩn thận như vậy, thì đây rõ ràng không phải là một solved problem.

Đây là lý do tại sao automation trở nên cần thiết, và cụ thể hơn là tại sao người ta bắt đầu nghĩ đến việc dùng LLM cho task này.

4. NVIDIA AI Blueprint: Plan-and-Execute cho CVE Analysis

NVIDIA đã release một AI Blueprint khá interesting cho vulnerability analysis, built on top of NVIDIA Morpheus và sử dụng Llama 3 NIM microservices. Điểm đáng chú ý là architecture Plan-and-Execute mà họ sử dụng, thay vì chỉ throw CVE vào LLM và hope for the best.

Kiến trúc tổng quan

Blueprint hoạt động theo 5 phases:

Tại sao Plan-and-Execute works

Thay vì single-shot prompting (đưa tất cả context vào một prompt và expect LLM trả lời), Plan-and-Execute chia task thành multiple steps với reasoning checkpoints. Planner LLM đóng vai trò như một security analyst experienced: trước khi dive vào investigation, nó generates một checklist những gì cần kiểm tra. Điều này giúp avoid missing critical checks và cũng làm cho reasoning process transparent hơn.

Agent với RAG capabilities sau đó execute từng item trong checklist, pulling relevant information từ multiple sources: CVE databases cho vulnerability details, SBOM cho affected components, và embedded codebase cho actual code paths. Cuối cùng, Categorization LLM synthesize tất cả findings và assign VEX status.

Simplified Code Concept

Dưới đây là một simplified illustration của approach này. Lưu ý đây là pseudo-code để minh họa concept, không phải actual NVIDIA implementation (actual code phức tạp hơn nhiều với error handling, async processing, và optimizations):

# Pseudo-code illustration - actual imports và APIs có thể khác
# depending on LangChain version và LLM provider
from langchain_openai import ChatOpenAI  # hoặc langchain_community
from langchain_core.prompts import PromptTemplate

# Phase 1: Planner generates investigation checklist
planner_prompt = PromptTemplate(
    input_variables=["cve_id", "cve_description", "affected_component"],
    template="""
    You are a security analyst investigating {cve_id}.

    CVE Description: {cve_description}
    Affected Component: {affected_component}

    Generate a checklist of 3-5 specific questions that need to be answered
    to determine if this vulnerability is exploitable in the target application.
    Focus on:
    - Code reachability
    - Required configurations
    - Environmental prerequisites
    - Available mitigations
    """
)

# Trong thực tế, bạn sẽ chain này với LLM
llm = ChatOpenAI(model="gpt-4")
planner_chain = planner_prompt | llm  # LCEL syntax

# Phase 2: Agent executes checklist (simplified)
def investigate_cve(cve_id, checklist, codebase_index, cve_database):
    findings = []
    for question in checklist:
        # Query CVE database for vulnerability specifics
        cve_info = cve_database.query(cve_id)

        # Search codebase for relevant code paths
        code_context = codebase_index.similarity_search(question)

        findings.append({
            "question": question,
            "cve_context": cve_info,
            "code_context": code_context
        })
    return findings

# Phase 3: Categorization with VEX status
categorizer_prompt = PromptTemplate(
    input_variables=["cve_id", "findings"],
    template="""
    Based on the following investigation findings for {cve_id}:

    {findings}

    Determine the VEX status. Choose from:
    - vulnerable: The vulnerability is exploitable
    - code_not_present: Vulnerable code is not in the codebase
    - code_not_reachable: Code exists but cannot be reached
    - requires_configuration: Specific configuration needed
    - requires_environment: Specific environment needed
    - protected_by_compiler: Compiler mitigations prevent exploitation
    - protected_at_runtime: Runtime protections active
    - protected_by_perimeter: Network protections in place

    Provide:
    1. VEX Status
    2. Justification (2-3 sentences)
    3. Confidence level (high/medium/low)
    """
)

NVIDIA Blueprint sử dụng Llama-3.1-70B-instruct làm default model, với specifically tailored prompts và edge case handling. Họ cũng leverage NVIDIA Morpheus cho asynchronous, parallel GPU processing để analyze multiple CVEs simultaneously.

5. Từ Container Image đến VEX Report: Walkthrough

Hãy đi qua một ví dụ cụ thể để xem flow này hoạt động như thế nào trong thực tế.

Step 1: Generate SBOM với Syft

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate SBOM cho một container image
syft nginx:1.24 -o cyclonedx-json > nginx-sbom.json

# Output snippet:
# {
#   "bomFormat": "CycloneDX",
#   "specVersion": "1.4",
#   "components": [
#     {
#       "type": "library",
#       "name": "openssl",
#       "version": "3.0.2",
#       "purl": "pkg:deb/debian/[email protected]"
#     },
#     ...
#   ]
# }

Step 2: Cross-reference với Vulnerability Database

# Dùng Grype để scan vulnerabilities
grype nginx:1.24 -o json > vulnerabilities.json

# Hoặc query trực tiếp từ NVD/GHSA
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=openssl" \
  -H "apiKey: YOUR_API_KEY"

Giả sử scanner tìm thấy CVE-2024-XXXX affecting OpenSSL với description: "Buffer overflow in X509_verify() function when processing malformed certificates."

Step 3: LLM Investigation

Planner LLM generates checklist:

1. Does the application process X509 certificates from untrusted sources?
2. Is X509_verify() called directly or indirectly in the codebase?
3. What OpenSSL version is actually used, and is the fix backported?
4. Are there any input validation layers before certificate processing?

Agent executes và gathers:

• Code search: X509_verify không xuất hiện trong application code
• Configuration: HTTPS enabled nhưng chỉ với trusted CA bundle
• Environment: Container runs with read-only filesystem

Step 4: VEX Output

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2025/nginx-analysis",
  "author": "[email protected]",
  "timestamp": "2025-01-27T10:00:00Z",
  "statements": [
    {
      "vulnerability": {
        "@id": "https://nvd.nist.gov/vuln/detail/CVE-2024-XXXX",
        "name": "CVE-2024-XXXX"
      },
      "products": [
        {
          "@id": "pkg:docker/[email protected]",
          "name": "nginx:1.24"
        }
      ],
      "status": "not_affected",
      "justification": "code_not_reachable",
      "impact_statement": "The vulnerable X509_verify() function is present in the OpenSSL library included in this image. However, analysis of the nginx configuration and runtime environment shows that certificate verification only occurs with a pre-configured trusted CA bundle. User-supplied certificates are not processed, making the vulnerable code path unreachable from any attack surface.",
      "action_statement": "No action required. Continue monitoring for changes in certificate handling configuration."
    }
  ]
}

Output này có thể được feed trực tiếp vào vulnerability management tools, hoặc được review bởi security team trước khi finalize. Điểm quan trọng là phần lớn heavy lifting đã được automated, security analyst chỉ cần verify reasoning thay vì làm lại từ đầu.

Tuy nhiên, trước khi bạn excited quá và quyết định replace toàn bộ security team bằng một con chatbot, chúng ta cần nói về những gì có thể go wrong.

6. Limitations: Không phải Silver Bullet

LLM-powered VEX generation là một tool powerful, nhưng như mọi tool khác, nó có những limitations cần được hiểu rõ trước khi đưa vào production.

LLM Hallucination về Code Paths

LLMs có thể tự tin khẳng định rằng một code path không reachable trong khi thực tế nó có thể được trigger qua một edge case mà model không consider. Đây không phải là theoretical concern, mà là practical reality. Một LLM có thể miss indirect calls through reflection, dynamic dispatch, hoặc callback chains. Nó cũng có thể misunderstand framework-specific behaviors, ví dụ như cách Django middleware chain works hoặc cách Spring AOP weaves code. Kết luận là VEX output từ LLM nên được treat như first-pass triage, không phải final verdict.

Token Limits và Large Codebases

Ngay cả với context windows lớn như 128K tokens, việc analyze một codebase với hàng triệu lines of code là không feasible trong một lần. NVIDIA Blueprint addresses điều này bằng RAG (chỉ retrieve relevant code snippets), nhưng relevance của retrieval phụ thuộc vào quality của embedding và query formulation. Nếu vulnerable code nằm trong một module mà embedding không capture đúng semantic relationship, nó có thể bị miss.

Cost Considerations

Mỗi CVE analysis có thể involve multiple LLM calls: planner, agent queries, và categorizer. Với Llama-3.1-70B qua API, cost có thể nhanh chóng add up. Assume mỗi CVE cần ~5000 tokens input và ~1000 tokens output, với rate $0.01/1K tokens, analyzing 1000 CVEs có thể cost $50-100 chỉ riêng LLM calls, chưa kể infrastructure costs. Đây là một trade-off cần consider, đặc biệt cho small-to-medium teams.

Privacy và Data Sensitivity

Sending source code đến third-party LLM APIs raises obvious concerns. NVIDIA Blueprint được designed để run on-premises với NIM microservices, nhưng không phải organization nào cũng có GPU infrastructure để self-host 70B parameter models. Alternatives như smaller models có thể sacrifice accuracy.

False Sense of Security

Có lẽ concern lớn nhất là psychological: một automated system nói "not affected" có thể khiến teams skip manual verification cho critical vulnerabilities. Điều quan trọng là establish clear policies về khi nào human review là mandatory, ví dụ như tất cả CVEs với CVSS > 9.0, tất cả vulnerabilities trong authentication/authorization code, hay bất kỳ CVE nào mà LLM reports confidence level là "medium" hoặc "low".

Với những limitations này trong đầu, nếu bạn vẫn quyết định move forward (và honestly, với đúng guardrails thì đây vẫn là một approach đáng thử), đây là những gì cần consider cho production.

7. Production Considerations

Integration vào CI/CD Pipeline

VEX analysis nên được trigger tự động khi có base image updates hoặc dependency changes, khi new CVEs được published cho existing components (via vulnerability feed subscription), hoặc như part của regular security scanning schedule. Output có thể feed vào ticketing systems (JIRA, ServiceNow) với appropriate severity levels và assigned owners.

Caching và Deduplication

Cùng một CVE + component combination không cần re-analyze mỗi lần nếu không có changes. Implement caching strategy như cache VEX results by (CVE_ID, component_PURL, code_hash), chỉ invalidate khi CVE advisory updates hoặc code changes. Điều này có thể reduce LLM calls dramatically cho organizations với nhiều similar containers.

Confidence Scoring và Escalation

Không phải tất cả VEX determinations đều có cùng confidence level. Build escalation workflows như "high confidence not_affected" thì auto-close ticket, "medium confidence" thì queue cho human review, còn "low confidence" hoặc "vulnerable" thì immediate escalation. NVIDIA Blueprint supports outputting confidence levels, leverage this trong workflow design.

Audit Trail

VEX documents là assertions có thể được audit. Ensure bạn retain full context bao gồm LLM model version và prompts used, tất cả sources queried và responses, và human review decisions (nếu có). Điều này quan trọng cho compliance, đặc biệt trong regulated industries.

8. Kết luận

Key Takeaways

• VEX bridges the gap giữa SBOM inventory và actionable security decisions. Biết "có vulnerability" là không đủ, cần biết "có exploitable không".

• LLM-powered triage với Plan-and-Execute architecture có thể dramatically reduce manual effort, từ hours/days per CVE xuống seconds. NVIDIA Blueprint là một solid reference implementation.

• Không phải replacement cho human judgment, mà là force multiplier. LLM làm first-pass, humans focus vào high-risk và low-confidence items.

• Adoption đang accelerate: Microsoft đã bắt đầu publish VEX cho Azure Linux, và theo Gartner predictions, organizations implementing VEX có thể achieve up to 40% reduction trong patch management costs.

Next Steps

Nếu bạn muốn explore thêm, đây là suggested path:

1. Learn VEX formats: Start với OpenVEX cho simplicity, graduate to CycloneDX hoặc CSAF khi needs mature.

2. Try NVIDIA Blueprint: Available free tại build.nvidia.com. Code và integration examples trên GitHub.

3. Start small: Pick một critical application, generate SBOM, manually create VEX cho top 10 CVEs. Hiểu process trước khi automate.

4. Consider hybrid approach: LLM for initial triage, human review for anything affecting critical data paths hoặc authentication.

Vulnerability management sẽ không bao giờ là một "set and forget" problem. Nhưng với đúng tools và approach, chúng ta có thể shift từ drowning trong alerts sang actually understanding và managing risk. VEX là một piece quan trọng của puzzle đó, và LLM automation là cách để make it practical at scale.

Quay lại scenario đầu bài: 847 CVEs sáng thứ Hai. Với LLM-powered VEX, thay vì mất cả tuần để manually triage, bạn có thể có initial assessment trong vài giờ, với phần lớn CVEs được auto-categorized là "not affected" kèm reasoning. Security team chỉ cần focus vào những gì thực sự matter: các CVEs được flag là "vulnerable" hoặc "low confidence". Đó mới là cách làm việc smart trong thời đại này.

Sources:

• NVIDIA AI Blueprint for Vulnerability Analysis - Official implementation
• NVIDIA Technical Blog: Rapidly Triage Container Security
• Microsoft: Machine-readable VEX for Azure Linux
• OASIS: Signal in the Noise - State of VEX
• CycloneDX VEX Specification
• CISA VEX Minimum Requirements
• Anchore Blog: NVIDIA Blueprint with Syft