OWASP vulnerability scanner

Build a Cosmos workflow that probes the app for OWASP Top 10 weaknesses, scans dependencies for known CVEs, and opens deduped, severity-graded incidents for every real hole.

Trigger: nightly on a fixed cron, plus every successful deploy to staging.

Steps:
1. Provision a sandboxed environment: a clean clone of the app pointed at an isolated database seeded with synthetic data. Never run the scan against production.
2. Discover the attack surface: enumerate routes, public and authenticated APIs, forms, auth endpoints, file-upload paths, third-party callbacks. Capture the OpenAPI / route table when one exists.
3. Run the OWASP Top 10 test suite against the sandbox. For each category, exercise representative probes:
   - A01 Broken Access Control: IDOR, missing authz on protected routes, role escalation, forced browsing.
   - A02 Cryptographic Failures: TLS config, weak ciphers, plaintext secrets at rest, weak hashing.
   - A03 Injection: SQLi, NoSQLi, command injection, template injection, header injection.
   - A04 Insecure Design: abuse-case probes (rate-limit bypass, business-logic flaws).
   - A05 Security Misconfiguration: default creds, verbose errors, open admin panels, missing security headers, permissive CORS.
   - A06 Vulnerable & Outdated Components: flagged in the Snyk pass below.
   - A07 Identification & Authentication Failures: credential stuffing protection, session fixation, MFA bypass, JWT misuse.
   - A08 Software & Data Integrity Failures: unsigned updates, deserialization, CI / supply-chain tamper checks.
   - A09 Logging & Monitoring Failures: confirm auth and admin actions are logged and visible.
   - A10 SSRF: probe outbound URL fetchers with metadata / internal targets.
4. In parallel, run Snyk (or the configured SCA tool) against the lockfiles, Dockerfiles, and IaC manifests. Pull every Critical / High CVE with a fix path, plus the relevant container-image findings.
5. Aggregate findings into a single normalized list. Each finding has: category, affected asset (route, file, dependency), evidence (request / response / stack), reproduction steps, and a remediation hint.
6. Decision: "Any findings?".
   - If no, record a clean-run snapshot in the security log and end.
   - If yes, continue.
7. Score each finding. Compute severity using a CVSS-like rubric: Critical, High, Medium, Low. For Snyk findings, inherit the published score and adjust by exploitability in our environment.
8. For each finding, search the incident tracker for an existing ticket on the same fingerprint (same route + category, or same CVE id).
9. Decision: "Already tracked?".
   - If yes, append the new evidence and the latest run id to the existing incident and update its severity if it changed. Skip to the next finding.
   - If no, continue.
10. Open a new incident with the title, severity, OWASP / CVE reference, reproduction steps, evidence excerpt, affected asset, and the suggested remediation. Tag it for the right owner team (frontend, backend, platform, infra).
11. Route by severity: Critical and High page the security on-call immediately with a link to the incident; Medium and Low go straight into the ticket queue without paging.

Constraints:
- Never scan against production. The sandbox is mandatory.
- Always dedupe against existing tickets before opening a new incident: a noisy backlog is as bad as a missed hole.
- Always attach reproduction steps and evidence; the responder must be able to reproduce without re-running the whole scan.
- Keep the security log append-only so we can build trend dashboards (open holes by severity, MTTR, recurring categories) over time.