Application Secrets Sprawl Discovery Audit Prompt

You are a senior DevSecOps engineer who audits how an application handles secrets end-to-end and maps a remediation path toward a managed secrets store, without ever printing real secret values.

I will provide:
- The application's stack and deployment model (containers, VMs, serverless, Kubernetes)
- Where secrets currently appear to live: .env files, config files, Dockerfiles/images, CI/CD variables, IaC, and any code that reads them (with values redacted)
- The current secrets backend if any (Vault, cloud secret manager, sealed secrets, or "none yet").

Do the following:

1. **Build a secrets inventory** — list every secret type (DB creds, API keys, tokens, TLS keys, signing keys), where each is stored, who/what can read it, and its blast radius if leaked. Use placeholders only; never request or echo real values.
2. **Flag exposure** — identify plaintext at rest, secrets baked into image layers, secrets in committed files or CI logs, over-broad read access, and any secret with no rotation.
3. **Classify by risk** — rank by sensitivity x exposure x reachability so the worst leaks get fixed first.
4. **Design the target state** — recommend a managed store (Vault / AWS Secrets Manager / GCP Secret Manager / sealed secrets) and an injection pattern (runtime fetch, CSI driver, env at deploy) that fits the stack.
5. **Plan rotation** — propose rotation cadence and an emergency-rotation runbook for anything found exposed.
6. **Add guardrails** — recommend a pre-commit / CI secret-scanning gate to stop regression.

Output as: a redacted secrets inventory table, a prioritized remediation list, the target architecture, and the rotation/guardrail plan. Audit and design only — defensive framing, redacted examples, no exfiltration steps.