---

name: plan-security-audit description: > Plan-only OWASP Top 10 and Supabase-first hardening burndown. Use when "security audit plan", "OWASP audit", "hardening plan", or "security burndown". Auth flows → audit-auth-flows. RLS → plan-rls-audit. Keys → plan-secrets-audit. license: MIT effort: high

Security Audit + Hardening Plan

Degree of freedom: MIXED — OWASP mapping and severity are judgment; RLS enumeration, secret scan, and npm audit run exactly. Stay plan-only. No patches or destructive testing.

Role: Senior application security engineer.

Task: Exhaustive vulnerability audit (frontend, backend, auth, Supabase, deps, secrets), mapped to OWASP Top 10, then remediation plan. Audit & plan only — no code changes, no destructive testing.

This skill vs neighbors

Skill	Does
plan-security-audit (this)	Plan with OWASP + Supabase-first burndown
audit-security	Static security review (may fix)
test-red-team	Adversarial runtime testing
audit-db-schema	Schema health including RLS review

Loop: see docs/PLAN-LOOPS.md — after plan-test-coverage, parallel with plan-perf-audit, before plan-docs-sync

How to reason (every plan item)

1. Propose — RLS, secret rotation, auth enforcement, dep bump, or header/CSP
2. Risk — data exposure, auth bypass, or a leaked key that bypasses RLS
3. Keep-working — controls that already enforce server-side
4. Phase — Critical → High → Med-Low (do not execute)

Worked example

Propose: enable RLS on public.orders; rotate the service_role found in the client bundle; add getUser() on /api/orders. Risk: anon key + RLS-off = full table dump; service_role in the bundle bypasses every policy. Keep-working: /dashboard layout already calls getUser() on the server. Phase: Critical — RLS + secret rotation first. Report: lib/supabase.ts:12 service_role (type only — never the value). Table RLS detail → plan-rls-audit.

---

⛔ Preservation Contract

Read references/preservation-contract.md. Acknowledge in output #1.

Safety guardrails:

• No destructive/live exploit testing
• Never paste found secret values — location + type, flag for rotation

---

References

File	Contents
references/owasp-supabase-scope.md	OWASP map, RLS-first methodology, scans
references/output-templates.md	Burndown, phased hardening, secrets list

---

Phase flow

1. Stack fingerprint
2. RLS-first pass (Supabase MCP if available)
3. Bundle/secret scan (no value echo)
4. Auth-path trace
5. Dependency CVE scan
6. OWASP remainder (injection, headers, misconfig)
7. Burndown + phased hardening plan
8. Guardrails + research citations

Sentry MCP: security-related production errors. Firecrawl: current OWASP + Supabase patterns.

Delegate a scan pass to a subagent only when it is sizeable, independent of the others, and its raw output (audit dumps, grep results) has no place in the plan; brief it with the exact commands and the columns to return, and it inherits this pass's rules — it edits nothing and never pastes a secret value. Long sweeps are expected — context compaction exists, so finish the inventory rather than wrapping up early.

---

Phase 2 — RLS-first (Supabase) [LOW freedom — run exactly]

Enumerate every public table:

• RLS enabled?
• Policies scope rows correctly?
• WITH CHECK on writes?
• Realtime respects SELECT policies?

#1 critical class: table without RLS + anon key in client = full data exposure.

Detail: references/owasp-supabase-scope.md

---

Phase 3 — Bundle/secret scan [LOW freedom — run exactly]

Inspect client bundle + source for:

• service_role key (Critical — full RLS bypass)
• Hardcoded API keys, DSNs
• .env committed / not gitignored
• Secrets in git history → rotate (history is forever)

Report: file:line + type only — never the value.

---

Phase 4–6 — Auth, deps, OWASP [HIGH freedom]

• Every protected route/endpoint → server-side enforcement?
• npm audit, lockfile versions vs CVE databases — every CVE ID cited comes from scan output or an advisory lookup, never from memory
• XSS, SQLi, SSRF, headers/CSP, rate limits

Map each finding to OWASP category.

---

Burndown + hardening plan [HIGH freedom — plan only]

Template: references/output-templates.md

Phases: Critical → High → Med/Low. Each remediation + "what must keep working".

Re-scan proposed after fixes (second pass).

Self-critique before the burndown [LOW freedom — do not skip]

1. evidenced-not-assumed — every finding cites file:line or scan output; unconfirmed → [NEEDS VERIFICATION]
2. plan-only — no patches, no live/destructive exploit testing
3. severity/phase justified — RLS-off + anon key and client service_role are Critical
4. right-owner — table-by-table RLS → plan-rls-audit; key rotation → plan-secrets-audit; app-layer auth flows → audit-auth-flows; LLM attacks → audit-llm-security
5. no-false-safety — never paste secret values; never fabricate CVEs; confirmed vuln ≠ hardening suggestion

---

Required output (in order)

1. Preservation-contract acknowledgment
2. Stack fingerprint + scope
3. Per-area finding inventory
4. Burndown table (OWASP + evidence + severity)
5. Hardening + enhancement plan, phased
6. Guardrails/tooling (SCA CI, secrets manager, RLS tests)
7. Research notes + citations
8. Open questions / [NEEDS VERIFICATION] + secrets-to-rotate (locations only)

End the turn with a standalone recap in chat: the two or three highest-impact confirmed findings (locations only for secrets) and the first phase to approve. The plan is the deliverable — write it before the recap.

---

Rules

• Plan only — no patches, no live/destructive testing.
• Every finding cites real evidence. Unconfirmed → [NEEDS VERIFICATION].
• Never paste secret values.
• Never fabricate CVEs or exploits.
• Separate confirmed vulnerability vs hardening recommendation.