Code Security Flaw Detection Prompt

This prompt is designed for DevSecOps pipelines that need a binary pass/fail gate on AI-generated or human-authored code changes before they merge. It classifies vulnerabilities by OWASP category and severity, producing a structured verdict that can block a build, flag a pull request, or route code for manual review. Use this when you need a consistent, automatable security review that maps to your existing static analysis tooling and vulnerability management process.

The ideal user is a platform engineer, security champion, or DevSecOps lead integrating AI review into a CI/CD pipeline. Required context includes the code diff or full file, the target language, and a defined severity threshold (e.g., CRITICAL or HIGH) that triggers a block. You can optionally supply a list of OWASP categories to ignore, such as A01:2021-Broken Access Control if that surface is handled by a separate gateway. The prompt works best on backend services, API handlers, and infrastructure-as-code where common patterns like SQL injection, hardcoded secrets, and missing input validation are detectable from structure alone.

This is not a replacement for dedicated SAST tools or manual penetration testing. It is a high-speed triage layer that catches common patterns and reduces the review burden on security engineers. Do not use this prompt for cryptographic algorithm review, business logic abuse cases, or compliance audits that require regulatory evidence. The model may miss context-dependent vulnerabilities, produce false positives on test fixtures, or misclassify severity when the full call graph is unavailable. Always pair this gate with a human review step for flagged findings and periodically calibrate false-positive rates against your SAST tool baseline.

This template performs a structured security review of provided code, producing a binary safe or flagged verdict per security category. It is designed to be dropped into a DevSecOps pipeline where AI-generated or developer-submitted code needs automated pre-review before static analysis or human audit. The prompt enforces a strict JSON output schema, requires evidence for every finding, and maps vulnerabilities to OWASP categories for downstream tool integration.

codeCopy
You are a security-focused code reviewer. Your task is to analyze the provided code for security flaws and produce a structured finding per category.

## INPUT
Code to review:

[CODE]

codeCopy

Language: [LANGUAGE]
Context (optional): [CONTEXT]

## SECURITY CATEGORIES TO CHECK
[CATEGORIES]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "findings": [
    {
      "category": "string (must match one of the provided categories)",
      "verdict": "safe | flagged",
      "severity": "critical | high | medium | low | informational",
      "owasp_id": "string (e.g., A03:2021-Injection) or null if safe",
      "cwe_id": "string (e.g., CWE-89) or null if safe",
      "line_numbers": ["string range or line reference"],
      "description": "string (concise technical description of the flaw)",
      "evidence": "string (exact code snippet demonstrating the flaw)",
      "remediation": "string (specific fix guidance)",
      "false_positive_risk": "low | medium | high"
    }
  ],
  "summary": {
    "total_categories_checked": number,
    "flagged_count": number,
    "safe_count": number,
    "overall_verdict": "safe | flagged"
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. Check every category listed in [CATEGORIES], even if you believe the code is safe.
2. For each finding marked "flagged", you MUST include the exact code snippet as evidence.
3. Map every finding to the most specific OWASP Top 10 (2021) and CWE identifier applicable.
4. If a category is not applicable to the code (e.g., SQL injection check for code with no database calls), mark it "safe" and explain briefly.
5. Do not flag the same flaw under multiple categories; choose the most specific category.
6. Set `false_positive_risk` to "high" if the pattern could be safe in certain contexts (e.g., parameterized dynamic SQL).
7. If the code is incomplete or lacks sufficient context to make a determination, note this in the description and set severity to "informational".
8. Do not invent vulnerabilities. Only flag what you can support with evidence from the provided code.

Adaptation guidance: Replace [CODE] with the code snippet under review. Set [LANGUAGE] to the programming language for context-aware analysis. Use [CONTEXT] to provide architectural notes, dependency versions, or deployment environment details that affect risk assessment. Populate [CATEGORIES] with a JSON array of security categories to check, such as ["SQL Injection", "Cross-Site Scripting", "Authentication Bypass", "Insecure Deserialization", "Hardcoded Secrets", "Path Traversal", "Command Injection"]. Use [CONSTRAINTS] to add organization-specific policies, such as compliance frameworks (SOC 2, PCI DSS), internal coding standards, or severity thresholds that trigger mandatory human review. For CI/CD integration, set [CONSTRAINTS] to include a statement like "If any finding has severity 'critical' or 'high', the overall_verdict must be 'flagged' regardless of other safe categories." This prompt is designed for single-pass evaluation; for large codebases, chunk the input by file or function and aggregate findings in your application layer.

The Code Security Flaw Detection Prompt is designed to operate as a gate in a CI/CD pipeline or as an asynchronous review step in a pull-request workflow. The prompt expects a complete code snippet or diff as [INPUT], an optional [LANGUAGE] identifier to improve classification accuracy, and a [SEVERITY_THRESHOLD] to control which findings are returned. The output is a structured JSON object containing a verdict field (SAFE or FLAGGED), an array of findings with CWE identifiers, severity levels, and line references, and a coverage_map indicating which OWASP Top 10 categories were checked. The harness must validate this output shape before any downstream system acts on it, because a malformed JSON response from the model should be treated as a system error, not a passing security review.

Wire the prompt into your application by first constructing the model request with explicit response_format set to json_object (or the equivalent structured output mode for your model provider). After receiving the response, run a schema validator that checks for the presence of the verdict, findings, and coverage_map fields, and confirms that verdict is exactly SAFE or FLAGGED. If validation fails, retry once with a repair prompt that includes the original input, the malformed output, and the validation error message. If the retry also fails, log the failure and escalate to a human reviewer. For high-risk repositories, configure the harness to require human approval whenever the verdict is FLAGGED and the maximum severity in findings is CRITICAL or HIGH. This prevents automated blocking of deployments based on a single model call without human judgment.

Calibrate false positives by running the prompt against a golden dataset of known-safe code samples and known-vulnerable samples that have been verified by static analysis tools such as Semgrep or CodeQL. Track the false-positive rate per CWE category and per severity level. If the model consistently flags a particular pattern as vulnerable when static analysis tools do not, add a [CONSTRAINTS] section to the prompt that explicitly instructs the model to ignore that pattern or to require additional evidence before flagging. Log every model verdict alongside the commit hash, the static analysis results, and the eventual human disposition (confirmed, false positive, or ignored). This log becomes your calibration dataset for tuning the prompt, adjusting the severity threshold, or deciding when to fine-tune a smaller model on your organization's specific codebase patterns.

For production deployment, run the prompt in parallel with your existing static analysis tools rather than replacing them. Use the model's coverage_map to identify OWASP categories that your static analysis rules do not cover, and route those findings for prioritized human review. Set a latency budget: if the model call exceeds 5 seconds, fall back to static-analysis-only results and log the timeout for investigation. Never allow a model timeout or error to block a deployment pipeline unless your organization has explicitly chosen a hard-gate policy. The safest default is to let static analysis results govern the pipeline and use the model's output as an additional review signal that appears in the PR interface alongside the static analysis findings.