Security-Relevant Code Change Diff Review Prompt Template

This prompt is designed for security reviewers and AppSec engineers who need to triage pull requests for changes that alter the security posture of an application. It takes a raw code diff as input and produces a structured, first-pass security review. The goal is not to replace a human reviewer or a full penetration test, but to act as a consistent triage accelerator. It flags security-relevant changes—such as modifications to authentication logic, cryptographic primitives, input handling, permission boundaries, and data flows—and explains why they matter, allowing a human reviewer to focus their attention on the highest-risk changes first.

To use this prompt effectively, you must provide a complete and well-formed unified diff as the [CODE_DIFF] input. The prompt works best when the diff is scoped to a single, coherent change, such as one pull request. It is less effective on massive, unfocused diffs spanning hundreds of files, where the signal-to-noise ratio degrades. You should also supply a [RISK_LEVEL] parameter (e.g., 'low', 'medium', 'high', 'critical') to calibrate the review's depth and urgency. The prompt is designed to be wired into a CI/CD pipeline, where it can automatically comment on pull requests with its findings before a human ever looks at the code.

Do not use this prompt as a substitute for a formal threat model, a penetration test, or a manual security review for high-assurance systems. It is a triage tool, not a guarantee of security. It can miss context-dependent vulnerabilities, business logic flaws, and novel attack patterns that fall outside its defined categories. For changes in regulated environments or those handling highly sensitive data, the output of this prompt must always be reviewed and signed off on by a qualified human. The next step after reading this section is to copy the prompt template and adapt the [OUTPUT_SCHEMA] and [CONSTRAINTS] to match your team's specific security review taxonomy.

This prompt template is designed to be the core instruction set you send to a model when reviewing a pull request diff for security-impacting changes. It forces the model to act as a disciplined security reviewer, not a general-purpose code assistant. The template uses square-bracket placeholders for all variable inputs—your diff content, your organization's security policies, your risk tolerance, and your expected output format. Before using this prompt, you must replace every placeholder with concrete values. Leaving a placeholder unresolved will produce unpredictable or incomplete results.

textCopy
You are a senior application security engineer conducting a focused security review of a code change diff. Your review must be precise, evidence-based, and actionable. Do not comment on style, performance, or general code quality unless it has a direct security implication.

## Review Context
- **Change Purpose:** [CHANGE_DESCRIPTION]
- **Risk Appetite:** [RISK_LEVEL: low | medium | high | critical]
- **Security Policies:** [POLICY_DOCUMENTS_OR_RULES]
- **Threat Model Reference:** [THREAT_MODEL_CONTEXT]

