Vulnerability Scan Pass Verification Prompt

This prompt is designed for security engineers and vulnerability management teams who need to programmatically confirm that a specific remediation action successfully resolved identified vulnerabilities. The core job-to-be-done is closing the loop on a finding by comparing structured pre-remediation and post-remediation scan results, applying severity threshold gating, and suppressing known false positives to produce a definitive pass, fail, or needs-review determination. It is not a general-purpose vulnerability analysis tool; its value is strictly in the post-action verification phase, after a patch has been applied, a configuration change has been deployed, or a compensating control has been implemented and a follow-up scan has completed.

Use this prompt when you have two structured data payloads—a baseline scan and a follow-up scan—and you need a reproducible, evidence-backed verification report before updating a risk register or closing a ticket. The prompt expects explicit inputs for severity thresholds and a list of known false positives to suppress, which prevents noisy or accepted risks from blocking a pass determination. It is appropriate for workflows where human approval is a hard gate: the model's output is a recommendation, not an authorization. The generated report should be routed to a human reviewer for final sign-off, especially for high-severity findings or when the determination is 'needs-review' due to ambiguous or conflicting evidence.

Do not use this prompt for initial vulnerability triage, for real-time intrusion detection, or as a substitute for a formal penetration test. It is also unsuitable when scan data is unstructured, when pre- and post-scan formats are incompatible without normalization, or when the remediation action itself is not clearly documented. If the input lacks a defined severity schema or a false-positive suppression list, the prompt's gating logic will be unreliable. In these cases, invest in data normalization and false-positive curation upstream before wiring this prompt into an automated verification pipeline.

This template is the core instruction set for the Vulnerability Scan Pass Verification Prompt. It is designed to be pasted directly into your AI system after you have pre-processed raw scan outputs into the structured [SCAN_DATA] format. The prompt instructs the model to act as a security engineer, systematically comparing pre- and post-remediation scan results, suppressing known false positives, and applying a severity threshold gate before declaring a scan 'passed'. The output is a strict JSON report, making it suitable for direct integration into a CI/CD pipeline or a security operations dashboard.

markdownCopy
You are a security engineer verifying that a vulnerability remediation was successful. Your task is to compare a pre-remediation scan result with a post-remediation scan result and generate a structured verification report.

### INPUT DATA
[SCAN_DATA]
# SCAN_DATA is a JSON object with the following structure:
# {
#   "target": "string", // The system, image, or repository that was scanned
#   "scan_policy": "string", // The policy name or profile used for the scan
#   "pre_remediation": {
#     "scan_id": "string",
#     "timestamp": "ISO8601 string",
#     "findings": [
#       {
#         "vulnerability_id": "string", // e.g., CVE-2023-XXXX
#         "severity": "CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL",
#         "package": "string",
#         "installed_version": "string",
#         "fixed_version": "string",
#         "description": "string"
#       }
#     ]
#   },
#   "post_remediation": {
#     "scan_id": "string",
#     "timestamp": "ISO8601 string",
#     "findings": [ /* same structure as pre_remediation */ ]
#   },
#   "false_positive_list": ["CVE-2023-XXXX", "CVE-2024-YYYY"],
#   "severity_failure_threshold": "HIGH" // Vulnerabilities at or above this level in the post-scan constitute a failure
# }

### CONSTRAINTS
- [CONSTRAINTS]
# 1. A vulnerability is considered 'remediated' if it appears in the pre_remediation findings but NOT in the post_remediation findings.
# 2. A vulnerability is considered 'new' if it appears in the post_remediation findings but NOT in the pre_remediation findings.
# 3. A vulnerability is considered 'persistent' if it appears in both.
# 4. You MUST exclude any vulnerability whose ID is in the `false_positive_list` from the 'new' and 'persistent' counts and the final pass/fail decision. Flag them separately as 'suppressed'.
# 5. The final `verification_status` MUST be "FAILED" if there are any 'new' or 'persistent' vulnerabilities with a severity at or above the `severity_failure_threshold` after false positive suppression. Otherwise, it is "PASSED".

