Emergency Security Patch Deployment Approval Prompt

This prompt is designed for security and platform engineering teams who must accelerate the remediation of a critical vulnerability outside the standard change management window. The core job-to-be-done is generating a structured, evidence-backed approval payload that a human manager can review and sign off on without needing to hunt down CVE details, affected systems, or testing results themselves. The ideal user is a Site Reliability Engineer (SRE), Security Operations analyst, or DevOps lead who has already validated the patch in a staging environment and now needs to produce a formal, auditable request to bypass normal deployment gates. The prompt does not execute the deployment; it produces the approval artifact.

Use this prompt when a vulnerability with a CVSS score of 9.0 or higher is actively being exploited, and the standard change advisory board (CAB) process would introduce unacceptable risk. The required inputs include the CVE identifier, a vector string, a list of affected hostnames or service identifiers, a summary of the patch's functional changes, and the results of an accelerated testing suite. The prompt is designed to refuse generation if critical safety fields—such as a rollback plan or a blast-radius assessment—are missing from the input context. It will explicitly flag these gaps in the output rather than hallucinating a safe rollback procedure.

Do not use this prompt for routine patching, low-severity vulnerabilities, or deployments that can safely wait for the next scheduled maintenance window. It is also inappropriate when the patch source is untrusted or when the testing evidence is incomplete, as the structured output could lend a false sense of security to a risky change. After generating the approval request, the next step is to route it to the designated emergency change authority, typically a VP of Engineering or an on-call security manager, and store the signed payload in your compliance audit trail. Avoid using this prompt in fully autonomous pipelines where the model's output could be mistaken for actual human authorization.

This prompt template is designed to be integrated into a security operations or change management system. It forces the model to collect and structure critical information about a vulnerability and its proposed remediation before a deployment can bypass standard change windows. The output is a machine-readable JSON object that can be directly consumed by an approval workflow, ticketing system, or audit log. The prompt's structure ensures that no critical field, such as a rollback plan or CVE score, is omitted.

textCopy
Generate a structured emergency security patch deployment approval request. Use the provided variables to populate the request. The output must be a valid JSON object conforming to the schema defined in [OUTPUT_SCHEMA].

[INPUT]
CVE Identifier: [CVE_ID]
Vulnerability Description: [VULNERABILITY_DESCRIPTION]
CVSS Score: [CVSS_SCORE]
Exploitability Assessment: [EXPLOITABILITY_ASSESSMENT]
Affected Systems and Services: [AFFECTED_SYSTEMS]
Patch Description and Source: [PATCH_DESCRIPTION]
Accelerated Testing Summary: [TESTING_SUMMARY]
Patch Risk Evaluation: [RISK_EVALUATION]
Rollback Plan: [ROLLBACK_PLAN]
Justification for Emergency Bypass: [EMERGENCY_JUSTIFICATION]
Deployment Owner: [DEPLOYMENT_OWNER]

[CONSTRAINTS]
- If [ROLLBACK_PLAN] is empty or missing, set the 'approval_blocked' field to true and set the 'block_reason' to 'MISSING_ROLLBACK_PLAN'.
- If [TESTING_SUMMARY] does not explicitly mention dependency impacts, set the 'requires_manual_review' field to true and add a note to the 'reviewer_notes' list: 'Untested dependency impacts'.
- The 'risk_score' must be an integer between 1 and 100, derived from a qualitative assessment of [RISK_EVALUATION] and [CVSS_SCORE].
- All string fields must be non-null and non-empty unless explicitly allowed by the schema.

[OUTPUT_SCHEMA]
{
  "approval_request": {
    "request_id": "string (generate a unique ID)",
    "status": "string (enum: pending_approval, approved, rejected, blocked)",
    "cve_details": {
      "id": "string",
      "description": "string",
      "cvss_score": "number",
      "exploitability": "string"
    },
    "deployment_details": {
      "affected_systems": ["string"],
      "patch_description": "string",
      "testing_summary": "string",
      "risk_evaluation": "string",
      "risk_score": "integer",
      "rollback_plan": "string | null"
    },
    "approval_metadata": {
      "emergency_justification": "string",
      "deployment_owner": "string",
      "approval_blocked": "boolean",
      "block_reason": "string | null",
      "requires_manual_review": "boolean",
      "reviewer_notes": ["string"]
    }
  }
}

To adapt this template, replace the [INPUT] variables with data from your vulnerability scanner, threat intelligence feed, and patch management system. The [CONSTRAINTS] section encodes critical business logic directly into the prompt to act as a safety net before the output reaches a formal validator. The [OUTPUT_SCHEMA] provides the target structure. When implementing, you should first populate the prompt with real data, then validate the generated JSON against the schema. If the approval_blocked field is true or requires_manual_review is true, the deployment pipeline must halt and alert the deployment owner immediately. Do not proceed with an automated deployment if the model's output indicates a blocking condition.

This prompt is a blocking gate, not a notification. It must be integrated into your CI/CD or SOAR platform so that the deployment job cannot proceed until a human approves the structured request it generates. The application layer should call the LLM, parse the output against a strict JSON schema, and then post the formatted approval card to an internal review queue (e.g., a Jira ticket, a Slack channel with a dedicated workflow, or a PagerDuty incident note). The deployment pipeline must poll for a signed approval token before executing the patch.

Validation is critical before the approval request is shown to a human. The application must validate that the LLM output contains all required fields: a non-empty cve_id, a populated affected_systems array, a risk_assessment object with a valid severity enum, and a boolean rollback_plan_exists. If rollback_plan_exists is false, the system should automatically append a hard-blocker warning to the approval card and require a second approver. Use a retry loop (max 2 attempts) with a back-off if the initial output fails schema validation, sending the validation error back to the model as a [REPAIR_INSTRUCTION]. Log every validation failure and retry attempt for auditability.

Model choice and tool use: This is a high-stakes reasoning task. Use a capable frontier model (e.g., GPT-4o, Claude 3.5 Sonnet) with a low temperature setting (0.1–0.2) to enforce factual consistency. Do not provide the model with tools to execute deployments. The only tool it should have access to is a lookup_cve_details function to pull live data from your vulnerability scanner or NVD database, ensuring the prompt's [CVE_DETAILS] placeholder is populated with real-time, grounded data rather than training data. The output must be a single, valid JSON object matching the [OUTPUT_SCHEMA]. If the model returns a refusal or an unparseable response, the pipeline must halt and escalate to the on-call security engineer immediately.