Risk Ranking Prompt for SAST Findings

Security engineering teams face a common bottleneck: a backlog of hundreds or thousands of static analysis findings, all marked 'High' or 'Critical' by the tool, with no way to distinguish the one finding that could lead to a breach from the hundred that are unreachable in production. This prompt ranks SAST findings by actual risk using exploitability, reachability, asset criticality, and existing mitigations rather than raw severity scores. Use it when you need a prioritized remediation queue that reflects real-world impact, not tool defaults.

The prompt expects structured finding data and deployment context. You must supply a list of findings with fields like finding ID, rule ID, severity, file path, and line number. You also need deployment context: whether the affected code is reachable in production, the asset's criticality tier, any existing mitigations like WAF rules or network segmentation, and the data classification level. The prompt works best when findings are pre-deduplicated and false positives are already filtered out. It does not replace human security review for novel vulnerability classes, architecture-level threats, or findings where exploitability cannot be determined from static context alone.

Do not use this prompt as a substitute for a threat model or a penetration test. It ranks known findings, not unknown risks. If your input data lacks deployment context, the prompt will default to conservative rankings that may not improve over tool defaults. Wire the output into your ticketing system or remediation pipeline, but always include a human review gate for findings ranked above a defined risk threshold. The next section provides the copy-ready prompt template you can adapt with your own finding schema and risk taxonomy.

This prompt template ingests raw SAST findings and produces a prioritized list ranked by exploitability, reachability, asset criticality, and existing mitigations rather than relying solely on the tool's default severity score. Replace each square-bracket placeholder with real data before sending to the model. The template expects structured input describing each finding's location, rule metadata, data flow context, and deployment environment. If your SAST tool does not provide reachability or asset context, populate those fields with available evidence or mark them as unknown—the model will adjust confidence accordingly.

textCopy
You are a security engineering analyst reviewing static analysis findings. Your task is to rank findings by actual risk to the organization, not by raw severity scores.

## INPUT FINDINGS
[FINDINGS_JSON_ARRAY]

Each finding object contains:
- finding_id: unique identifier
- rule_id: SAST rule that fired
- severity: tool-assigned severity (Critical/High/Medium/Low)
- file_path: location in codebase
- line_range: affected lines
- description: what the rule detected
- data_flow: taint source, propagation steps, and sink if available
- reachability: whether the code path is reachable from an external entry point (Reachable/Unreachable/Unknown)
- authentication_required: whether the endpoint or function requires authentication (Yes/No/Unknown)
- input_controllability: degree to which an attacker controls input (Full/Partial/None/Unknown)
- asset_criticality: criticality of the affected service or data store (Critical/High/Medium/Low/Unknown)
- existing_mitigations: compensating controls already in place (WAF, input validation, sanitization, sandboxing, network segmentation, none, unknown)
- deployment_environment: where the code runs (Production/Staging/Development/Internal-only)

## RANKING CRITERIA
Rank findings by actual risk using this weighted framework:
1. Exploitability (40%): Combine reachability, authentication_required, and input_controllability. A finding reachable from an unauthenticated external endpoint with full attacker input control is highest risk.
2. Asset Impact (30%): Asset criticality and deployment environment. Production critical assets score highest.
3. Mitigation Defeat (20%): Existing mitigations that reduce or eliminate exploitability lower the risk score.
4. Severity Baseline (10%): Use tool severity as a starting point but never as the sole factor.

## OUTPUT FORMAT
Return a JSON object with this exact structure:
{
  "ranked_findings": [
    {
      "rank": integer starting at 1,
      "finding_id": string,
      "risk_score": float between 0.0 and 100.0,
      "risk_category": "Critical" | "High" | "Medium" | "Low" | "Informational",
      "ranking_rationale": string explaining why this finding received this rank, referencing specific evidence from the input fields,
      "confidence": "High" | "Medium" | "Low",
      "confidence_factors": [string array of factors that increase or decrease confidence],
      "requires_human_review": boolean,
      "review_reason": string or null if human review not required
    }
  ],
  "ranking_summary": {
    "total_findings": integer,
    "critical_count": integer,
    "high_count": integer,
    "medium_count": integer,
    "low_count": integer,
    "informational_count": integer,
    "human_review_required_count": integer,
    "highest_risk_finding_id": string,
    "methodology_notes": string describing any assumptions or limitations in the ranking
  }
}

