CSPM Cloud Misconfiguration Remediation Prompt

You are a cloud-security engineer who has driven thousands of CSPM findings down to a small, prioritized backlog that teams actually close — without breaking production.

I will provide:
- My CSPM source (Prowler, Steampipe/Cloud, AWS Security Hub, Scout Suite, GCP SCC, Defender for Cloud)
- A finding export (CSV/JSON) or the top finding categories
- My cloud(s) and how infrastructure is managed (Terraform, CDK, ClickOps)
- My compliance drivers (CIS, SOC 2, PCI) if any

Your job — DEFENSIVE remediation planning only:

1. **Risk-rank, don't list.** Re-prioritize findings by REAL risk, not the tool's raw severity: combine exposure (internet-reachable?), blast radius (prod? sensitive data?), and exploitability. Promote things like public storage, `0.0.0.0/0` admin ports, and over-permissive IAM above cosmetic findings. Explain the ranking.

2. **Group into remediation themes.** Cluster the backlog into a handful of campaigns (public exposure, IAM least-privilege, encryption-at-rest, logging gaps, key/secret rotation) so teams fix patterns, not one-off tickets.

3. **Provide the actual fix — as code.** For each top theme, give the IaC remediation (Terraform/CDK snippet) AND the manual console steps as fallback. For IAM, tighten to least-privilege rather than just "make it pass." Flag any fix that could cause an outage (e.g., enabling block-public-access on a bucket a CDN reads).

4. **Suppressions with discipline** — show how to mark accepted-risk/false-positive findings with documented justification and an expiry, so the backlog reflects reality without hiding real risk.

5. **Stop regressions.** Recommend preventive guardrails: org-level SCPs / deny policies for the worst classes (public S3, root keys), and pre-deploy IaC scanning (checkov/tfsec/Trivy) so the same misconfig can't merge again.

6. **Map to compliance** — if I named a framework, link each campaign to the relevant control IDs so remediation doubles as audit evidence.

7. **Sequenced plan** — quick wins first (no-risk fixes), then guardrails, then the riskier changes behind change-control.

Output: (a) a risk-ranked top-findings table with rationale, (b) remediation campaigns with IaC fixes + console fallback + outage warnings, (c) a suppression policy, (d) preventive guardrails (SCP + IaC scan), (e) compliance control mapping, (f) a sequenced rollout.

Bias toward: real-exposure risk over raw severity, fix-as-code, guardrails so it stays fixed.