Comparisons / CI scanners & AI reviewers
Semgrep matches patterns in code; RowShield checks the database
The short version
- Semgrep scans source with lightweight, writable pattern rules — fast, embeddable, and extensible enough to sketch policy-linting for migration files. RowShield evaluates the deployed catalog directly and probes behaviour, with rules maintained upstream.
- Choose Semgrep when — security engineers who enjoy owning rule packs and integrating scanners into bespoke pipelines.
- Choose RowShield when — teams who want Supabase-specific findings maintained by someone else, verified against production rather than intention.
RowShield rules relevant here
Head to head: Semgrep vs RowShield
| Capability | Semgrep | RowShield | Edge |
|---|---|---|---|
| Truth source | Files as written at scan time — faithful to the repository, indifferent to what the server actually runs. | The catalog as deployed, read every scan from pg_policies and related system views. | RowShield |
| Rule maintenance | Yours for the life of the project: dialect quirks, metavariable placeholders, false-positive tuning after every change. | Rules maintained upstream with suppressions documented publicly, so engineers review findings instead of rule packs. | RowShield |
| Expression normalisation | Pattern-level matching; semantic equivalence between different spellings stays structurally out of reach. | Deparsed expressions reduced before judgement — true, 1=1, NOT false and friends collapse into one finding. | RowShield |
| Surface breadth | Any language, any pattern: generality that makes it a fine default scanner for application code. | One domain done thoroughly; we deliberately do not compete on breadth. | Semgrep |
| Pipeline ergonomics | First-class CI integration, mature open-source governance and broad community trust earned over years. | A simple CLI plus scheduled monitoring; adoption takes minutes because there is little to configure. | Semgrep |
| Runtime cost findings | Not meaningfully expressible as file patterns; performance behaviour lives in query plans, not source text. | Unindexed predicates and bare auth.uid() calls detected against live definitions, each with a suggested fix. | RowShield |
| Community/rulesets | A large registry spanning many languages and frameworks, far beyond this particular niche. | A focused catalogue kept deliberately small, so every shipped rule earns its severity. | Semgrep |
Column claims about Semgrep are sourced below. Where the edge is theirs, the page says so — and the sections that follow explain why Supabase teams still pick RowShield.
What Semgrep does
Semgrep pairs a pattern matcher operating on parsed ASTs with an extensive rules registry, scaling from quick bad-pattern hunts to organisation-wide policy enforcement. Rules are code-review-shaped: find `eval`, find hardcoded secrets, find risky deserialisation.
Mechanically, a rule declares patterns per language alongside a message and severity; the engine parses matching files and reports every hit, which keeps scans fast enough to run on every push. That speed is why teams adopt it broadly before asking where its substrate ends.
Ambitious teams extend it toward infrastructure idioms — including SQL migrations — and that path works until the target stops being text.
Where the scopes differ
Three walls appear quickly. Equivalence: `USING true` and `USING 1=1` and OR-arm tautologies are one finding in the catalog, three near-misses in patterns. Provenance: dashboard and console edits bypass files entirely. Behaviour: no pattern answers "what does PostgREST return to the anon key".
Each wall converts to engineering hours on rule packs — hours that recur every schema evolution.
Migration guidance is straightforward if you already maintain custom SQL rules: connect the project, let scheduled scans reproduce the findings those rules attempted, then retire the pack once severities match expectations. Teams report the same relief in every such move — the rules stopped being theirs to debug the day the scans started.
Why Supabase teams choose RowShield over Semgrep
Buy the rules, not the rule-writing. Nine classes maintained upstream, tuned suppressions documented publicly, severity mapped sensibly, fixes generated from live columns. Your engineers stop being scanner maintainers and start reading findings.
The deeper argument is epistemic: a finding about deployed posture should be produced by observing the deployment. Pattern tools approximate that through files; when approximation is unacceptable — audits, incident reviews, compliance conversations — observation wins by default.
Where Semgrep is the right choice
Application-code security — secrets, injection sinks, framework pitfalls — is Semgrep's home turf and the registry is genuinely valuable; security-conscious platforms should run it. Its speed and writability also make it the right answer for org-wide conventions no other scanner encodes.
It simply is not a database monitor, and stretching it into one costs recurring engineering for approximations. The pivot we observe: teams keep Semgrep exactly where it excels and stop pretending migration files are a proxy for the database — RowShield takes the layer where truth lives server-side.
Using both
Clean split: Semgrep guards the application repo; RowShield owns the Postgres layer. If you sketched custom SQL rules for policies, migrate them to scheduled scans and retire the pack. Thereafter the two never disagree about jurisdiction — code findings route to reviewers, posture findings route to whoever owns the database — and both signals stay cheap because neither tool is asked to leave its substrate.
Frequently asked
- Is RowShield affiliated with Semgrep?
- No. RowShield is an independent Veristria product. Semgrep is a trademark of Semgrep, Inc., referenced here descriptively because it is the most common way teams first attempt policy linting in code. Nothing on this page implies endorsement or partnership, and all behavioural descriptions come from public documentation rather than private knowledge.
- Is RowShield a good Semgrep alternative?
- For database-posture checking, decisively — pattern matching was never the right instrument for catalog truth, and the gap compounds with every dashboard edit. For application-code scanning, keep Semgrep; it remains excellent there, which is precisely why the two coexist in most security-conscious stacks rather than one replacing the other. The two layers never compete for the same finding.
- Could we just write the rules ourselves?
- You could, and the first month feels productive. Normalisation, suppression hygiene and drift tracking are where homegrown packs stall — each new spelling of a tautology is another rule, and each dashboard edit is invisible anyway. Those are precisely the parts we ship, maintained upstream so your team never inherits the burden.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit