Row-Level Security and function logic keep tenant A from seeing tenant B. seccover proves it stays true as the code keeps shipping.
RLS policies tested per table, command and role
Functions, views and triggers, run as different tenants
Enforced or leaking, with the table, command and channel
Runs on your side, no telemetry
Run it
The database URL goes in the DATABASE_URL environment variable. There is no command-line flag for it.
export DATABASE_URL=postgresql://user:pass@host:5432/mydb
unitautogen seccover --schema public
On Windows PowerShell, set it with $env:DATABASE_URL="postgresql://user:pass@host:5432/mydb". The standard PG* variables work too. Connecting →
It picks up your Enterprise licence file automatically. On Supabase, run unitautogen --supabase seccover --schema public from your project. It connects to the local Supabase database itself.
What seccover checks
Your RLS policies, and the objects that run with their owner's privileges and can bypass them.
RLS policies tested per table, command and role, an improved version of the rlsautotest checks
Column grants checked for columns a broader grant exposes
SECURITY DEFINER functions run as their owner, not the calling user
Views without security_invoker are evaluated as the view owner, the Postgres default
SECURITY DEFINER and owner-run triggers make writes and reads that escape RLS
Each run as two tenants, with generated data on both sides
The Data security coverage report
Dated and reproducible. A contents index, then numbered chapters, laid out like the HIPAA report.
A sample run on a test schema. 8 of 17 functions leak, and each is listed under What to fix with the change that closes it.
Totals for leaking, too strict, enforced and unproven
One card per check, from RLS policy tests to PII in errors
What to fix, ranked, with the smallest database change for each
Function and view verdicts per client role, linked to their pgTAP tests
Trigger bindings name the exact tables a leak reaches
RLS policies as the last chapter, one matrix per table
A hole means the role can act but shouldn't, a tick means enforced
RLS policy and column-level reports written beside it
Two layers where tenant data leaks
A test at one layer says nothing about the other.
The policy layer, where Row-Level Security governs direct table access
The code layer, where SECURITY DEFINER functions, views and owner-run triggers bypass RLS by design
rlsautotest
Policy layer
Proves each RLS policy, per table, per command and per identity
Fails CI on a reachable table with no policy
Names every SECURITY DEFINER function, view and trigger as a suspect
It cannot judge the suspects; it sees that code bypasses RLS, not whether it leaks.
seccover checks exactly what PostgreSQL, Supabase and Neon tell you to watch.
Supabase flags SECURITY DEFINER views that bypass RLS in its project linter, and says to set security_invoker. seccover finds every one. Supabase, Security Definer View lint →
Supabase encourages automated pgTAP tests that RLS policies are correctly applied. seccover generates them. Supabase, Testing your database →
PostgreSQL documents that SECURITY DEFINER runs with the owner's rights, and how RLS is applied. seccover runs each routine as a tenant to prove it. PostgreSQL, Row Security Policies →
Neon requires RLS on every table exposed through its Data API. seccover proves the code paths cannot slip past it. Neon, Row-Level Security →
Your privacy
We would like to log your visit to see how the site is used. That records the page, the site you came from, your IP address and browser, and a random id for this tab. We delete it once we no longer need it.