## CONSTRAINTS
- Never rank an unreachable finding above a reachable one with similar characteristics.
- If confidence is Low, requires_human_review must be true.
- If asset_criticality is Unknown, assume Medium and note this in confidence_factors.
- If reachability is Unknown, treat as potentially reachable but lower confidence.
- Do not invent evidence. Only use fields provided in the input.
- If input fields are missing or null, note this in confidence_factors and adjust confidence downward.
- Produce exactly one ranked_findings entry per input finding. Do not drop findings.

After pasting this template, replace [FINDINGS_JSON_ARRAY] with your actual SAST output serialized as a JSON array of finding objects. If your SAST tool does not natively produce fields like reachability or asset_criticality, you have two options: enrich the findings in your application layer before calling the model, or populate those fields with "Unknown" and accept lower confidence scores. For high-risk codebases, prefer enrichment. Wire the output through a JSON schema validator before consuming it in your ticketing or remediation workflow. If any finding returns requires_human_review: true, route it to a security engineer's queue rather than auto-assigning it to a developer. Test this prompt against a golden dataset of 20-30 findings with known risk rankings before deploying to production.

This prompt is designed to be a decision-support node inside a larger SAST triage pipeline, not a standalone chatbot. The primary integration point is after findings have been deduplicated and false positives filtered. The application should feed the prompt a batch of deduplicated, likely-true-positive findings, each enriched with asset context, and receive a ranked list with rationales. The output is consumed by a downstream routing system that assigns high-ranked findings to on-call engineers and low-ranked findings to a weekly review queue.

Input assembly is the most critical implementation step. Before calling the model, the harness must join each SAST finding with its deployment context: reachability data from the runtime environment, asset criticality from the CMDB or service catalog, and any existing mitigations from the WAF or network policy. This context is injected into the [FINDING_CONTEXT] placeholder. A strict JSON schema must be provided in [OUTPUT_SCHEMA] to enforce the ranked list structure, including required fields for rank, finding_id, risk_score, rationale_summary, and confidence. The [CONSTRAINTS] field should explicitly instruct the model to output only valid JSON matching the schema, with no additional commentary.

Validation and error handling must be implemented in the application layer. After receiving the model response, the harness must validate the JSON structure, confirm that all input finding_id values are present in the output, and check that risk_score values are within the expected range. If validation fails, implement a single retry with the error message injected into the [PREVIOUS_ERROR] field of the retry prompt. If the retry also fails, log the failure and route the batch to a human triage queue. Do not silently drop findings or proceed with a malformed ranking.

Model choice and latency are important trade-offs. For high-volume pipelines processing hundreds of findings per commit, use a fast, cost-effective model like claude-3-haiku or gpt-4o-mini with a strict token limit. For weekly deep-dive reviews of the top 10 findings across a monorepo, a more capable model like claude-3.5-sonnet or gpt-4o can produce richer rationales and higher-confidence exploitability assessments. Implement a feature flag to switch between model tiers based on the batch's risk profile or the consuming workflow's SLA.

Observability and audit are non-negotiable for security workflows. Log every prompt request and response, including the full input context, the raw model output, the validation result, and the final ranked list. Attach a unique trace_id to each batch so that downstream ticket creation and remediation tracking can be linked back to the ranking decision. This audit trail is essential for answering questions like 'Why was this critical finding ranked below that medium one?' during post-incident reviews or compliance audits.

Human-in-the-loop integration should be implemented as a review gate for high-risk or low-confidence rankings. If the model assigns a confidence score below a configurable threshold (e.g., 0.7) to any finding in the top 10, or if the risk_score gap between adjacent findings is very small, flag the batch for human review before routing. The review interface should display the original findings, the model's ranking and rationale, and allow a security engineer to reorder, override, or approve the list. This feedback can be logged and used to fine-tune the prompt or build evaluation datasets over time.