Catch tenant-isolation regressions before a Supabase migration ships.
BoundaryCI reconstructs the final authorization state produced by ordered SQL migrations, then applies deterministic checks to the tables, policies, views, and privileged functions that remain.
What the scanner checks
A text search can report SQL that was later replaced or dropped. BoundaryCI follows migration order so its findings describe the final state a deployment would create.
The current rules focus on exposed tables and views, unsafe policy conditions and metadata, and SECURITY DEFINER functions—the small authorization changes most likely to weaken a shared-database tenant boundary.
- Tables in exposed schemas without row-level security enabled
- RLS-enabled tables with no remaining policies
- Unrestricted anon, PUBLIC, or authenticated policies
- Exposed views that do not apply the caller's permissions
- RLS policies that trust user-editable authentication metadata
- SECURITY DEFINER functions with unsafe search_path or PUBLIC execution
Run locally without database credentials
The deterministic scan reads migration files. It does not connect to a Supabase project, request a service-role key, or need production access.
bashnpx boundaryci scan . --profile supabaseTurn the result into a pull-request gate
BoundaryCI emits terminal, JSON, SARIF, and native GitHub annotations. A reviewed baseline lets an existing project adopt the scanner without allowing new findings to hide inside old debt.
bashnpx boundaryci baseline .
npx boundaryci scan . --fail-on high