Security-Sensitive Diff Review Prompt

This prompt is designed for security engineers and DevSecOps pipelines that need a fast, automated first pass at triaging pull request diffs for common vulnerability patterns. The primary job-to-be-done is to reduce the mean time to detection for high-signal, low-noise security issues—such as SQL injection, XSS, path traversal, and insecure deserialization—before a human reviewer ever looks at the code. It maps findings to OWASP Top 10 and CWE classifications, producing a severity-ranked list with precise code references. The ideal user is a security engineer who wants to amplify their review capacity, or a platform team embedding security gates into CI/CD without blocking development velocity on low-risk changes.

To use this prompt effectively, you must provide a structured diff as input, along with any relevant context such as the language, framework, and the trust boundary of the modified code. The prompt is most effective when it can reason about data flow from user input to sensitive sinks. It is not a replacement for a full penetration test, a manual security review of authentication or cryptographic implementations, or a business logic abuse assessment. It should be deployed as a pre-merge gate that flags potential issues for human triage, not as an auto-approval mechanism. For high-risk repositories handling financial transactions, personal data, or authentication, always require a human security engineer to approve findings before merging.

Avoid using this prompt for diffs that are purely cosmetic, documentation-only, or configuration changes that do not alter runtime behavior. It will produce noise on large, monolithic refactors where data flow is obscured. For those cases, pair it with a context-gathering step that retrieves the relevant sink and source definitions from your codebase. The next section provides the copy-ready prompt template you can adapt to your specific vulnerability classes and severity taxonomy.

This template is designed to be copied directly into your application or evaluation harness. Every placeholder enclosed in square brackets—such as [DIFF_CONTENT], [REPO_CONTEXT], and [SEVERITY_THRESHOLD]—must be replaced with actual data before the prompt is sent to the model. The template enforces a structured output schema so findings can be parsed, validated, and routed into your existing vulnerability management workflow. Do not modify the instruction structure unless you also update the corresponding output schema, eval assertions, and downstream ingestion logic.

textCopy
You are a security review assistant analyzing a code diff for common vulnerability patterns aligned with OWASP Top 10 and CWE classifications. Your output must be machine-readable JSON matching the schema below. Do not include commentary outside the JSON structure.

## INPUT

### Diff to Review
[DIFF_CONTENT]

### Repository Context
- Language(s): [LANGUAGES]
- Framework(s): [FRAMEWORKS]
- Sensitive data types handled: [DATA_TYPES]
- Authentication mechanism: [AUTH_MECHANISM]
- Deployment boundary: [DEPLOYMENT_BOUNDARY]

## CONSTRAINTS
- Only report findings with severity at or above: [SEVERITY_THRESHOLD]
- Maximum findings to return: [MAX_FINDINGS]
- If no findings meet the threshold, return an empty findings array.
- Cite the specific file path and line range for each finding.
- Map each finding to at least one CWE ID where applicable.
- Do not flag issues already addressed by existing mitigations described in: [EXISTING_MITIGATIONS]
- [ADDITIONAL_CONSTRAINTS]

## OUTPUT SCHEMA
Return valid JSON only:
{
  "review_metadata": {
    "diff_hash": "string",
    "review_timestamp": "string (ISO 8601)",
    "severity_threshold_applied": "string",
    "total_findings": "integer"
  },
  "findings": [
    {
      "finding_id": "string (unique within this review)",
      "severity": "critical | high | medium | low | informational",
      "cwe_ids": ["string"],
      "title": "string (concise summary)",
      "description": "string (what the vulnerability is and why it matters)",
      "file_path": "string",
      "line_range": "string (e.g., L42-L58)",
      "vulnerable_code_snippet": "string (excerpt from diff)",
      "exploitability": "string (assessment of how exploitable this is in the current deployment context)",
      "remediation": "string (specific, actionable fix guidance)",
      "requires_immediate_escalation": "boolean",
      "references": ["string (URLs to CWE, OWASP, or relevant documentation)"]
    }
  ],
  "diff_summary": {
    "files_changed": "integer",
    "lines_added": "integer",
    "lines_removed": "integer",
    "security_relevant_files": ["string"],
    "overall_risk_assessment": "string (holistic assessment of the diff's security posture)"
  }
}

