对 Supabase 应用做完整安全审计时：按阶段检测…

当需要对自己拥有或已获授权的 Supabase 应用执行端到端安全审计时使用，按阶段编排并持续保存证据与上下文。

适用场景

解决思路

1. 如环境支持 Plan Mode，在开始审计编排前使用 `EnterPlanMode`；让用户在执行前验证审计方法；如不可用则直接执行。
2. 在任何审计开始前，创建不存在的 `.sb-pentest-context.json`、`.sb-pentest-audit.log`、`.sb-pentest-evidence/` 目录结构，并用目标 URL 和时间戳初始化上下文。
3. 执行期间采用渐进式写入：每个动作前写 `.sb-pentest-audit.log`，每个发现后立即更新 `.sb-pentest-context.json`，每个测试后保存证据到 `.sb-pentest-evidence/`，不要批量写入。
4. 每个 skill 完成后验证所有跟踪文件已更新，再继续下一个 skill/阶段。
5. 系统化维护必需文件：`.sb-pentest-context.json` 在每次发现后更新；`.sb-pentest-audit.log` 在每个动作前后更新；`.sb-pentest-evidence/timeline.md` 在每次重要发现后更新；`.sb-pentest-evidence/curl-commands.sh` 在每次 curl/HTTP 请求后更新。
6. 阶段切换前执行验证清单：context 包含当前阶段所有发现；audit.log 有所有动作条目；证据文件存在于 `.sb-pentest-evidence/XX-phase-name/`；`timeline.md` 已更新 P0/P1/P2 发现；`curl-commands.sh` 包含所有 HTTP 请求；任一缺失/不完整则不进入下一阶段。
7. 按渐进写入模式执行每个 skill：`[LOG]` 写 START 到 audit.log → `[CONTEXT]` 更新 context.json 为 `phase_in_progress` → `[ACTION]` 执行测试/扫描 → `[EVIDENCE]` 立即保存证据 → `[CURL]` 追加 curl 命令到 curl-commands.sh → `[TIMELINE]` 如有重要发现更新 timeline.md → `[CONTEXT]` 更新 context.json 结果 → `[LOG]` 写 COMPLETE 到 audit.log。
8. 失败恢复：若 skill/阶段失败，保留失败点前已写入的所有文件；从最后成功检查点恢复；用 context 文件标明审计停止位置。
9. 要求用户在继续前确认授权：确认“我拥有该应用”或“我有明确书面授权进行安全测试”；让用户输入 `I confirm I am authorized to test this application` 后再继续。
10. 按顺序运行审计阶段，并在每个阶段之间请求确认。
11. Phase 0 初始化：如支持，使用 `EnterPlanMode`；创建 `.sb-pentest-context.json`、`.sb-pentest-audit.log`、`.sb-pentest-evidence/` 目录结构；初始化 `curl-commands.sh` 头部；用审计开始时间初始化 `timeline.md`；记录初始化日志；调用 `supabase-evidence`（初始化）；验证 4 个跟踪文件存在、证据目录完整、用户授权已确认；输出可开始收集证据。
12. Phase 1 Detection：调用 `supabase-detect`；确认是否使用 Supabase 并识别项目 URL；保存证据到 `.sb-pentest-evidence/01-detection/`。
13. Phase 2 Key Extraction：调用 `supabase-extract-url`、`supabase-extract-anon-key`、`supabase-extract-service-key`、`supabase-extract-jwt`、`supabase-extract-db-string`；输出所有发现凭据及严重性评估；保存证据到 `.sb-pentest-evidence/02-extraction/`。
14. Phase 3 API Audit：调用 `supabase-audit-tables-list`、`supabase-audit-tables-read`、`supabase-audit-rls`、`supabase-audit-rpc`；输出可访问表、数据暴露评估、RLS 缺口；保存证据到 `.sb-pentest-evidence/03-api-audit/`。
15. Phase 4 Storage Audit：调用 `supabase-audit-buckets-list`、`supabase-audit-buckets-read`、`supabase-audit-buckets-public`；输出 bucket 清单、公开暴露、可访问文件；保存证据到 `.sb-pentest-evidence/04-storage-audit/`。
16. Phase 5 Auth Audit：调用 `supabase-audit-auth-config`、`supabase-audit-auth-signup`、`supabase-audit-auth-users`、`supabase-audit-authenticated`；输出认证提供商分析、注册限制、枚举风险、认证与匿名对比；保存证据到 `.sb-pentest-evidence/05-auth-audit/`。
17. 在 `supabase-audit-authenticated` 中，创建测试用户前必须请求明确同意；该步骤可选但强烈推荐，用于检测 IDOR 和跨用户访问漏洞。
18. Phase 6 Realtime & Functions Audit：调用 `supabase-audit-realtime`、`supabase-audit-functions`；输出暴露的 channel、function 端点、访问控制问题；保存证据到 `.sb-pentest-evidence/06-realtime-audit/` 和 `.sb-pentest-evidence/07-functions-audit/`。
19. Phase 7 Report Generation：调用 `supabase-report`；输出完整 Markdown 报告，包含执行摘要、发现、修复建议。
20. 如支持 Plan Mode，按以下工作流：用户请求审计 → agent 使用 `EnterPlanMode` → 浅层探索目标（检测 Supabase、提取 URL）→ 将计划写入 plan 文件（目标 URL、检测到的 Supabase 配置、拟执行阶段、预计范围）→ 使用 `ExitPlanMode` 让用户审阅并批准 → 执行阶段并系统性更新文件 → 每阶段后确认文件已更新 → 生成最终报告。
21. 基本完整审计（有 Plan Mode）：对 `https://myapp.example.com` 运行 `Run a Supabase security audit on https://myapp.example.com`；agent 应使用 `EnterPlanMode`（如可用）、提交计划审批、系统性更新文件并执行。
22. 基本完整审计（无 Plan Mode）：运行 `Run a Supabase security audit on https://myapp.example.com --no-plan`。
23. 从某阶段恢复：运行 `Continue Supabase audit from Phase 3 (API Audit)`。
24. 跳过特定阶段：运行 `Run Supabase audit on https://myapp.example.com, skip auth audit`。
25. 管理并初始化证据目录：`.sb-pentest-evidence/` 包含 `README.md`、`curl-commands.sh`、`timeline.md`、`01-detection/`、`02-extraction/`、`03-api-audit/`（含 `tables/`、`data-samples/`、`rls-tests/`、`rpc-tests/`）、`04-storage-audit/`（含 `buckets/`、`public-url-tests/`）、`05-auth-audit/`（含 `signup-tests/`、`enumeration-tests/`）、`06-realtime-audit/`、`07-functions-audit/`、`screenshots/`；每个 skill 工作时保存证据到对应目录。
26. 遵守强制更新规则：每个 skill 执行后必须更新 `.sb-pentest-context.json`；每个动作必须带时间戳记录到 `.sb-pentest-audit.log`；文件不存在必须在审计开始时创建；任何 skill 未更新上下文文件不得视为完成。
27. 使用强制日志格式：`[YYYY-MM-DD HH:MM:SS] [SKILL_NAME] [STATUS] Message`，例如 `[2025-01-31 14:00:00] [supabase-detect] [START] Starting Supabase detection`、`[2025-01-31 14:00:05] [supabase-detect] [SUCCESS] Supabase detected`、`[2025-01-31 14:00:05] [supabase-detect] [CONTEXT_UPDATED] .sb-pentest-context.json updated`。
28. 使用上下文 JSON 结构保存状态：包含 `target_url`、`started_at`、`authorization_confirmed`、`supabase`（`detected`、`project_url`、`anon_key`、`service_key_exposed`）、`phases_completed`、`findings`。
29. 实施自适应限速：从正常请求速度开始；检测到 HTTP 429 时指数退避；遵守 Supabase 的 rate limit headers。
30. 每个阶段后按指定格式输出阶段完成块，列出发现并询问是否进入下一阶段，例如显示 `PHASE 2 COMPLETE: Key Extraction`、findings 和 `Proceed to Phase 3 (API Audit)? [Y/n]`。
31. 最佳实践：在非生产时段运行审计以减少影响；保存 context 文件作为审计轨迹；修复前与安全团队审阅发现；修复后重新运行审计验证。
32. 常见问题处理：若 Phase 1 报 `Supabase not detected`，应用可能使用自定义域名，手动提供 Supabase URL：`Run audit with Supabase URL https://myproject.supabase.co`。
33. 常见问题处理：若审计中遇到限速，orchestrator 会自动调整；若持续限速，等待 5 分钟并从恢复点继续。
34. 常见问题处理：若 context 文件损坏，删除 `.sb-pentest-context.json` 并重新开始审计。
35. 相关技能参考：`supabase-help`（所有技能快速参考）、`supabase-evidence`（证据收集管理）、`supabase-report`（从现有 context 生成报告）、`supabase-report-compare`（与之前审计对比）。

适用边界 · 注意事项

• 未获得目标应用所有者授权或明确书面授权时不要执行。
• 目标不是 Supabase 应用且无法提供或确认 Supabase URL 时不要按此流程执行。
• 不要用该编排替代非 Supabase 技术栈的通用安全审计流程。