False Positive Triage Prompt for Security Scanners

Security scanner output is noisy. For every real vulnerability, tools like SAST, DAST, and secret scanners can generate dozens of false positives. This prompt is designed for AppSec engineers who need to triage raw scanner findings against actual code context and exploitability. It takes a scanner alert, the surrounding source code, and any relevant deployment context, then produces a classified finding with a triage rationale, evidence for dismissal or escalation, and a recommended action. Use this prompt when you need consistent, auditable triage decisions that reduce alert fatigue without missing real threats.

The ideal workflow feeds this prompt structured data: the raw scanner alert (including rule ID and severity), the relevant code snippet with file path and line numbers, and deployment context such as exposure level or authentication requirements. The prompt template expects placeholders for [SCANNER_ALERT], [CODE_SNIPPET], and [DEPLOYMENT_CONTEXT]. You should also provide an [OUTPUT_SCHEMA] that enforces a classification field (True Positive, False Positive, Uncertain), a confidence score, evidence statements, and a recommended action. For high-risk codebases, always route Uncertain classifications to a human review queue rather than auto-closing them. The prompt works best with models that support structured output or tool calling, allowing you to validate the schema before the response reaches your ticketing system.

Do not use this prompt as a replacement for a human security review on critical systems or when the finding involves novel attack chains the model has not seen. The model can reason about common vulnerability patterns and code context, but it cannot guarantee discovery of zero-day exploitation paths or complex multi-step attack chains that require deep domain expertise. Additionally, avoid using this prompt for compliance-mandated reviews where a qualified human sign-off is legally required. For those cases, use the prompt as a pre-filter to prioritize findings for human review rather than as the final decision maker. The next section provides the copy-ready template you can adapt to your scanner output format and triage workflow.

This template is the core instruction set you will send to the model. It is designed to accept a raw scanner finding, the relevant source code, and any available runtime context, then produce a structured triage verdict. The prompt forces the model to ground its reasoning in the code itself rather than the scanner's severity rating, which is the primary source of false positives in automated security pipelines. Replace every square-bracket placeholder with data from your scanner and repository before sending.

textCopy
You are an application security engineer triaging findings from an automated security scanner. Your goal is to reduce alert fatigue by classifying each finding based on code-level exploitability, not scanner severity.

## INPUT
- Scanner Finding: [FINDING_JSON]
- Relevant Source Code: [CODE_SNIPPET]
- Runtime Context (optional): [RUNTIME_CONTEXT]

## TASK
For the provided finding, determine whether it represents a true positive that requires remediation or a false positive that can be dismissed. You must ground every conclusion in the source code provided.

## CLASSIFICATION RULES
1. **True Positive**: The vulnerable pattern exists in the code AND is reachable by untrusted input OR exposes a clear security boundary. Explain the attack path.
2. **False Positive - Dead Code**: The vulnerable pattern exists but is in unreachable code, test fixtures, or build artifacts that never execute in production.
3. **False Positive - Compensating Control**: A mitigating control earlier in the request path (input validation, sanitization, auth check, WAF rule) neutralizes the exploit before it reaches the vulnerable code. Cite the specific control.
4. **False Positive - Incorrect Pattern Match**: The scanner matched a benign code pattern that resembles a vulnerability but lacks the required preconditions for exploitation. Explain why the match is invalid.
5. **Uncertain - Insufficient Context**: The provided code is insufficient to determine exploitability. Specify exactly what additional context is needed (caller code, framework config, deployment topology).

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "finding_id": "string",
  "classification": "TRUE_POSITIVE | FALSE_POSITIVE_DEAD_CODE | FALSE_POSITIVE_COMPENSATING_CONTROL | FALSE_POSITIVE_INCORRECT_MATCH | UNCERTAIN",
  "confidence": "HIGH | MEDIUM | LOW",
  "rationale": "string explaining the code-level reasoning",
  "evidence": {
    "vulnerable_line_range": "[START_LINE]-[END_LINE]",
    "mitigating_line_range": "[START_LINE]-[END_LINE] or null",
    "attack_path": "string or null if false positive",
    "missing_context": ["string"] 
  },
  "recommended_action": "ESCALATE | DISMISS | REQUEST_CONTEXT | SUPPRESS_RULE",
  "remediation_guidance": "string or null"
}

