Technical Security Advisory RAG Prompt

This prompt is designed for security operations and product security teams who need to generate structured, evidence-backed technical advisories from a corpus of CVE records, vendor bulletins, and internal security documentation. The core job-to-be-done is converting a natural-language question—such as 'What is the exploitability of CVE-2024-1234 on our current kernel version?'—into a disciplined advisory that includes a CVE reference, an affected-version matrix, an exploitability assessment, and a prioritized remediation plan. The ideal user is an AI engineer or security analyst integrating this prompt into an internal RAG pipeline where the retrieved context is already scoped to a trusted document collection.

Use this prompt when the output must be actionable by infrastructure and remediation teams. It is appropriate when the system has access to a curated, versioned knowledge base of vulnerability data and when the cost of a hallucinated CVE identifier or a wrong version range is high enough to require strict grounding and citation. The prompt includes explicit instructions to abstain when evidence is missing, to flag stale advisory data, and to separate confirmed exploitability from theoretical risk. This makes it suitable for environments where a misleading answer could trigger unnecessary patching or, worse, leave a critical vulnerability unaddressed.

Do not use this prompt as a general-purpose security chatbot or as a substitute for a live threat intelligence feed. It is not designed for open-ended threat hunting, raw log analysis, or incident response coordination. The prompt assumes that retrieval has already occurred and that the provided context contains structured advisory data. If your system cannot reliably retrieve CVE records, vendor fix versions, or CVSS vectors, this prompt will not compensate for that gap. For high-severity or actively exploited vulnerabilities, always pair the generated advisory with a human review step before it reaches remediation teams or automated patch management systems.

This prompt template is designed to be dropped into a RAG pipeline where retrieved context—CVE entries, vendor advisories, and internal security documentation—has already been assembled. It instructs the model to synthesize a structured advisory that prioritizes actionable remediation, explicitly flags data staleness, and separates confirmed exploitability from theoretical risk. The template uses square-bracket placeholders for all variable inputs, making it straightforward to wire into an application that populates these fields before inference.

codeCopy
You are a technical security advisory assistant. Your task is to generate a concise, actionable security advisory using ONLY the retrieved context provided below. Do not use any external knowledge or training data.

## CONTEXT
[RETRIEVED_CONTEXT]

## INSTRUCTIONS
1.  **Synthesize an advisory** that addresses the user's question: [USER_QUESTION].
2.  **Structure the output** strictly according to the following schema:
    - **Executive Summary:** A one-paragraph summary of the threat, its severity, and the most critical remediation action.
    - **Affected Systems Matrix:** A markdown table listing each affected product/version, its status (e.g., Affected, Not Affected, Under Investigation), and the source document reference.
    - **Vulnerability Details:** For each relevant CVE, provide the CVE ID, CVSS score, exploitability assessment (e.g., "Proof of Concept Exists", "Actively Exploited", "Theoretical"), and a concise technical description grounded in the context.
    - **Remediation & Mitigation:** A prioritized list of actions (patch, configuration change, workaround) with explicit steps and source references.
    - **Data Freshness & Confidence Notes:** Explicitly state the publication date of the newest and oldest source documents used. Flag any information that appears stale (e.g., a CVE last modified over 90 days ago without a vendor fix) or where sources conflict. If the context is insufficient to answer the question fully, state what is missing.
3.  **Constraints:**
    - Every factual claim must be directly supported by a citation to a source document in the context (e.g., [Source: CVE-2024-XXXXX]).
    - Do not fabricate CVSS scores, affected versions, or remediation steps.
    - If the user's question falls outside the scope of a technical security advisory (e.g., asks for legal advice, writes marketing copy), respond with: "This request is outside the scope of a technical security advisory."
    - The advisory must be self-contained and not require the reader to have access to the original context to understand the core message.

To adapt this template, replace the placeholders with your application's runtime values. [RETRIEVED_CONTEXT] should be a pre-formatted string of your top-k retrieval results, ideally with clear document IDs for citation. [USER_QUESTION] is the raw query from the security analyst. The output schema is designed to be parseable; you can further constrain the model by replacing the markdown structure with a strict JSON schema in the instructions if your downstream system requires it. For high-stakes deployments, always pair this prompt with a validation step that checks for the presence of required fields and source citations before the advisory reaches a human reviewer.

The Technical Security Advisory RAG prompt is designed to operate within a retrieval-augmented generation pipeline that pulls from CVE databases, vendor advisories, and internal security documentation. The implementation harness must enforce strict input validation, output schema compliance, and evidence grounding before any advisory reaches a security analyst. Because the output includes exploitability assessments and remediation prioritization, a human review step is mandatory for any advisory rated CRITICAL or containing a remediation_timeline of less than 24 hours.

Wire the prompt into your application by first assembling the retrieval context. Query your vector store and structured CVE database in parallel, deduplicate results by CVE ID, and sort by published_date descending. The [CONTEXT] placeholder expects a JSON array of advisory objects, each containing cve_id, description, cvss_score, affected_products, vendor_advisory_url, and last_modified. Validate that every object has a non-null cve_id before injection. The [INPUT] placeholder accepts a natural-language question from the security analyst, such as "What is the current exposure for CVE-2024-1234 in our environment?" The [RISK_LEVEL] placeholder should be set to high or critical when the query involves actively exploited vulnerabilities, which triggers stricter output validation and mandatory human review.

After the model returns a response, validate the output against the expected schema: advisory_id, cve_references (array of CVE IDs), affected_version_matrix (object mapping product to version ranges), exploitability_assessment (enum: none, proof_of_concept, active_exploitation), remediation_priority (enum: immediate, scheduled, monitor), and stale_data_flags (array of CVE IDs where last_modified is older than 30 days). Use a JSON Schema validator in your application layer. If validation fails, retry once with the original prompt plus the validation error message appended as a [CONSTRAINTS] note. If the retry also fails, log the failure and escalate to a human analyst with the raw model output and validation errors attached. For observability, log every prompt version, retrieval query, model response, validation result, and human review decision to your security operations audit trail.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, and set temperature to 0.1 or lower to reduce variability in CVE references and version matrices. Enable structured output mode if your provider supports it, passing the expected JSON schema directly rather than relying on prompt-level formatting instructions alone. For stale advisory data, implement a pre-retrieval freshness check: if any retrieved CVE has a last_modified date older than your configured threshold (default 30 days), inject a [STALE_DATA_WARNING] into the prompt context that instructs the model to flag those CVEs explicitly. This prevents the model from presenting outdated information as current without warning the analyst.

The most common production failure mode is the model hallucinating CVE IDs or version ranges that do not appear in the retrieved context. Mitigate this by implementing a post-generation evidence check: extract every CVE ID from the model output and verify it exists in the original retrieval results. If any CVE ID is not found, either strip it from the output or retry with an explicit instruction to only reference CVEs present in the provided context. A second failure mode is the model producing overly confident exploitability assessments when evidence is thin. Configure your eval pipeline to flag any exploitability_assessment of active_exploitation that is not supported by at least two distinct sources in the retrieval context. When this flag fires, downgrade the assessment to proof_of_concept and add a note that active exploitation could not be confirmed from available sources.