Slack Webhook Security & Secret Rotation Prompt

You are a senior security engineer who has hardened webhook secret management at multiple companies after incidents involving leaked webhook URLs being abused.

I will provide:
- Estimated number of webhooks in use
- Where webhook URLs likely live today (env vars, CI vars, Terraform state, source code, Helm values, secret managers)
- Secret manager in use (Vault, AWS Secrets Manager, GCP Secret Manager, 1Password Connect)
- Current rotation cadence (or lack of one)
- Recent incidents or audit findings

Your job:

1. **Threat model** — for an incoming webhook URL:
   - **What an attacker can do** with it (post arbitrary messages, impersonate the integration, embed phishing links)
   - **What they cannot do** (read messages, exfiltrate users, install apps)
   - **Vectors to leak** the URL (committed to git, in CI logs, in error tracebacks, in Slack message export, screenshots, browser history of staging dashboards)

2. **Inventory & discovery**:
   - Query Slack admin API: `apps.connections.open` and `team.integrationLogs` (Enterprise Grid only) for current install state
   - Grep git history for `hooks.slack.com/services/`
   - Search secret managers + Terraform state files
   - Search CI variable lists across repos
   - Search Splunk/Loki for accidentally-logged secrets

3. **Categorization** — group webhooks by:
   - Owner team
   - Sensitivity of destination channel
   - Whether the source is in your control or external (SaaS pushing TO you)
   - Frequency of use (daily / rare / dead)

4. **Hardening steps**:
   - Move every active webhook URL into the secret manager; remove from env files / CI plaintext
   - Add a CI pre-commit hook + scan that fails the PR if a `hooks.slack.com/services/` URL is in the diff
   - Configure DLP egress monitoring to flag the URL pattern leaving the network
   - Migrate high-value webhooks to a proper Slack app (OAuth + signed requests) where feasible

5. **Rotation plan**:
   - Cadence: 90 days for prod, 30 days for high-sensitivity, on-demand on suspicion
   - Mechanism: revoke + recreate via Slack admin API; secret manager rotation hook updates the consumer
   - Zero-downtime: dual-active window (old + new both valid for N minutes) where Slack's flow allows
   - Failure mode: who gets paged if rotation breaks an integration

6. **Detection** — how to know a webhook is being abused:
   - Volume anomalies (10x daily message rate)
   - Off-hours posts
   - Unusual content patterns (links to unknown domains)

7. **Decommission** — for dead webhooks, the revocation + ownership-record process. Audit log retention.

Output as: (a) threat model summary, (b) inventory script outline / query set, (c) hardening checklist with priority order, (d) rotation runbook with example Vault/SSM integration, (e) DLP / detection rules, (f) decommission process.

Bias toward: reducing the total number of secret types in circulation, automation over manual rotation, observability of secret use.