## CONSTRAINTS
- Never classify based on scanner severity alone. Always inspect the code.
- If you cannot trace a complete attack path from untrusted input to the vulnerable sink, mark as UNCERTAIN and specify what context is missing.
- For compensating controls, you must identify the specific line or function that provides the mitigation.
- Do not assume deployment context (WAF, network segmentation) unless provided in [RUNTIME_CONTEXT].
- If the finding is in a test file, dependency, or build output, explicitly note this in the rationale.

To adapt this template for your pipeline, start by mapping your scanner's output format into the [FINDING_JSON] placeholder. Most SAST tools emit a structured payload with a rule ID, file path, line range, and severity. Pass that entire object. For [CODE_SNIPPET], extract the vulnerable file plus any adjacent caller functions—at minimum 50 lines of context around the flagged line. The [RUNTIME_CONTEXT] field is optional but valuable: include deployment architecture notes, known WAF rules, or authentication middleware details when available. After the model returns a classification, route ESCALATE findings to a human reviewer, automatically close DISMISS findings with the rationale attached, and feed REQUEST_CONTEXT back into your context-gathering pipeline. For SUPPRESS_RULE outcomes, consider adding a suppression comment in your scanner config to prevent the same false positive pattern from re-alerting.

The false positive triage prompt is designed to sit downstream from a SAST, secret scanner, or dependency checker. Its job is to receive a raw finding plus surrounding code context and return a structured triage decision. The harness should be built as a stateless function that accepts a finding object, enriches it with code snippets from the repository, calls the LLM, validates the output, and routes the result to either an automated dismissal queue or a human review queue. Do not send raw scanner output directly to the model without first attaching the relevant file content, diff context, or dependency manifest excerpt—the model needs code-level evidence to distinguish false positives from exploitable findings.

Wire the prompt into a pipeline with these stages: (1) Finding ingestion—normalize scanner output into a standard schema with fields for finding_id, rule_id, file_path, line_range, message, and severity. (2) Context assembly—read the target file from the repository at the correct revision and extract a window around the flagged lines (default 40 lines before and after). For dependency findings, include the affected package entry from the lockfile and any direct usage in source. (3) LLM invocation—call the model with the prompt template, passing [FINDING], [CODE_CONTEXT], [REPOSITORY_CONTEXT], and [TRIAGE_POLICY]. Use a model with strong code reasoning (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 for deterministic triage. (4) Output validation—parse the JSON response and validate that triage_decision is one of CONFIRMED, FALSE_POSITIVE, or NEEDS_REVIEW, that confidence is a float between 0 and 1, and that evidence contains at least one concrete code reference. Reject malformed outputs and retry once with a stricter schema reminder. (5) Routing—if triage_decision is FALSE_POSITIVE and confidence >= 0.85, auto-dismiss with a logged rationale. If NEEDS_REVIEW or confidence < 0.7, escalate to a human triage queue with the full LLM output attached. If CONFIRMED, forward to the remediation workflow.

For production reliability, implement retry logic with exponential backoff (1s, 2s, 4s) on validation failures or model errors, capping at 3 attempts. Log every triage decision with the finding_id, triage_decision, confidence, model, prompt_version, and latency_ms for observability. Set up a triage accuracy dashboard that samples decisions weekly and compares them against human reviewer labels—this is your primary eval metric. If the false positive rate on CONFIRMED findings exceeds 10% or the false dismissal rate on FALSE_POSITIVE findings exceeds 5%, pause automated dismissal and investigate prompt drift or model behavior changes. Never auto-dismiss findings in repositories classified as [RISK_LEVEL] = CRITICAL without human sign-off, regardless of confidence score.

Common failure modes to instrument for: the model dismissing a real finding because the vulnerable code path appears unreachable in the extracted context window (mitigate by including call graph or import context in [REPOSITORY_CONTEXT]); the model confirming a finding based on pattern matching without understanding runtime protections like middleware sanitization (mitigate by including relevant middleware or filter chain code in the context window); and output schema drift where the model adds extra fields or changes enum values after a model version update (mitigate with strict JSON schema validation and a schema version field in the prompt). Start with a shadow mode deployment where the harness runs alongside existing manual triage for two weeks before enabling automated dismissal.