## EXAMPLES
### Example Finding (for reference only—do not include in output)
{
  "finding_id": "SEC-001",
  "severity": "high",
  "cwe_ids": ["CWE-89"],
  "title": "SQL Injection in User Search Endpoint",
  "description": "User-supplied input is concatenated directly into a SQL query string without parameterization, allowing an attacker to manipulate query logic.",
  "file_path": "src/api/users/search.ts",
  "line_range": "L142-L148",
  "vulnerable_code_snippet": "const query = `SELECT * FROM users WHERE name LIKE '%${req.query.name}%'`;",
  "exploitability": "Remotely exploitable without authentication. Attacker can exfiltrate user data or modify database contents.",
  "remediation": "Replace string interpolation with parameterized queries using the database driver's prepared statement API. Example: `db.query('SELECT * FROM users WHERE name LIKE ?', [`%${name}%`])`.",
  "requires_immediate_escalation": true,
  "references": ["https://cwe.mitre.org/data/definitions/89.html", "https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"]
}

## INSTRUCTIONS
1. Parse the diff to identify all changed code blocks.
2. For each change, assess against the OWASP Top 10 and relevant CWE categories.
3. Filter findings below [SEVERITY_THRESHOLD].
4. Rank remaining findings by severity, then by exploitability.
5. For each finding, determine whether immediate escalation is required (true if severity is critical or if the finding involves authentication bypass, remote code execution, or data exfiltration paths).
6. Populate the output JSON exactly as specified.
7. If no findings meet the threshold, return the schema with an empty findings array and a diff_summary reflecting the review.

Before integrating this template into a CI/CD pipeline, test it against a golden set of diffs containing known vulnerabilities at varying severity levels. Validate that the model correctly identifies each finding, assigns appropriate CWE IDs, and respects the severity threshold. For high-risk repositories, always route findings with requires_immediate_escalation: true to a human security reviewer before merging. The [EXISTING_MITIGATIONS] placeholder is critical for reducing false positives—populate it with compensating controls such as WAF rules, input sanitization middleware, or network-level restrictions that the diff alone cannot see.

This prompt is designed to be called from a DevSecOps pipeline, a security bot, or a manual review tool, not as a one-off chat interaction. The application layer is responsible for assembling the diff, providing repository context, and enforcing the output contract. The prompt itself is a template that expects a structured diff input, a risk tolerance level, and a defined output schema. The harness must validate that the model's response conforms to the expected JSON schema before any findings are surfaced to a developer or logged to a security dashboard.

The implementation should follow a strict validate-retry-escalate pattern. First, parse the model's JSON output and validate it against a defined schema that requires finding_id, severity, cwe_id, affected_lines, description, and remediation fields. If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] block. If the second attempt also fails, log the raw output and escalate to a human security reviewer. For model choice, use a model with strong reasoning capabilities and a large context window to handle substantial diffs; a mid-tier model is sufficient for flagging common patterns, but a frontier model will produce more accurate severity assessments and fewer false positives on complex vulnerabilities.

Tool integration is critical. The harness should provide the model with a read_file tool or include relevant file snippets in the [CONTEXT] block so the model can trace the full function or class surrounding a changed line. Without this, the model is guessing at the broader logic and will produce unreliable findings. Log every invocation with the prompt version, model, diff hash, and output for auditability. Never auto-merge or auto-remediate based on this prompt's output. All findings, especially those marked CRITICAL or HIGH, must enter a human review queue. For low-severity informational findings, you may auto-post them as non-blocking comments on the PR, but the system must clearly label them as AI-generated and require a human to resolve them.