How we compared them
We make Continuum, which sells an outside-in Leak Check and a human-reviewed Ship Check, so we say where the other checks do a better job.
A security check is only useful if it looks at the place where your app is actually weak. Each option was weighed on:
- What it looks at: your code, your database settings, your secrets or your live app.
- Which kinds of problem it misses.
- What it costs and how long it takes.
- Whether a person who is not an engineer can act on the result.
The options
Options are listed in the order you meet them while building, which is not a ranking. Facts about other products come from the sources at the bottom.
Your builder’s own scan (Lovable shown)
Built into the tool that made the app
Lovable documents a Project security view and a quick scan that runs when you publish. Its Supabase guidance tells you to confirm every table has policies that restrict row reads and writes before going live.
- Good at
- It sits right where you build, so there is nothing extra to set up.
- Fits
- A Lovable user who wants a first pass before publishing. Other builders differ, so check what yours documents.
- Drawbacks
- Publishing is not blocked by findings unless a workspace admin turns that on. Lovable’s own guidance also says to verify policies in the Supabase dashboard, so the scan is a starting point.
Sources: [1]
Supabase Security Advisor
A linter for your Supabase project
The advisors are checks that ship with Supabase. You can open them in the dashboard, run them through the CLI with supabase db advisors, or call them from the MCP server. The Security Advisor flags tables that have row level security switched off.
- Good at
- It reads your real project settings, which no code scanner can see.
- Fits
- Any app on Supabase, whichever builder made it.
- Drawbacks
- Supabase says some findings may be intentional, for example when you only reach the database from a web server, so each one needs a decision. It does not look at your front end or your secrets.
Sources: [2]
GitHub secret scanning and push protection
Catches keys before and after they land in a repository
GitHub scans for known secret formats. Push protection blocks a push that contains a credential from a supported provider before it reaches the repository.
- Good at
- It stops the most common leak, a real key committed by accident, at the moment it happens.
- Fits
- Anyone whose code lives on GitHub.
- Drawbacks
- GitHub’s docs say older and legacy token formats may not be covered. It reads the repository, not the JavaScript your live site actually serves.
Sources: [3]
OWASP ZAP baseline scan
A passive scan of a running web app
The ZAP baseline scan runs a spider against your site for one minute by default, then analyses the responses without sending attack payloads.
- Good at
- It finds common web faults such as missing security headers, and it suits frequent automated runs.
- Fits
- A developer or a technical friend who can run it and read the alerts.
- Drawbacks
- Reports lean technical. In our view a passive scan will not catch logic flaws such as broken access control, which is how one user reaches another user’s data.
Sources: [4]
Continuum Leak Check and Ship Check
An outside read, then a human review
The Leak Check is free and runs seven checks on your live URL in about a minute: reachability and SSL, auth routes, payment path, secrets in the client bundle, Supabase exposure, broken links and speed. The Ship Check costs $299. A senior engineer reads the codebase and reviews every finding by hand.
- Good at
- The Leak Check needs only a URL, and the Ship Check explains each finding in plain words.
- Fits
- A non-technical founder who wants a plain-language answer, or an app with payments and private data.
- Drawbacks
- The Leak Check is a surface scan that Continuum itself calls not a full security audit. The Ship Check needs access to your repository and costs money, while the tools above are free.
Run the free Leak Check →
Why the database check comes first
Continuum’s own scan of live AI-built apps asked one question: does the database answer a request that carries no login?
Continuum scanned 500 live apps built with Lovable, Bolt and base44 in October 2026. 177 of them ran on Supabase, and 31 of those 177 (17.5%) had at least one table that returned a row to a request with no login. 8 of the 177 (4.5%) had a table holding clearly non-public records. [5] Method and data.
A scanner that reads the repository cannot answer that, which is why a database check and an outside read belong in the set.