Enterprise
Prove your database isolates tenants.
Row-Level Security and function logic keep tenant A from seeing tenant B. seccover proves it stays true as the code keeps shipping.
- Enforced or leaking, per routine
- Evidence of which table, which command and which channel
- Functions, views and triggers, run as different tenants
- Runs on your side, no telemetry
What seccover checks
The objects that run with their owner's privileges, so they can bypass the caller's RLS.
- 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 Security coverage report
Dated and reproducible. Four counters and four detection passes up top, then every routine judged role by role, with the table, command and channel of any leak.
When a routine leaks, it is flagged. Here 8 functions and 2 views cross a trust boundary, each with the table and channel named.
When isolation holds, the same report reads 0 leaking, every routine enforced as declared.
- Counters for leaking, too strict, enforced and unproven cells
- Detection passes for RLS leak, view leak, trigger-binding and PII
- Each function judged per client role, with its unit-test coverage
- A leak names the table, the command and the channel
- A hole means the role can act but shouldn't, a tick means enforced
- Dated and reproducible, so a run stands as evidence
Two layers where tenant data leaks. One tool for each. Use both.
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.
rlsautotest, free and open source →
UnitAutogen seccover
Code layer
- Runs each suspect as two tenants with generated data on both sides
- A verdict per routine, enforced or leaking, with the table, command and channel
- A PII pass for personal data escaping through error messages
It cannot stand in for the policies; direct table access is rlsautotest's job.
seccover, in the UnitAutogen engine →
Complete leakage detection needs both.
- rlsautotest verifies the RLS policies
- UnitAutogen verifies the functions, views and triggers that bypass them
Evidence, not a certificate
- Standard pgTAP plus dated, reproducible reports
- Supporting evidence for HIPAA and SOC 2 access controls
- Produced inside your perimeter
- A tool, never a certification or an audit service
What platforms suggest
seccover checks exactly what PostgreSQL, Supabase and Neon tell you to watch.