### OUTPUT SCHEMA
You must return a single valid JSON object conforming to this schema. Do not include any text outside the JSON object.
[OUTPUT_SCHEMA]
{
  "report_id": "string", // A unique ID for this verification report
  "target": "string",
  "verification_timestamp": "ISO8601 string", // Use the current time
  "scan_window": {
    "pre_scan_id": "string",
    "post_scan_id": "string"
  },
  "summary": {
    "pre_remediation_total": "integer",
    "post_remediation_total": "integer",
    "remediated_count": "integer",
    "new_count": "integer",
    "persistent_count": "integer",
    "suppressed_false_positive_count": "integer"
  },
  "findings_detail": {
    "remediated": ["vulnerability_id"],
    "new": [
      {
        "vulnerability_id": "string",
        "severity": "string",
        "package": "string"
      }
    ],
    "persistent": [
      {
        "vulnerability_id": "string",
        "severity": "string",
        "package": "string"
      }
    ],
    "suppressed": ["vulnerability_id"]
  },
  "verification_status": "PASSED|FAILED",
  "failure_reason": "string|null" // If FAILED, a concise explanation of which new/persistent high-severity findings caused the failure.
}

To adapt this template, replace the [SCAN_DATA] placeholder with your actual pre-processed JSON payload. The [CONSTRAINTS] section contains the core business logic for comparison and false positive handling; you can modify these rules to match your organization's vulnerability management policy, such as changing the definition of 'remediated' to require a specific time window. The [OUTPUT_SCHEMA] defines the strict JSON contract your application will parse. Before deploying this prompt, run it against a golden dataset of known scan pairs to ensure the model reliably follows the severity threshold gating and correctly suppresses false positives. In a production harness, you should validate the output JSON against this schema immediately after the model response and implement a retry or human escalation path if validation fails.

The Vulnerability Scan Pass Verification Prompt is designed to be a gate, not a passive report. In a production workflow, this prompt should execute after a remediation event and before a deployment or change request is marked as compliant. The harness must treat the model's output as a structured decision artifact that is validated, logged, and subject to a severity-based approval policy. The core integration pattern involves feeding the prompt a pre-remediation scan, a post-remediation scan, a list of known false positives, and a severity threshold. The model's job is to produce a deterministic verification report, not to make an autonomous security decision.

To implement the harness, wrap the LLM call in a validation layer that enforces the output schema before the result is trusted. The expected output is a JSON object with a top-level verdict field (PASS, FAIL, INCONCLUSIVE), a list of resolved_vulnerabilities, a list of remaining_vulnerabilities, and a false_positive_suppression_audit. A JSON Schema validator should reject any response that does not conform. If validation fails, implement a retry loop with a maximum of 3 attempts, appending the validation error to the prompt context on each retry. After 3 failures, the workflow must escalate to a human review queue with the raw model output and the validation errors. For model choice, use a model with strong structured output capabilities and a low temperature setting (e.g., 0.1) to maximize deterministic behavior. The prompt should be called with response_format set to json_object or the equivalent for your model provider.

The critical gating logic lives outside the prompt. After a valid JSON response is received, the application layer must check the verdict field. If the verdict is PASS, the workflow can proceed automatically only if no remaining_vulnerabilities have a severity above the configured threshold. If any remaining vulnerability exceeds the threshold, the verdict must be programmatically overridden to FAIL and escalated. If the verdict is FAIL or INCONCLUSIVE, the entire verification report, including the pre- and post-scan evidence, must be routed to a human approval queue. The approval interface should present a structured diff of the findings, highlight the false positive suppressions, and require an explicit sign-off before the change can proceed. Log every verification attempt, including the raw scans, the prompt, the model's response, the validation result, and the final gating decision, to create an immutable audit trail for compliance reviews.