SAST Finding Exploitability Assessment Prompt

Security engineers and DevSecOps teams use this prompt to move from a raw list of static analysis findings to a risk-prioritized action queue. The core job is exploitability triage: determining whether a specific finding represents a viable attack path in a production deployment. This prompt is designed for the moment after a SAST scan completes and before findings are assigned to development teams. It prevents alert fatigue by filtering out findings that are theoretically interesting but practically unreachable due to authentication gates, network segmentation, input validation layers, or deployment architecture. The ideal user is a security engineer or senior developer who can provide the finding details, relevant code snippets, and a description of the deployment context.

To use this prompt effectively, you must supply three categories of input. First, the finding itself: the tool name, rule ID, severity, description, and the exact file paths and line numbers involved. Second, code context: the vulnerable code, any calling functions, and relevant validation or sanitization logic. Third, deployment and architecture context: how the application is deployed, which services are publicly exposed, what authentication and authorization mechanisms are in place, and what network controls exist. Without this context, the model cannot assess reachability or input controllability and will default to theoretical severity, which defeats the purpose of the assessment. The prompt is not a replacement for penetration testing, dynamic analysis, or runtime verification. It is a structured reasoning tool that helps you make faster, more consistent triage decisions at scale.

Do not use this prompt for findings where you lack deployment context or where the code is too complex to describe in a single prompt. It is also unsuitable for findings that require dynamic confirmation, such as deserialization gadgets that depend on runtime classpaths or vulnerabilities that require chaining multiple obscure components. For findings in regulated environments, always route the output through a human review step before closing or suppressing any alert. The next section provides the copy-ready prompt template you can adapt for your specific SAST tool and deployment environment.

This prompt template is designed for security engineers who need to move beyond raw SAST severity scores and determine if a finding is actually reachable and exploitable by an attacker. It forces structured reasoning about the attack path, required preconditions, and existing defenses before producing a final rating. The template is self-contained and can be pasted directly into an LLM interface after replacing the placeholders with real data from your SAST tool and deployment context.

codeCopy
You are a senior application security engineer triaging a static analysis finding. Your task is to assess whether this finding represents a genuinely exploitable vulnerability in the target production environment, or whether it is a false positive, unreachable, or mitigated by existing controls.

## INPUT

