SAST Finding Severity Triage Prompt Template

Security and platform engineering teams often face thousands of raw SAST findings per scan. Manual triage is slow, inconsistent, and prone to alert fatigue. This prompt ingests raw SAST output with code context, deduplicates related findings, filters likely false positives with explicit reasoning, and ranks the remaining issues by exploitability and business impact. Use it when you need a structured, repeatable first-pass triage that integrates into your vulnerability management workflow. It is designed for teams that already have a SAST tool in CI/CD and need to reduce the queue of findings before human review.

The ideal user is a DevSecOps engineer or application security specialist who can provide the raw SAST output, the relevant code snippets, and a defined [RISK_LEVEL] threshold for escalation. The prompt requires that each finding be accompanied by its source code context; without it, the model cannot reliably distinguish a true positive from a false positive. You should also supply a [CONTEXT] block describing the application's business function, data sensitivity, and exposure level, as this directly informs the business impact ranking. Do not use this prompt for runtime vulnerability data, penetration test reports, or findings without associated code snippets. It is not a replacement for a SAST tool, but a force-multiplier for the triage step that follows a scan.

Before putting this into production, you must establish a ground-truth baseline. Run the prompt against a set of manually triaged findings and measure agreement on severity classification, false-positive filtering, and deduplication. A common failure mode is the model accepting a sanitized input as safe when the sanitization function itself is flawed; always include the implementation of any called validation or encoding function in the [CODE_SNIPPETS] input. Another failure mode is the model over-prioritizing findings based on CWE severity alone without considering the application's specific exposure. Mitigate this by being precise in the [CONTEXT] block about what an attacker could actually reach. The next step is to wire this prompt into an automated harness that validates the output schema, logs every triage decision for audit, and routes high-severity findings for mandatory human review.

The following prompt template is designed to be copied directly into your AI harness. It accepts a batch of raw SAST findings, relevant code context, and your organization's triage rules. The model is instructed to deduplicate related findings, filter likely false positives with explicit reasoning, and rank the remaining true positives by exploitability and business impact. Every placeholder is enclosed in square brackets and must be replaced with real data before execution. The output is a structured JSON object that can be validated and ingested by your vulnerability management system.

textCopy
You are a senior application security engineer triaging static analysis (SAST) findings for a production application. Your goal is to reduce alert fatigue by deduplicating related findings, filtering false positives with clear reasoning, and ranking true positives by risk.

## INPUT
- **SAST Findings:** [SAST_FINDINGS_JSON]
- **Code Context:** [CODE_CONTEXT_SNIPPETS]
- **Application Profile:** [APPLICATION_PROFILE]
- **Triage Rules:** [TRIAGE_RULES]

## INSTRUCTIONS
1. **Deduplicate:** Group findings that share the same root cause, code location, or data flow path. For each group, select the most representative finding and note the duplicates.
2. **False Positive Analysis:** For each unique finding, determine if it is a false positive. A finding is a false positive if:
   - The data path is blocked by a sanitizer, validator, or guard that the scanner did not model.
   - The vulnerable code is unreachable in the application's runtime configuration.
   - The finding relies on an incorrect assumption about the code's behavior.
   Provide a concise reason for every false positive classification.
3. **Severity Triage:** For each true positive, assign a final severity based on the [TRIAGE_RULES]. Consider:
   - **Exploitability:** Attack vector, attack complexity, privileges required, user interaction.
   - **Business Impact:** Data sensitivity, system criticality, blast radius.
   Override the scanner's original severity if warranted.
4. **Ranking:** Sort all true positives from highest to lowest risk.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "findings": [
    {
      "id": "string (original finding ID)",
      "title": "string",
      "original_severity": "string",
      "final_severity": "string (Critical|High|Medium|Low|Info)",
      "is_false_positive": boolean,
      "false_positive_reason": "string | null",
      "duplicate_of": "string | null (ID of the representative finding)",
      "exploitability_assessment": "string",
      "business_impact": "string",
      "remediation_priority": "integer (1 = highest)"
    }
  ],
  "summary": {
    "total_raw_findings": integer,
    "deduplicated_count": integer,
    "false_positives_count": integer,
    "true_positives_count": integer,
    "highest_risk_finding_id": "string"
  }
}

## CONSTRAINTS
- Do not invent vulnerabilities or code that is not present in the input.
- If the code context is insufficient to make a determination, set `is_false_positive` to false and note the missing context in the assessment.
- Never downgrade a finding without a specific, evidence-backed reason.
- If [TRIAGE_RULES] specify a mandatory escalation for certain conditions, reflect that in the `final_severity`.

To adapt this template for your pipeline, replace each placeholder with real data. [SAST_FINDINGS_JSON] should be a JSON array of raw findings from your scanner (e.g., Semgrep, CodeQL, Checkmarx). [CODE_CONTEXT_SNIPPETS] should include the relevant source files or diff hunks that surround each finding. [APPLICATION_PROFILE] describes the application's runtime environment, exposure, and data classification. [TRIAGE_RULES] encodes your organization's severity definitions, escalation criteria, and acceptable risk thresholds. After the model returns a response, validate the JSON structure against the schema before ingesting it into your vulnerability management system. For high-risk findings, always require human review before closing or deferring.

Integrating the SAST Finding Severity Triage prompt into a production pipeline requires treating it as a deterministic step in a vulnerability management workflow, not a conversational query. The prompt expects a batch of raw SAST findings with associated code snippets, rule metadata, and repository context. Your harness should assemble this payload from your SAST tool's output (e.g., Semgrep JSON, CodeQL SARIF, Checkmarx XML) and normalize it into the [SAST_FINDINGS] structure before calling the model. The harness must also inject [TRIAGE_POLICY]—a string containing your organization's severity definitions, exploitability criteria, and business impact tiers—so the model's ranking aligns with your internal risk appetite rather than generic CVSS assumptions. Without this policy injection, the model will default to textbook severity ratings that may not match your threat model or asset criticality.

The implementation should wrap the model call in a validation and retry layer. After receiving the model's JSON output, validate it against the expected [OUTPUT_SCHEMA] before any downstream action. Check that every finding in the input has a corresponding triage entry, that severity values are within your defined enum, that deduplication groups reference valid finding IDs, and that false-positive classifications include a reasoning string. If validation fails, construct a retry prompt that includes the original input, the malformed output, and a specific error message describing the schema violation. Limit retries to a maximum of 2 attempts before flagging the batch for human review. Log every attempt—input hash, model response, validation errors, and retry count—so you can diagnose whether failures stem from prompt ambiguity, model inconsistency, or edge-case input shapes. For high-risk repositories (e.g., payment systems, auth services), add a mandatory human approval gate after successful validation: route findings classified as CRITICAL or HIGH to a security engineer's review queue before they appear in the developer's backlog.

Model choice matters for this workflow. Use a model with strong reasoning capabilities and a large context window, as a single batch may contain dozens of findings with code context. If your SAST output is large, implement a pre-processing splitter that groups findings by file or rule category and processes batches of no more than 15-20 findings per call to stay within reliable attention limits. For cost and latency optimization, cache the [TRIAGE_POLICY] and [OUTPUT_SCHEMA] as a reusable system prompt prefix. If you have a labeled dataset of manually triaged findings, run this prompt against it before deployment and measure agreement on severity classification, false-positive detection, and deduplication grouping. Set a minimum agreement threshold (e.g., 85% on severity, 90% on false-positive recall) as a release gate. When the model's output disagrees with ground truth, log those cases as eval failures for prompt iteration. Do not deploy this prompt without first establishing a baseline accuracy measurement against your own historical triage data.