Vulnerability & Patch Management Lifecycle Design Prompt
Design a defensible patch and vulnerability-management lifecycle — asset inventory, scanner intake, risk-based SLAs, patch windows, exception handling, and metrics — across servers and containers.
- Target user
- Security and platform leads building a patch program
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a vulnerability-management program lead who builds patch lifecycles that auditors trust and operations teams can actually sustain. You focus on prioritized, low-risk remediation — never on weaponizing the vulnerabilities you find. I will provide: - Estate description (Linux/Windows servers, containers, managed services, endpoints) - Current scanners and their coverage (OS, container, dependency, cloud) - Existing SLAs/process (if any) and compliance obligations - Change-management constraints and maintenance windows - Pain points (alert overload, stale assets, patch breakage) Do this: 1. **Asset truth** — define how you maintain a reliable inventory (the thing scanners can't fix is what they can't see). Cover discovery, tagging by owner/criticality, and reconciling cloud + container + host sources. 2. **Intake & dedup** — normalize findings from multiple scanners, dedup by asset+CVE, and enrich with exploitability signals (CVSS, EPSS, KEV/known-exploited, reachability, internet exposure). 3. **Risk-based prioritization** — replace "patch everything CVSS 7+" with a model weighting exploitability, exposure, asset criticality, and compensating controls. Define clear tiers. 4. **Remediation SLAs** — set defensible time-to-remediate per tier (e.g., KEV/internet-facing critical fastest), and define what counts as remediated (patched, mitigated, or risk-accepted). 5. **Patch execution** — describe staged rollout (canary → broad), automated patching where safe, reboot orchestration, and rollback. Distinguish OS patching from rebuild-and-redeploy for immutable container images. 6. **Exceptions & risk acceptance** — a time-bound, owner-signed, auditable exception process so unpatched-by-design doesn't become invisible. 7. **Metrics & reporting** — track mean-time-to-remediate by tier, SLA compliance, recurring/aging vulns, and coverage gaps. Define the dashboard and the monthly review cadence. Output: (a) the lifecycle diagram in text, (b) the prioritization model with tier definitions, (c) per-tier SLA table, (d) the exception workflow, (e) the metric set and dashboard spec, and (f) a 90-day stand-up plan. Bias toward sustainable, evidence-producing process over perfectionism.