Supabase RLS audit and merge-request gate

What it does

A read-only SQL audit that flags Row Level Security mistakes in a Supabase project. It reads the database catalog and returns one table of findings. A second query checks for Supabase's October 2026 grant change. A GitLab CI flow runs both on every merge request and posts a ranked review for human approval.

How it works

• The audit is a single SELECT that reads pg_catalog only. It creates nothing and writes nothing.
• It flags tables with RLS disabled, permissive policies with USING (true) or WITH CHECK (true), policies not tied to the caller, views not set to security invoker, and more.
• A second query checks whether the project still auto-grants new tables, or already needs explicit grants.
• On every merge request, CI applies the migrations to a throwaway Postgres, runs both audit queries, and writes findings.json.
• A GitLab Duo flow reads the merge request diff and the findings, writes a ranked review, and stops for human approval before any write.

Guardrails and design choices

• The audit is read-only. It cannot see API routes, edge functions, keys, webhooks, or anything outside the database.
• The CI flow stops and shows the review to a human, who approves or rejects. Before approval the flow has no write tool at all.
• The fixer writes only from five fixed templates, for names that are plain lowercase identifiers. Anything else is listed as needing a human.
• The release job fails while any high finding is open, and a person presses the release button.

Status

The audit is published under the MIT license. The merge-request gate is a work in progress. The audit finds only what the SQL checks for; a clean result is the floor, not proof the app is safe.