Security Scan Results Triage Prompt for Release

This prompt is designed for AppSec engineers and security-minded QA leads who need to process raw automated security scan results—from SAST, DAST, SCA, or container scanning tools—and produce a release-focused triage report. The core job-to-be-done is converting a noisy list of findings into a prioritized, actionable set of decisions that clearly states which vulnerabilities block the release, which can be deferred with compensating controls, and which are false positives. The ideal user has access to the raw scan output, the application's threat model or security context, and the authority to recommend a disposition for each finding.

Use this prompt when you have a batch of scan results that must be evaluated against a specific release's risk tolerance and deployment context. It is most effective when the input includes finding identifiers, descriptions, severity scores, CVSS vectors, affected components, and any available exploitability indicators. The prompt expects you to supply the release's risk profile, such as internet-facing vs. internal-only deployment, data sensitivity, and any compensating controls already in place. Do not use this prompt for real-time intrusion detection alert triage, for compliance-only scans where every finding must be remediated regardless of risk, or for penetration test reports that require narrative-style analysis rather than structured disposition. It is also unsuitable when the scan tool's severity ratings are the only decision factor and no human security judgment is required.

Before running this prompt, ensure you have normalized the scan results into a consistent format. The prompt works best with structured input, not raw tool output. You should also define your release's security gates in advance—for example, 'no Critical with known exploit' or 'no High in authentication modules'—so the model can apply them consistently. After receiving the output, a human AppSec reviewer must validate each blocking recommendation, especially for findings where exploitability is inferred rather than proven. The prompt is a force-multiplier for triage, not a replacement for security review. Next, move to the prompt template section to copy and adapt the base template for your toolchain and risk thresholds.

This prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It accepts raw security scan output, release context, and your organization's risk tolerance, then returns a structured, prioritized finding list. Every placeholder is enclosed in square brackets and must be replaced with concrete values before execution. The template enforces a strict output schema so that downstream automation—such as ticketing systems or release dashboards—can consume the results without manual reformatting.

textCopy
You are an application security triage specialist reviewing automated security scan results for an upcoming software release. Your goal is to determine which findings block the release and which can be deferred, with clear justification for each disposition.

## INPUT
Scan results (JSON or markdown table):
[SCAN_RESULTS]

Release context:
- Application name and version: [APP_NAME] [VERSION]
- Deployment environment: [ENVIRONMENT]
- Internet-facing: [IS_INTERNET_FACING]
- Data classification handled: [DATA_CLASSIFICATION]
- Regulatory requirements: [REGULATORY_REQUIREMENTS]
- Known compensating controls: [COMPENSATING_CONTROLS]

## CONSTRAINTS
- Organization risk tolerance: [RISK_TOLERANCE]
- CVSS threshold for automatic blocking: [CVSS_BLOCK_THRESHOLD]
- Exploitability must be assessed in the context of [DEPLOYMENT_CONTEXT]
- Do not recommend blocking a release for findings with proven, validated compensating controls
- If a finding lacks sufficient evidence for a confident disposition, flag it as NEEDS_MANUAL_REVIEW

## OUTPUT_SCHEMA
Return a JSON object with this exact structure:
{
  "release_id": "string",
  "triage_timestamp": "ISO8601",
  "summary": {
    "total_findings": int,
    "blocking_findings": int,
    "deferred_findings": int,
    "needs_manual_review": int
  },
  "findings": [
    {
      "finding_id": "string",
      "cve_id": "string or null",
      "title": "string",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL",
      "cvss_score": float or null,
      "exploitability_assessment": "string (explain why this is exploitable or not in the deployment context)",
      "compensating_controls": "string (describe existing controls that reduce risk, or state 'none')",
      "disposition": "BLOCK_RELEASE|DEFER|NEEDS_MANUAL_REVIEW",
      "disposition_justification": "string (specific reasoning tied to evidence, context, and risk tolerance)",
      "remediation_guidance": "string (actionable fix or investigation steps)"
    }
  ],
  "residual_risk_statement": "string (summary of risk remaining after recommended dispositions are applied)"
}

## INSTRUCTIONS
1. Parse all findings from [SCAN_RESULTS].
2. For each finding, assess severity, exploitability in [DEPLOYMENT_CONTEXT], and the effectiveness of any [COMPENSATING_CONTROLS].
3. Assign a disposition: BLOCK_RELEASE if the finding exceeds [CVSS_BLOCK_THRESHOLD] and lacks adequate compensating controls; DEFER if risk is below threshold or adequately mitigated; NEEDS_MANUAL_REVIEW if evidence is insufficient.
4. Write a specific disposition_justification that references concrete evidence, not generic statements.
5. Produce the final JSON conforming exactly to OUTPUT_SCHEMA.
6. If [SCAN_RESULTS] is empty or unparseable, return a valid JSON object with an error field: {"error": "No parseable scan results provided"}.

Adaptation guidance: Replace [SCAN_RESULTS] with the raw output from your SAST, DAST, SCA, or container scanner. The [COMPENSATING_CONTROLS] field should list controls already in place—such as WAF rules, network segmentation, or auth requirements—that may reduce exploitability. Set [CVSS_BLOCK_THRESHOLD] to match your organization's policy (commonly 7.0 or 9.0). If your scanner outputs findings in a non-standard format, preprocess the data into JSON before inserting it into this template. For high-risk releases, always route findings marked NEEDS_MANUAL_REVIEW to a human AppSec engineer before the release decision is finalized.

This prompt is designed to operate as a decision-support tool within a CI/CD quality gate, not as an autonomous release blocker. The ideal integration point is a post-scan pipeline step where aggregated SARIF, CycloneDX, or vendor-specific JSON reports are available. The application harness should collect scan results from multiple tools (SAST, DAST, SCA, container scanning), normalize them into a unified finding schema, and inject them into the [SCAN_FINDINGS] placeholder. The [RELEASE_CONTEXT] placeholder must include the target environment, data classification, exposure surface, and any compensating controls already in place. The [POLICY_THRESHOLDS] placeholder defines the organization's severity-to-action mapping—for example, 'Critical with known exploit must block; High without compensating control must block; Medium requires security lead approval.'

Validation and output enforcement is critical because the prompt produces structured JSON that downstream systems consume. Implement a post-generation validation layer that checks: (1) the output is valid JSON matching the expected schema, (2) every finding has a non-empty disposition field from the allowed enum [BLOCK, APPROVE_WITH_CONDITIONS, ACKNOWLEDGE, DEFER], (3) BLOCK dispositions include a specific policy reference, and (4) exploitability_assessment fields contain reasoning, not just labels. If validation fails, retry the prompt once with the validation errors appended to the [CONSTRAINTS] section. After two failures, escalate to the on-call AppSec engineer with the raw scan data and partial output. Log every invocation with the prompt version, model, input hashes, output, validation results, and final disposition for auditability. This trace is essential for post-release review and regulatory evidence.

Model choice and latency considerations matter here. Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the task requires multi-step reasoning across exploitability, compensating controls, and policy alignment. Expect 15-45 seconds per invocation depending on finding count. For releases with hundreds of findings, batch the input into chunks of 25-30 findings per invocation and merge results. Human review is mandatory for any finding with disposition BLOCK or APPROVE_WITH_CONDITIONS—the harness should create a review ticket with the finding details, model reasoning, and a required sign-off before the release gate proceeds. Never allow the model's output to directly fail a build without human confirmation. For high-compliance environments, store the full prompt-response pair as an immutable artifact in the release record alongside the human reviewer's decision and timestamp.