### Finding
- **Tool:** [SAST_TOOL_NAME]
- **Rule ID:** [RULE_ID]
- **Rule Description:** [RULE_DESCRIPTION]
- **Severity:** [TOOL_SEVERITY]
- **File:** [FILE_PATH]
- **Line:** [LINE_NUMBER]
- **Code Snippet:**
```[LANGUAGE]
[CODE_SNIPPET]

• Data Flow Trace (if available): [DATA_FLOW_TRACE]

Deployment Context

• Service Name: [SERVICE_NAME]
• Exposure: [INTERNET_FACING | INTERNAL_ONLY | ADMIN_ONLY | OTHER]
• Authentication Required: [YES | NO | PARTIAL]
• Authorization Model: [DESCRIBE_AUTHZ]
• Data Sensitivity: [PII | FINANCIAL | HEALTH | INTERNAL | PUBLIC | OTHER]
• Existing Mitigations: [WAF | INPUT_VALIDATION | SANITIZATION | RATE_LIMITING | NETWORK_SEGMENTATION | OTHER]
• Threat Model Notes: [ANY_RELEVANT_THREAT_MODEL_CONTEXT]

CONSTRAINTS

• Do not assume an attacker has already bypassed authentication unless the finding itself enables authentication bypass.
• Consider the full attack path from entry point to impact, not just the flagged line.
• If the code is in a test file, dead code path, or unreachable internal utility, note this explicitly.
• Distinguish between "exploitable in theory" and "exploitable given the current deployment context."
• If you lack sufficient information to make a determination, state what is missing rather than guessing.

OUTPUT_SCHEMA

Return a JSON object with the following structure: { "finding_id": "[RULE_ID]@[FILE_PATH]:[LINE_NUMBER]", "exploitability_rating": "EXPLOITABLE | LIKELY_EXPLOITABLE | UNLIKELY_EXPLOITABLE | NOT_EXPLOITABLE | INSUFFICIENT_EVIDENCE", "attack_path_reachable": true | false | "unknown", "attack_path_description": "Step-by-step description of how an attacker would reach and exploit this code path, or why it is unreachable.", "preconditions": ["List of conditions that must be true for exploitation to succeed"], "existing_defenses": ["List of existing controls that mitigate or prevent exploitation"], "impact_if_exploited": "Description of the worst-case impact if this finding were successfully exploited.", "confidence": "HIGH | MEDIUM | LOW", "evidence_chain": ["Ordered list of evidence supporting the rating, from code patterns to deployment facts"], "missing_information": ["List of facts that would change the assessment if known"], "recommended_next_steps": ["Concrete actions: manual review, dynamic testing, code fix, suppress finding, escalate"] }

EXAMPLES

Example 1: SQL Injection in Internal Admin Tool

Input: SQL injection finding in an internal admin dashboard behind VPN and SSO, with parameterized queries already used in 95% of the codebase but one concatenation found in a reporting endpoint. Output: { "finding_id": "java/sql-injection@ReportsController.java:142", "exploitability_rating": "UNLIKELY_EXPLOITABLE", "attack_path_reachable": true, "attack_path_description": "An authenticated admin user could craft a malicious report parameter that reaches the string concatenation in buildReportQuery(). However, the endpoint is only accessible after SSO authentication and VPN connection.", "preconditions": ["Valid admin SSO credentials", "Active VPN session", "Knowledge of the internal report parameter structure"], "existing_defenses": ["VPN restricts network access to employees only", "SSO enforces MFA for all admin accounts", "Audit logging captures all report queries"], "impact_if_exploited": "An authenticated insider could extract arbitrary data from the reporting database, which contains aggregated business metrics but no PII.", "confidence": "MEDIUM", "evidence_chain": ["Code review confirms string concatenation in query builder", "Deployment config confirms VPN-only access", "IAM policy confirms SSO enforcement", "Data classification confirms no PII in reporting DB"], "missing_information": ["Whether the reporting database has read-replica access to sensitive tables", "Whether audit logs are reviewed for anomalous queries"], "recommended_next_steps": ["Fix the string concatenation to use parameterized query for consistency", "No emergency escalation required", "Add to next sprint backlog as low-priority hardening"] }

codeCopy

Copy the template above into your LLM interface. Replace every `[PLACEHOLDER]` with real data from your SAST tool output and deployment context. The more complete your deployment context, the more accurate the exploitability assessment will be. If your SAST tool provides a data flow trace, include it verbatim—the model can reason about taint propagation and sanitizer placement better when it sees the full path.

After running the prompt, validate the output JSON against the schema before using the result in any automated pipeline. If the exploitability_rating is INSUFFICIENT_EVIDENCE, route the finding to a human security engineer with the missing_information list as an investigation guide. For findings rated EXPLOITABLE or LIKELY_EXPLOITABLE, the evidence_chain field serves as documentation for your vulnerability management system and should be preserved alongside the finding for auditability.

This prompt is designed to operate as a decision-support step inside a larger SAST triage pipeline, not as a standalone chatbot. The model receives a single finding, its surrounding code context, and deployment metadata, then returns a structured exploitability assessment. The calling application is responsible for fetching the right context, enforcing the output schema, and deciding what happens next based on the assessment. Do not expose this prompt directly to end users or allow free-form follow-up questions without guardrails.

Wire the prompt into your pipeline by building a thin orchestration layer that performs the following steps for each finding: (1) Fetch the finding details from your SAST tool's API or export. (2) Retrieve the relevant source file snippet, including the flagged line and 20-30 lines of surrounding context. (3) Pull deployment context from your CMDB or infrastructure-as-code repo: is the affected service internet-facing? What authentication and authorization controls sit in front of it? What WAF, input validation, or sanitization layers exist? (4) Assemble these into the [FINDING_DETAILS], [CODE_CONTEXT], and [DEPLOYMENT_CONTEXT] placeholders. (5) Call the model with the prompt template and validate the response against the expected JSON schema before proceeding. (6) Route the result: findings rated EXPLOITABLE or LIKELY_EXPLOITABLE should create a high-priority ticket or block the release; UNLIKELY findings can be logged for periodic review; NOT_EXPLOITABLE findings with strong evidence can be auto-suppressed with an audit trail.

Validation and retry logic are critical because the output drives security decisions. Implement a JSON schema validator that checks for the required fields (exploitability_rating, attack_path_summary, evidence_chain, confidence_score) and enforces the enum values for exploitability_rating. If validation fails, retry once with the same input and an added instruction to correct the specific schema error. If the second attempt fails, log the finding for human review and do not auto-suppress. For model choice, use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because exploitability assessment requires multi-step causal reasoning about attack paths and control interactions. Avoid smaller or faster models for this task unless you have calibrated their performance on your specific finding types and codebase.

Human review gates are non-negotiable for findings rated EXPLOITABLE or LIKELY_EXPLOITABLE. The model's assessment should accelerate triage, not replace security engineering judgment. Route these findings to a review queue with the full model output, the original finding, and a link to the code. For UNCERTAIN findings, batch them for weekly review by the security team to identify patterns and improve the prompt's context or examples. Log every assessment with the model version, prompt version, input context, and output for auditability. This log becomes your evidence trail for compliance reviews and your dataset for evaluating prompt changes over time.

Do not use this prompt in a fully automated blocking pipeline without a human review step for high-severity findings. The model can misjudge exploitability when deployment context is incomplete, when custom framework behaviors are not described in the code context, or when novel attack techniques are involved. Start with a shadow mode deployment where the model's assessments are logged alongside human triage decisions for 2-4 weeks. Compare agreement rates, identify systematic errors, and tune the prompt's [CONSTRAINTS] and [EXAMPLES] sections before moving to partial automation. Even after tuning, maintain the human review gate for EXPLOITABLE findings and periodically audit NOT_EXPLOITABLE classifications to catch drift.