Reader Comments Shaped Three Releases of supabase-rls-check

The article published on dev.to on November 10, 2026 introduced supabase-rls-check, an open-source Python CLI and read-only PostgreSQL 15+ catalog query that inspects pg_catalog and storage.buckets for Row Level Security (RLS) mistakes.

Readers of the article began posting comments with edge cases from their own schemas. Within a day, versions 0.4.0 and 0.5.0 were released, adding 4 new rules and introducing run-to-run diffing for CI and local secret scanning for coding agent config files.

One reader pointed out a policy pattern that passes basic RLS enablement checks, leading to the creation of the policy_any_authenticated rule in version 0.4.0. This rule flags policies in the public schema with USING or WITH CHECK clauses that pass basic RLS checks but allow authenticated users to access all rows.

Another reader raised concern about writable USING (true) policies paired with table grants, which can allow anyone with an anon key to change or delete every row in the table. This led to the creation of the policy_true_writable rule in version 0.5.0.

Launchgatecheck contributed two ideas across versions 0.5.0 and 0.6.0. The first was to run supabase-rls-check in CI and diff the output between runs to catch new problems in pull requests while fixing older warnings over time. The second was to add an optional basis column to check.sql and expand the diff identity key to include the basis value.

One of launchgatecheck's suggestions led to the creation of the sensitive_anon_policy rule in version 0.6.0, which checks for policies that allow access to sensitive data tables. The rule also flags SECURITY DEFINER RPC functions that trust a user_id argument from the caller, as these can bypass RLS on underlying tables if not properly secured.