RowShield

Help / Start here

Glossary: finding, transition, disposition, drift event, health score, remediation SQL, probe

All plansLast reviewed 2026-08-23

These terms mean the same thing in the dashboard, in alert payloads and in every article on this site. The definitions are short on purpose; each linked article goes deeper.

RowShield is an independent product, not affiliated with or endorsed by Supabase; Supabase-specific terms below are described as the platform behaves, not as we would prefer it to.

Finding

A finding is one violation of one rule against one object: a table with RLS off, a policy that always evaluates to true, a bucket that is public. Every finding carries a severity, an explanation, evidence such as the policy expression involved, and usually remediation SQL.

Findings are keyed by rule and object, so the same unresolved problem stays one finding across scans instead of accumulating duplicates. One misconfigured table can legitimately yield several findings, for example RLS_DISABLED on the table and MISSING_WITH_CHECK on a policy attached to it, and each stands or resolves independently.

Transition

A transition is a change in a finding's state between two consecutive scans: created when first seen, regressed when a previously resolved problem comes back, resolved when it disappears. Alerts fire on transitions only.

That is what keeps alerting quiet enough to leave enabled. A table left broken all week raises one created alert, not seven daily reminders, and a retried scan raises nothing because the transitions were already recorded. Transitions also give you the regression history: the fifth time a policy comes back, the record shows all five dates, which says something about process rather than luck.

Disposition

A disposition is the decision you attach to a finding once you have read it: fix it, accept it as intentional, or dispute it. Transitions are recorded automatically by comparing scans; dispositions are yours.

Keeping the two distinct matters in practice. An accepted risk should stop generating debate without pretending the underlying state changed, and a disputed finding should stay visible until an engineer has looked at it, which is what the dispute route exists for.

Drift event

A drift event is any detected difference between two consecutive snapshots: a policy added, dropped or rewritten, Row Level Security switched off or on, an index removed, a bucket flipped from private to public. Drift alerts phrase these as appeared, came back or disappeared.

When policies quietly stop working months after launch, the drift timeline is usually the shortest route to the migration that caused it. Drift covers indexes and buckets too, because an index silently dropped before a deploy can turn a fast policy into a sequential scan without anything looking different in the application.

Health score

The health score compresses the current open findings into a number from 0 to 100. It starts at 100 and loses points per open finding, 22 per critical, 9 per high, 3 per medium, with caps so that a pile of minor issues never outweighs one severe one. Grades run A, B, C, D and F.

A worked example: one critical and two high findings cost 22 plus 18, landing at 60 out of 100, which grades C. The full arithmetic, including what the score ignores, is in How the health score is calculated.

Remediation SQL

Remediation SQL is the copyable fix attached to most findings: policy definitions built from your actual columns, FORCE ROW LEVEL SECURITY always included, and a clearly marked TODO wherever the right condition depends on your data model and could not be inferred safely.

Where an ownership column cannot be identified, the block lists your columns and asks you to pick one rather than guessing. Every generated block opens with the same banner asking you to review before running in production, and that banner is sincere.

Probe

The probe is the external check. It inspects a deployed app's public surface using only the anon key, issuing read-only GET, HEAD and OPTIONS requests to learn whether tables answer unauthenticated callers. Everything it reports is something an attacker could reproduce with no credential beyond the public one.

A 200 response with an empty array is reported as reachable, not leaking, because RLS filtering every row and an empty table are indistinguishable from outside. Discovery, enumeration and that ambiguity are covered in What the free probe checks; in hosted form the probe runs from an edge worker, and the CLI reproduces it locally with rowshield probe.

Using the words with support

When writing to info@getveristria.com about a result, quoting the rule id and the object pins the conversation to exactly one record: RLS_TAUTOLOGY on public.documents, policy documents_open, tells us everything a screenshot would and more precisely.

Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.

RowShield checks 9 rule classes continuously. This article describes shipped behaviour only.