## Input Diff
```diff
[CODE_DIFF]

Review Instructions

Analyze the diff for the following security-relevant change categories. For each finding, provide the exact file path, line range, a severity rating, and a concise explanation grounded in the code change itself.

1. Authentication and Authorization Changes

• Modifications to login, session management, token handling, or password flows.
• Changes to role checks, permission logic, middleware, or access control lists.
• Any new or removed authorization gates.

2. Cryptographic and Secrets Handling

• Changes to encryption, hashing, key generation, or key storage.
• Hardcoded secrets, API keys, tokens, or certificates.
• Use of deprecated or weak cryptographic algorithms.

3. Input Handling and Injection Risks

• New or modified user input paths, file uploads, or deserialization points.
• Changes to SQL queries, shell commands, or dynamic code execution.
• Output encoding modifications that could affect XSS defenses.

4. Data Flow and Sensitive Data Exposure

• New data flows that transmit, store, or log sensitive data (PII, credentials, financial data).
• Changes to logging statements that might expose sensitive information.
• Modifications to data export, serialization, or API response shapes.

5. Permission and Trust Boundary Changes

• Modifications to network policies, firewall rules, or service-to-service authentication.
• Changes to file permissions, container security contexts, or sandbox configurations.
• New external dependencies or third-party service integrations.

Output Format

Return a JSON object with the following structure. If no security-relevant changes are found in a category, return an empty array for that key.

jsonCopy
{
  "summary": "A one-paragraph summary of the overall security impact of this change.",
  "findings": {
    "auth_and_authz": [
      {
        "severity": "critical | high | medium | low | informational",
        "file": "path/to/file.ext",
        "line_range": "L10-L25",
        "finding": "Concise description of the security issue.",
        "evidence": "Relevant code snippet from the diff.",
        "remediation": "Specific, actionable fix guidance."
      }
    ],
    "crypto_and_secrets": [],
    "input_handling": [],
    "data_flow": [],
    "permission_boundary": []
  },
  "risk_assessment": {
    "overall_severity": "critical | high | medium | low | informational",
    "requires_immediate_action": true,
    "requires_human_review": true,
    "blocking_issues": ["List of issues that should block merge"],
    "recommendation": "approve | approve_with_comments | request_changes | block"
  }
}

Constraints

• Only report findings you can directly link to code in the diff.
• Do not speculate about code you cannot see.
• If the diff is incomplete or lacks context for a definitive assessment, note this in the finding and recommend human follow-up.
• Severity ratings must reflect the organization's risk appetite specified above.
• If you detect a critical-severity finding, set requires_human_review to true and explain why.

To adapt this template for your own pipeline, start by replacing the policy and threat model placeholders with references to your internal documentation or a summarized version of your security standards. If you don't have formal threat models, replace [THREAT_MODEL_CONTEXT] with a brief description of the service's trust boundaries and critical assets. The [RISK_LEVEL] placeholder should map to your deployment context—a public-facing payment service warrants critical, while an internal dashboard might use medium. After adapting the prompt, run it against a set of known-good and known-bad diffs to calibrate severity thresholds and false positive rates before integrating it into your CI pipeline.

This prompt is designed to operate as a gating step in a pull request workflow, not as a standalone chatbot. The implementation harness must receive a structured diff (unified format) and repository metadata, invoke the model, validate the output against the expected JSON schema, and route findings to the appropriate review queue. Because the prompt analyzes security-impacting changes—auth modifications, crypto shifts, input handling, permission boundaries, and new data flows—the harness must treat schema validation failures and high-severity classifications as blocking events that prevent automatic merge.

Wire the prompt into your CI/CD system (GitHub Actions, GitLab CI, Jenkins) as a required check that triggers on PR creation and new commits. The harness should: (1) extract the diff using git diff origin/main...HEAD or the platform's diff API; (2) assemble the prompt with the diff in the [DIFF] placeholder, the PR title and description in [CONTEXT], and the repository's security policy or risk tolerance in [RISK_LEVEL]; (3) call the model with response_format set to the defined JSON schema and a low temperature (0.1–0.2) for consistency; (4) validate the response against the schema—reject and retry (up to 2 attempts) if findings is not an array, severity is not one of the allowed enum values, or required fields are missing; (5) log every invocation with the prompt version, model, diff hash, and raw response for auditability. For high-risk repositories, route all CRITICAL and HIGH findings to a human security reviewer via your ticketing system or chat platform before the PR can merge. MEDIUM and LOW findings can be posted as non-blocking PR comments with remediation suggestions.

Model choice matters here. Use a model with strong code reasoning capabilities and a large context window (128K+ tokens) to handle substantial diffs without truncation. If the diff exceeds the context window, preprocess it by filtering to security-relevant file paths (e.g., auth/, crypto/, middleware, input validation, configuration) before assembly. Do not summarize the diff—the model needs line-level context to produce accurate file paths and line numbers. Implement a caching layer for unchanged files across commits to reduce token consumption. The harness should also track false positive rates over time by comparing model findings against human reviewer dispositions; if the false positive rate exceeds 20%, recalibrate the [RISK_LEVEL] parameter or add few-shot examples of dismissed patterns. Finally, never allow the model's output to directly apply patches or close security findings—the harness must enforce human-in-the-loop for any remediation action.