Remediation Patch Verification Prompt Template

This prompt is designed for security engineers and DevSecOps pipelines that need to verify whether a code patch fully resolves a reported vulnerability. Use it after a developer submits a fix but before the change merges. The prompt ingests the original vulnerability report and the proposed patch diff, then produces a structured assessment confirming whether the fix is complete, whether any bypasses remain, and whether the change introduces new security concerns. This is not a replacement for SAST or dynamic testing; it is a pre-merge review accelerator that catches incomplete fixes and regressions before they reach production.

The ideal workflow places this prompt as a gating step in your CI/CD pipeline. When a pull request is tagged with a vulnerability identifier, the system should assemble the original finding (including reproduction steps, affected endpoints, and severity), the full patch diff, and any relevant code context into the prompt. The model then produces a structured verification assessment. You should configure the pipeline to block the merge if the assessment returns a verification_status of incomplete or regression_detected. For high-severity vulnerabilities, always require a human security reviewer to approve the model's assessment before the merge proceeds. Do not use this prompt for vulnerabilities that require dynamic testing, runtime exploit verification, or cryptographic proof of fix correctness—those require separate testing infrastructure.

Avoid using this prompt when the vulnerability report lacks reproduction steps or when the patch is too large for a single context window. If the diff exceeds the model's effective context, split the review by affected component and run multiple assessments. Also avoid relying on this prompt for vulnerabilities in compiled binaries, firmware, or hardware designs where source-code analysis alone cannot confirm remediation. For regulated environments, ensure that the model's output is logged as part of the audit trail but does not replace the required human sign-off. The next step after reading this section is to copy the prompt template, populate the placeholders with your vulnerability report and patch data, and wire it into your review pipeline with the validation checks described in the implementation harness.

This prompt template is designed for security engineers who need to validate that a code change actually fixes a reported vulnerability. It ingests the original finding, the patch diff, and any relevant application context, then produces a structured verification assessment. The template is built to catch incomplete fixes, regressions, and new attack surfaces introduced by the remediation itself.

codeCopy
You are a security engineer verifying a vulnerability remediation patch.

## INPUTS
[FINDING_DETAILS]
[PATCH_DIFF]
[APPLICATION_CONTEXT]

## TASK
Analyze the patch diff against the original finding and determine whether the remediation is complete, partial, or ineffective. Identify any new risks introduced by the patch itself.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "verification_status": "VERIFIED" | "PARTIAL" | "INEFFECTIVE" | "REGRESSIVE",
  "finding_coverage": {
    "addressed_root_cause": true | false,
    "addressed_attack_vector": true | false,
    "addressed_impact": true | false,
    "explanation": "string"
  },
  "residual_risk": {
    "level": "NONE" | "LOW" | "MEDIUM" | "HIGH",
    "description": "string",
    "conditions_for_exploitation": "string or null"
  },
  "new_risks_introduced": [
    {
      "type": "string",
      "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
      "location": "string (file and line reference from diff)",
      "description": "string"
    }
  ],
  "test_recommendations": [
    {
      "test_type": "string (e.g., unit, integration, security regression)",
      "description": "string",
      "priority": "HIGH" | "MEDIUM" | "LOW"
    }
  ],
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "confidence_rationale": "string",
  "requires_human_review": true | false,
  "human_review_reason": "string or null"
}

## CONSTRAINTS
- Do not assume the patch is correct. Verify each claim against the diff content.
- If the patch only addresses the symptom but not the root cause, classify as PARTIAL.
- Flag any code that introduces new input paths, new dependencies, or new privilege requirements.
- If the patch removes security-relevant checks without explanation, flag as REGRESSIVE.
- When confidence is LOW or residual risk is HIGH, requires_human_review must be true.
- Reference specific file paths and line numbers from the diff in all findings.
- Do not hallucinate vulnerabilities not present in the provided inputs.

Before executing this prompt, replace each square-bracket placeholder with real data. The [FINDING_DETAILS] should include the vulnerability type, affected component, severity, attack vector description, and any reproduction steps. The [PATCH_DIFF] should be the full unified diff of the proposed fix. The [APPLICATION_CONTEXT] should describe the application's trust boundaries, authentication model, and any relevant security controls already in place. After receiving the output, validate that the JSON schema matches exactly before routing the result. For high-severity vulnerabilities, always route the output through a human reviewer regardless of the model's confidence score.

The Remediation Patch Verification Prompt Template is designed to sit at a critical gate in your CI/CD or security review pipeline: after a developer submits a fix for a known vulnerability, but before that fix is merged or deployed. The prompt ingests the original vulnerability finding and the proposed patch diff, then produces a structured verification assessment. This assessment must answer three questions: does the patch actually close the reported vulnerability vector, does it introduce any new security concerns, and what residual risk remains after the fix? The harness around this prompt is what makes the difference between an interesting AI output and a reliable security control.

To integrate this prompt into a pipeline, start by defining the required inputs as structured objects rather than free text. The [ORIGINAL_FINDING] should include the vulnerability type (CWE), affected code location, exploit preconditions, and severity. The [PATCH_DIFF] should be the unified diff of the proposed change with sufficient context lines to show surrounding logic. The [APPLICATION_CONTEXT] should describe the runtime environment, trust boundaries, and any compensating controls already in place. Before calling the model, validate that all three inputs are present and non-empty. After receiving the model response, parse the structured output—which should include a verification_status (VERIFIED, INCOMPLETE, REGRESSIVE, or UNCERTAIN), a finding_status for each original vulnerability vector, a new_concerns array for any introduced issues, and a residual_risk assessment. Implement a schema validator that rejects responses missing required fields or containing invalid enum values, and trigger a retry with the validation errors fed back into the prompt context.

For high-risk applications, this prompt should never be the sole gate. Implement a confidence threshold: if the model's verification_status is UNCERTAIN or its confidence score falls below a configured floor, route the assessment to a human security reviewer. Log every verification run with the full input, output, model version, and timestamp for auditability. When deploying to production, test the harness against a golden dataset of known patch scenarios: fixes that correctly close a vulnerability, incomplete fixes that leave the vector partially open, regressive fixes that introduce new flaws, and fixes for vulnerabilities that were already mitigated by compensating controls. Measure both false-acceptance rate (passing a bad patch) and false-rejection rate (failing a good patch). If the prompt is part of an automated merge gate, the false-rejection rate directly impacts developer velocity, so tune the confidence thresholds and human-review fallback accordingly. The harness should also detect when the patch diff is too large for a single context window and either truncate with a warning or split the review across multiple calls with a reconciliation step.