Security Vulnerability Defect Report Prompt

This prompt is designed for application security (AppSec) engineers, penetration testers, and security-focused QA teams who need to convert raw vulnerability findings into structured, actionable defect reports. Use it when you have a confirmed or suspected security weakness and must produce a triage-ready record that includes a clear attack vector, preconditions, a preliminary CVSS 3.1 score, and remediation guidance. The prompt enforces responsible disclosure language, evidence preservation, and impact assessment, making it suitable for workflows that feed into ticketing systems like Jira, vulnerability management platforms, or security review boards.

The prompt expects several concrete inputs to function reliably. You must supply the raw vulnerability finding, which can include scanner output, manual test notes, or proof-of-concept code. You should also provide the affected component or endpoint, the testing environment context, and any relevant compliance or policy constraints. The prompt uses square-bracket placeholders such as [VULNERABILITY_FINDING], [AFFECTED_COMPONENT], [TEST_ENVIRONMENT], and [COMPLIANCE_REQUIREMENTS] to structure these inputs. When adapting the template, replace each placeholder with the specific data from your assessment. If a placeholder is not applicable, explicitly mark it as 'Not Available' rather than deleting it, as the model uses placeholder presence to reason about missing information.

Do not use this prompt for general functional bugs, performance issues, or cosmetic defects. It is not a replacement for a formal penetration testing report or a certified CVSS calculation by a security analyst. The prompt produces a preliminary CVSS 3.1 vector and score intended for triage and prioritization, not for regulatory submission or vendor disclosure without review. Always require human security review before the report is accepted as final, especially for high-severity findings where the CVSS score exceeds 7.0 or the impact involves sensitive data exposure. The output should be treated as a draft that accelerates the reporting workflow, not as an authoritative security assessment.

This prompt instructs the model to act as a senior Application Security (AppSec) engineer. It is designed to receive an unstructured vulnerability finding—such as a pentest note, a scanner alert, or a researcher email—and produce a rigorous, structured JSON defect report. The output is built for direct ingestion into a bug tracker or security dashboard, not for casual reading. Every field in the output schema is chosen to reduce the back-and-forth between security and engineering teams.

textCopy
You are a senior Application Security engineer writing a defect report for an engineering team. Your report must be precise, evidence-backed, and actionable. Do not speculate beyond the provided input. If critical information is missing, flag it explicitly instead of guessing.

Using the vulnerability finding below, produce a structured JSON defect report that conforms to the [OUTPUT_SCHEMA].

[INPUT]

[OUTPUT_SCHEMA]
{
  "defect_id": "string, a unique identifier for this report, prefixed with SEC-",
  "title": "string, a concise technical summary of the vulnerability (max 100 chars)",
  "severity": "string, one of: CRITICAL, HIGH, MEDIUM, LOW, INFO",
  "cvss_vector": "string, a valid CVSS v3.1 vector string (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)",
  "cvss_score": "number, the calculated base score from the vector (0.0 to 10.0)",
  "attack_vector": "string, a description of how an attacker would deliver the exploit (e.g., network request, file upload, phishing link)",
  "preconditions": ["string, a list of conditions required before exploitation is possible (e.g., 'attacker must have a valid user account')"],
  "affected_component": "string, the specific software module, endpoint, or library that contains the vulnerability",
  "reproduction_steps": ["string, an ordered list of steps an engineer can follow to reproduce the issue in a test environment"],
  "observed_behavior": "string, what happens when the vulnerability is triggered",
  "expected_behavior": "string, what the system should do instead",
  "impact_assessment": "string, a plain-language description of the worst-case business or technical impact if exploited",
  "remediation_guidance": "string, specific, prioritized recommendations for fixing the root cause, not just the symptom",
  "evidence": ["string, a list of supporting evidence such as request/response snippets, log lines, or screenshot descriptions"],
  "missing_information": ["string, a list of facts not present in the input that would improve confidence or completeness"],
  "responsible_disclosure_note": "string, a reminder about disclosure obligations and handling restrictions for this report"
}

[CONSTRAINTS]
- If the input does not contain enough information to fill a required field, use null and add an entry to missing_information explaining what is needed.
- Do not invent CVSS scores. If the input lacks sufficient detail, use the lowest plausible score and flag it in missing_information.
- The reproduction_steps must be safe to execute in a sandboxed test environment. Do not include instructions that would exploit a production system.
- The responsible_disclosure_note must remind the reader not to share the report externally until the vulnerability is patched.

Adaptation notes: Replace [INPUT] with the raw vulnerability text. The [OUTPUT_SCHEMA] is provided inline for clarity, but you can move it to a separate system parameter if your harness supports structured output natively. The [CONSTRAINTS] section is critical for safety: it prevents the model from hallucinating CVSS scores and ensures reproduction steps are lab-safe. For high-risk workflows, add a [RISK_LEVEL] placeholder and conditionally require human review before the report is shared with engineering. If your platform supports tool use, consider adding a [TOOLS] section that allows the model to call a CVSS calculator function for accurate scoring rather than relying on its internal knowledge.

Integrating this prompt into a production security workflow requires treating the model output as a draft, not a final submission. The prompt is designed to produce a structured defect record with a CVSS vector, attack vector, and remediation guidance, but the model cannot independently verify the vulnerability or guarantee the accuracy of the severity score. The implementation harness must enforce a human-in-the-loop review step before any report is accepted into a defect tracker or disclosed to external stakeholders. This is non-negotiable for AppSec workflows where misclassification could delay critical patches or cause premature disclosure.

The harness should wrap the LLM call in a validation layer that checks the output schema before human review. Use a strict JSON Schema validator to confirm the presence and type of required fields: title, cvss_vector, cvss_score, attack_vector, preconditions, reproduction_steps, impact_assessment, remediation_guidance, and evidence_references. If the model output fails schema validation, retry once with a repair prompt that includes the validation error and the original input. After two failures, log the raw output and escalate to a human analyst with a flag indicating the model could not produce a well-formed report. Do not silently drop malformed outputs—they may contain partial findings that still need triage.

For evidence preservation, the harness must store the original vulnerability finding input (scanner output, pentest notes, researcher submission) alongside the generated defect report. This creates an audit trail for internal review and supports responsible disclosure workflows where the original evidence must be cited. If the input contains sensitive data—such as internal hostnames, credentials, or customer PII—redact it before passing it to the model, or use a local deployment where data never leaves your environment. The prompt's [EVIDENCE] placeholder should receive only sanitized, shareable evidence. For high-severity findings (CVSS >= 7.0), the harness should automatically flag the report for expedited review and notify the security on-call rotation rather than waiting for the normal triage queue.

Model choice matters here. Use a model with strong reasoning capabilities and a known safety profile for structured security analysis. Avoid models that are prone to hallucinating technical details or inventing CVE references. If your organization runs a private LLM deployment, prefer that path to keep vulnerability data off third-party infrastructure. When using an external API, ensure your data processing agreement covers security findings and that you are not sending exploit code or live credentials. The harness should log every model interaction—input, output, retries, and reviewer decisions—for compliance and post-incident review. Finally, never allow the model to autonomously file a defect in your tracker or send a disclosure email; the harness must require explicit human approval on the final record before any downstream action is taken.