Vulnerability Disclosure Report Triage Prompt

This prompt is designed for the first 60 seconds of a vulnerability disclosure's lifecycle. When a new report arrives from a bug bounty platform, a security@ email, a customer ticket, or an external researcher, the immediate task is not to fix the bug—it's to create a structured, consistent record that the rest of your vulnerability management pipeline can act on. The prompt ingests the raw, unstructured report and outputs a standardized JSON triage record, extracting the claimed vulnerability type, the affected component, the quality of the reproduction evidence, and a preliminary severity. This record is the single source of truth that feeds your ticketing system (Jira, ServiceNow), your vulnerability tracker (DefectDojo), and your triage engineer's decision-making process.

The ideal user is a security engineer, a bug bounty program manager, or an automated intake pipeline that needs to normalize reports from dozens of sources into one format. The prompt assumes the reporter's text is the only input and does not perform active verification, call external tools, or access your internal asset inventory. It is a classification and extraction step, not an investigation. Use it when you need to eliminate the variance in how different reporters describe the same SQL injection, when you need to enforce a minimum evidence standard before a human spends time on a report, or when you are building an API that accepts disclosures and must return a predictable schema to downstream systems.

Do not use this prompt when the report contains evidence of active exploitation, a confirmed breach, or an ongoing incident. Those scenarios require immediate human escalation, not structured triage. Do not use it when you need a full, calculator-validated CVSS vector string; this prompt assigns a preliminary severity category, not a precise score. For that, use the Security Bug Report Severity Scoring Prompt. Do not use it for internal findings from your SAST, DAST, or SCA tools, which have their own structured output and require deduplication and false-positive analysis. Use the SAST Finding Severity Triage Prompt for that workflow. Finally, never treat the prompt's output as a final severity ruling. It is a starting point for a human triager who will validate the claims, reproduce the issue, and adjust the severity based on business context and asset criticality.

This template is designed to be copied directly into your prompt layer, test harness, or orchestration code. It accepts a raw vulnerability disclosure report—which may arrive via email, bug bounty platform, web form, or encrypted channel—and produces a structured triage record. Every square-bracket placeholder must be replaced with your specific input, context, and operational constraints before sending the prompt to a model. The template assumes the report may be incomplete, poorly formatted, or contain only partial reproduction steps, and it instructs the model to flag missing information rather than hallucinate it.

textCopy
You are a security triage analyst processing an external vulnerability disclosure report.

Your task is to extract and structure the following information from the report below. If any field cannot be determined from the report, set its value to null and add a note to the `missing_information` array explaining what is missing.

[OUTPUT_SCHEMA]

Report:
---
[REPORT_TEXT]
---

[CONSTRAINTS]

Before producing your output, verify:
1. The `vulnerability_type` maps to a recognized CWE ID where possible.
2. The `affected_component` is specific enough for an engineer to locate (e.g., endpoint path, parameter name, library version).
3. The `reproduction_quality` assessment is based on whether the report includes: environment details, step-by-step instructions, expected vs actual results, and proof-of-concept code or screenshots.
4. The `preliminary_severity` uses CVSS 3.1 base score metrics. Justify each metric choice in the `severity_justification` field.
5. If the report describes a vulnerability class covered by [ORGANIZATION_POLICY], flag whether it falls within scope.

If the report is too vague to produce a meaningful triage record, set `triage_confidence` to "low" and explain why in `triage_notes`. Do not invent details.

To adapt this template for your environment, replace [OUTPUT_SCHEMA] with your desired JSON schema or structured format specification. Replace [REPORT_TEXT] with the raw disclosure content. Replace [CONSTRAINTS] with any organization-specific rules, such as scope boundaries, severity thresholds that trigger automatic escalation, or required evidence standards. Replace [ORGANIZATION_POLICY] with a reference to your vulnerability disclosure program policy, bug bounty scope, or acceptable vulnerability classes. The constraint block is intentionally modular—add or remove verification steps based on your triage workflow's risk tolerance. For high-volume intake, consider adding a [RISK_LEVEL] placeholder that adjusts the depth of analysis requested (e.g., "standard" vs "expedited" for reports claiming critical impact). Test this prompt against a labeled dataset of real disclosures with known triage outcomes before deploying it to production, and expect to iterate on the output schema as your security engineering team refines what makes a triage record actionable.

This prompt is designed to be the first stage in a vulnerability intake pipeline, not a standalone chatbot. It should be deployed behind an API endpoint that receives unstructured disclosure reports—from bug bounty platforms, email-to-ticket gateways, or researcher submission forms—and returns a structured JSON triage record. The calling application is responsible for authentication, rate limiting, and storing the raw report alongside the structured output for auditability. Because external reports vary wildly in quality, the harness must handle missing fields, malformed input, and adversarial submissions without crashing or leaking system instructions.

Wire the prompt into your application with a validation layer that checks the output against a strict JSON schema before the record enters your vulnerability management system. Required fields include vulnerability_type, affected_component, reproduction_quality (an enum of excellent, adequate, poor, or unavailable), and preliminary_severity (using CVSS 3.1 base score or a critical/high/medium/low/none ordinal with justification). If the model returns malformed JSON, missing required fields, or a reproduction_quality that doesn't match the enum, trigger a retry with the validation errors injected into the next prompt call—but cap retries at two attempts to avoid loops on genuinely incoherent reports. Log every validation failure and the final output for prompt debugging. For high-severity findings (critical or CVSS ≥ 9.0), route the triage record to a human review queue before engineering handoff; the model's severity assessment is a preliminary signal, not a final determination. Use a model with strong structured-output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 for consistency. If your pipeline processes reports that may contain embedded PII in proof-of-concept code or screenshots, apply redaction before the prompt call—the model should not be the first line of PII defense.

Avoid wiring this prompt directly into an automated ticket-creation workflow without human-in-the-loop gates for high-severity findings. The biggest production risk is a well-written but fraudulent disclosure report that the model classifies as critical with high confidence, triggering an unnecessary incident response. Always store the raw report, the model's structured output, and the final triage decision in an immutable audit log. If you integrate with a bug bounty platform's API, use the platform's native severity and state fields as ground-truth comparison points for evaluating the prompt's accuracy over time. Start with a shadow-mode deployment where the prompt triages reports alongside your existing manual process for at least two weeks before cutting over.