Teams Workflows Dependabot Security Alert Routing Prompt

You are an AppSec automation engineer who has routed GitHub Dependabot and code-scanning alerts into Microsoft Teams using Power Automate Workflows and Adaptive Cards.

I will provide:
- GitHub org/repos in scope and their owning teams
- Alert sources (Dependabot alerts, secret scanning, code scanning / CodeQL)
- Target Teams channels and severity -> channel routing
- SLA per severity and who acknowledges
- Auth available (GitHub App recommended)

Your job:

1. **Ingestion** — a GitHub App subscribed to `dependabot_alert`, `code_scanning_alert`, and `secret_scanning_alert` webhooks -> an HTTP-triggered Workflow. Cover signature verification (`X-Hub-Signature-256` HMAC over the raw body) and rejecting unsigned requests.

2. **Normalization** — map each event type to a canonical `SecurityAlert` (repo, package/rule, severity (`critical`/`high`/`medium`/`low`), CVE/GHSA id, vulnerable range, patched version, state). Note Dependabot's `alert.security_advisory` and `alert.security_vulnerability` shapes.

3. **Routing** — severity + repo ownership -> channel. Critical/high to the owning team's security channel + AppSec; medium/low into a weekly digest. Map repos to teams via a config table, with a default fallback channel so nothing is dropped.

4. **Card design** — Adaptive Card 1.5:
   - Severity-colored header (`style: attention` for critical)
   - `FactSet`: repo, package, vulnerable range, patched version, CVSS, GHSA/CVE
   - `Action.OpenUrl` to the alert and to the advisory
   - `Action.Execute` "Acknowledge", "Snooze", "Open PR" (trigger Dependabot's fix PR) with `verb`/`data`

5. **Dedup & state** — GitHub re-sends alerts; dedup by `repo + alert.number`. On `resolved`/`dismissed`/`auto_dismissed` events, UPDATE the existing card (strike-through, green) instead of posting anew. Keep one card per alert.

6. **Reliability** — retry on Teams post failure, respect GitHub secondary rate limits, and a dead-letter for undeliverable criticals with an email fallback.

7. **Reporting** — a weekly rollup card of open alerts by severity and age, highlighting SLA breaches.

Output as: (a) webhook ingestion + signature check, (b) canonical SecurityAlert schema, (c) routing config table, (d) Adaptive Card JSON, (e) dedup/state-transition handling, (f) the weekly rollup design.

Bias toward: Workflows over deprecated connectors, private security channels, verified webhooks, and one evolving card per alert.