Static Analysis Finding Risk Scoring Prompt Template

This prompt is designed for security engineers, DevSecOps practitioners, and platform teams who need to move from a flat list of static analysis results to a prioritized, risk-ranked backlog. The job-to-be-done is consistent, evidence-based triage: given a single finding from a SAST or linting tool, the prompt produces a structured risk score, a priority level, and a clear justification that links exploitability, reachability, data sensitivity, and business impact. The ideal user is someone integrating AI into a security review pipeline where raw tool output is too noisy to act on directly, and where every finding must be scored against a repeatable rubric before it reaches a human reviewer or an automated remediation queue.

Use this prompt when you have a well-defined static analysis finding with enough context to reason about its risk—typically a finding ID, rule identifier, file path, line number, and a description of the vulnerable pattern. The prompt assumes you can supply the surrounding code snippet and, where relevant, deployment context such as whether the affected component faces the internet, handles sensitive data, or sits on a critical path. Do not use this prompt for real-time intrusion detection, dynamic analysis results, or findings from penetration tests where exploitability has already been demonstrated; those workflows require different evidence models and escalation paths. This prompt is also not a replacement for a CVSS calculator or a formal threat model—it is a triage accelerator that produces a defensible, auditable score when human review bandwidth is limited.

Before wiring this into a production pipeline, define your risk tolerance thresholds and calibrate the scoring factors against a set of findings your team has already triaged manually. Run the prompt against those known cases and compare the output to your ground-truth priorities. Expect to tune the factor descriptions in the prompt template to match your organization's specific data classification labels, deployment topology, and regulatory surface. The next section provides the copy-ready template; after that, the implementation harness section covers validation, retries, and human-review gates for high-severity findings.

This prompt template is the core scoring engine for a single static analysis finding. It expects a structured description of the finding, repository context, and a defined risk taxonomy. The model's job is to produce a consistent, evidence-backed risk score and priority level, not to interpret raw linter output. Use this template when you have already extracted and normalized a finding into the required input fields. Do not use it for batch triage, executive summaries, or fix generation—those are separate playbooks.

textCopy
You are a security-focused static analysis risk scorer. Your task is to evaluate a single static analysis finding and produce a risk score with clear justification.

## INPUT
- Finding: [FINDING_DESCRIPTION]
- File path: [FILE_PATH]
- Line range: [LINE_RANGE]
- Rule ID: [RULE_ID]
- Rule severity from tool: [TOOL_SEVERITY]
- Language: [LANGUAGE]
- Repository context: [REPO_CONTEXT]
- Data sensitivity classification: [DATA_SENSITIVITY]
- Deployment exposure: [DEPLOYMENT_EXPOSURE]

## SCORING DIMENSIONS
Score each dimension from 0 (none) to 4 (critical).
1. Exploitability: How easy is it for an attacker to trigger this finding?
2. Reachability: Is the vulnerable code reachable from an untrusted entry point?
3. Data Sensitivity Impact: What data or resources are at risk if exploited?
4. Business Impact: What is the blast radius in terms of system, user, or revenue impact?

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "finding_id": "string",
  "dimension_scores": {
    "exploitability": {"score": 0-4, "justification": "string"},
    "reachability": {"score": 0-4, "justification": "string"},
    "data_sensitivity_impact": {"score": 0-4, "justification": "string"},
    "business_impact": {"score": 0-4, "justification": "string"}
  },
  "composite_risk_score": 0.0-10.0,
  "priority_level": "CRITICAL|HIGH|MEDIUM|LOW|INFO",
  "scoring_notes": "string explaining the overall rationale",
  "uncertainty_flags": ["string"]
}

## CONSTRAINTS
- The composite_risk_score is the weighted average: (exploitability * 0.3) + (reachability * 0.3) + (data_sensitivity_impact * 0.2) + (business_impact * 0.2), then scaled to 0-10.
- Priority level thresholds: CRITICAL >= 8.0, HIGH >= 6.0, MEDIUM >= 4.0, LOW >= 2.0, INFO < 2.0.
- Every dimension score must have a concrete justification referencing the finding details or repository context.
- If you lack sufficient information to score a dimension confidently, set the score to 0 and add an uncertainty flag explaining what is missing.
- Do not inflate scores due to the tool's original severity. Re-evaluate independently.
- If the finding is in test code, a build script, or unreachable dead code, reflect that in reachability and exploitability.

To adapt this template, replace the square-bracket placeholders with actual values from your static analysis pipeline. The [REPO_CONTEXT] field should include relevant architectural notes, trust boundaries, and data flow summaries—not the entire codebase. The [DATA_SENSITIVITY] and [DEPLOYMENT_EXPOSURE] fields work best when populated from a pre-defined taxonomy (e.g., PII, PCI, PHI, internal-only, public-facing). If your organization uses different scoring dimensions or weights, adjust the CONSTRAINTS section and the OUTPUT_SCHEMA field names accordingly. Keep the output schema strict so downstream automation can parse scores reliably.

Before deploying, test this prompt against a golden set of 20-30 findings with known risk levels. Compare the model's composite scores and priority levels against your security team's manual assessments. Watch for score inflation on high-severity tool findings and score deflation on findings in test files. If the model consistently misjudges reachability, add a few annotated examples to the prompt showing correct reachability reasoning for your architecture. The next section covers how to wire this prompt into an application harness with validation, retries, and human review gates.

This prompt is designed to be one step in a larger static analysis triage pipeline, not a standalone chatbot interaction. The typical integration point is after a SAST tool (Semgrep, CodeQL, Fortify, etc.) has produced findings and before those findings are routed to developer queues or security review boards. The harness should call the model with one finding at a time to keep context focused and token costs predictable. Batching multiple findings in a single call risks score leakage between unrelated issues and makes per-finding validation harder.

The implementation harness must enforce a strict output contract. After receiving the model response, validate that the JSON contains all required fields (risk_score, priority_level, factor_breakdown, justification_summary), that risk_score is an integer between 1 and 10, and that priority_level is one of the allowed enum values (CRITICAL, HIGH, MEDIUM, LOW, INFO). If validation fails, retry once with the same prompt plus the validation error message appended as a [CORRECTION] block. If the retry also fails, route the finding to a human review queue with the raw model output and validation errors attached. Log every attempt—including the prompt version, model, input finding ID, output, validation result, and retry count—to your observability platform for later prompt debugging and regression analysis.

For high-risk repositories (auth services, payment systems, PII handlers), add a mandatory human approval gate for any finding scored HIGH or CRITICAL before the finding enters a developer's backlog. The harness should also compare the model's score against any existing scanner severity (e.g., CodeQL's error vs warning) and flag discrepancies greater than two severity levels for review—this catches cases where the model's risk reasoning diverges significantly from the static analysis tool's built-in assessment. Model choice matters here: prefer a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet) over smaller or faster models, because the scoring task requires multi-factor reasoning about exploitability, reachability, and business impact that smaller models tend to flatten into generic medium scores. If latency is critical, consider running the prompt asynchronously after finding ingestion rather than blocking the triage pipeline.