You are about to ship a Supabase-backed app built in an AI editor and the question is which security scanner to point at it before launch. Lovable has a built-in suite, CodeWatchtower is a Visual Studio Code extension that runs over any project, and the two tools look at different surfaces.
Short answer
The Lovable Security Scanner runs four automated checks inside the Lovable editor (RLS analysis, database security, code review, dependency audit) and is tied to the Supabase project Lovable provisions for a build. CodeWatchtower is a Visual Studio Code extension that runs a Docker-based scanner against any folder, producing a security score, inline highlights, and a list of top issues. For Row Level Security audits on a Lovable app, the built-in scanner is the closer fit. For broader code patterns across languages, CodeWatchtower covers more ground.
What you should know
- Lovable enables Row Level Security by default and re-runs RLS analysis after migrations. The scanner triggers when configuration or migration files change.
- The Lovable scanner verifies that RLS policies exist, not that they correctly block unauthorized access. Runtime correctness sits outside the checks the platform makes today.
- CodeWatchtower runs inside Visual Studio Code via Docker. Findings appear as inline squiggly underlines in the editor and as a security score. The free tier surfaces the top five issues; Pro reveals the full list.
- Both tools include dependency scanning. Lovable audits npm packages against CVE databases; CodeWatchtower runs Software Composition Analysis on the project folder.
- Neither tool replaces a pentest. Lovable now offers AI-driven pentesting through an Aikido Security partnership; CodeWatchtower describes itself as a scanner, not a pentest.
What does each scanner actually inspect?
The short answer is that Lovable runs four specific checks inside a Lovable project, while CodeWatchtower runs a generic security score over any folder you point it at.
According to Lovable's security documentation, the platform ships four automated scanners. RLS Analysis reviews database access policies and row-level rules. Database Security Check examines the schema together with the RLS configuration. Code Security Review looks for vulnerability patterns in application code, including XSS, input handling issues, insecure authentication, and unsafe external service usage. Dependency Audit checks npm packages against known vulnerability databases. The first three only run when relevant to the project; the database scanners require a connected database.
CodeWatchtower works differently. According to the CodeWatchtower listing on the Visual Studio Marketplace, the extension mounts the project folder into a Docker container, runs the scanner, and writes findings to a temporary JSON file the extension then reads. Output includes a security score, the top five issues in the free tier, complete findings in Pro, SCA dependency checking, and JSON or Markdown export for reports. Findings show up as squiggly underlines in the editor, the same way TypeScript errors do.
| Capability | Lovable Security Scanner | CodeWatchtower |
|---|---|---|
| Runs inside | Lovable editor | Visual Studio Code (any project) |
| RLS policy detection | Yes, automatic | Not documented |
| Code pattern scan | Yes (XSS, auth, input) | Yes (SAST via Docker) |
| Dependency scan | Yes (npm) | Yes (SCA) |
| Inline editor display | No | Yes |
| Pentest layer | Optional via Aikido | Not included |
| Cost (basic) | Free for most scans | Free tier (top 5 issues) |
How does Lovable handle Row Level Security audits?
The honest answer is that Lovable enables RLS by default, runs a linter after migrations, and flags missing or overly permissive rules. What it does not do is run live queries against the policies to confirm a logged-out user cannot read a private row.
According to Lovable's founder guide to security, misconfigured RLS is the most common cause of data exposure in Supabase-backed apps. Lovable's defaults push back on that by enabling RLS on new tables. The RLS Analysis scanner then runs automatically when migration or configuration files change. The Database Security Check runs once per session afterwards to look at how schema and policies interact.
The limit is the same one Supabase's own RLS troubleshooting docs underline. A policy that exists is not the same as a policy that is correct. A USING (true) policy is technically enabled. A policy that references a column an attacker can spoof is enabled too. Automated scanners that look only at the existence and shape of policies will miss these. Runtime testing, where you actually send unauthenticated and cross-tenant requests and check the response, catches them. The Lovable scanner does not do that step.
For a Lovable app holding personal data, the practical sequence is: rely on the built-in RLS scanner to catch missing policies, then run a separate runtime test (manually or through a tool that simulates unauthenticated requests) before going public.
What does CodeWatchtower add beyond Lovable's checks?
CodeWatchtower's value is that it runs in the editor you already use and scans any folder, not just Lovable projects.
Three things stand out. First, inline display. Findings appear as squiggly underlines in Visual Studio Code, which keeps the review loop tight because the developer sees the issue while writing the code. Second, Docker isolation. The scanner runs inside a container rather than in the host environment, which limits side effects on the developer machine. Third, the SCA layer pulls dependency findings into the same view as code findings, so a developer doing a security pass does not switch tools.
The trade-off is that CodeWatchtower is not specialized for Supabase or RLS the way Lovable's scanner is. Its documentation does not describe Row Level Security checks. For a Lovable app, running CodeWatchtower as a second opinion on JavaScript or TypeScript code patterns is a reasonable add, but the RLS surface still needs the Lovable scanner or a Supabase-specific test.
For builders working outside Lovable (a Next.js project pushed straight to Vercel, an Expo app, a Cursor-generated codebase), CodeWatchtower fills a niche the built-in Lovable scanner cannot reach.
Can either tool replace a pentest before launch?
The short answer is no, and both teams are explicit about this.
Lovable's documentation says the built-in scanners cannot guarantee complete security and that applications handling sensitive data or performing critical functions should undergo a professional security review. The platform added a paid pentesting tier through an Aikido Security partnership announced on the Lovable blog that runs AI-driven testing against the OWASP Top 10 and the OWASP Top 10 for LLM Applications. The Aikido side advertises a no-findings-no-charge structure on the basic tier.
CodeWatchtower describes itself as a scanner, not a pentest, and does not include a manual review layer. SAST and SCA together find a class of issues (known dependency CVEs, common injection patterns, hard-coded secrets) and miss others (broken authentication flows, business logic flaws, runtime authorization gaps).
For builders shipping a mobile wrapper around an AI-built web app, neither tool inspects the compiled APK or IPA. That review belongs to a separate process against the OWASP Mobile Application Security Verification Standard and OWASP MASTG. Teams that want an external automated read of a compiled mobile build before App Store Connect or Google Play submission often use a dedicated pre-submission scanner. PTKD.com (https://ptkd.com) is one of the platforms focused specifically on that step for AI-coded and no-code apps.
What to watch out for
The first trap is treating an RLS pass from any scanner as proof the policies work. The Lovable scanner reports missing or overly permissive rules; it does not run a logged-out request against the table and confirm the response is empty. Add at least one runtime test for the tables that hold personal data.
The second trap is the public Lovable project. A Lovable project can be public or private; making it public exposes the code and, depending on configuration, the build history. Several of the incidents covered in independent write-ups on exposed Lovable apps trace back to default visibility settings rather than scanner gaps.
The third trap is the free tier limit on CodeWatchtower. The free version surfaces the top five issues, so a project with a long list of medium-severity findings can pass the free scan while real issues sit further down the queue. For a project shipping to real users, the Pro tier or a complementary scanner is the safer call.
The fourth trap is the mobile wrapper. A Lovable web app rendered inside Capacitor or a WebView shell goes through Apple App Review or Google Play review, which use criteria neither scanner encodes. A Lovable-clean and CodeWatchtower-clean app can still fail Guideline 5.1.1 or trip a Data Safety flag.
Key takeaways
- For a Supabase-backed Lovable app, the Lovable Security Scanner is the closer fit because the RLS Analysis check is specifically built around the Lovable plus Supabase setup.
- CodeWatchtower is a useful second layer when the project lives outside Lovable, or when a developer wants inline SAST findings in Visual Studio Code without leaving the editor.
- Both tools flag dependency CVEs through npm or SCA, so duplicating that check is mostly noise; pick one for that surface and move on.
- Neither scanner replaces a runtime test of the actual RLS policies or a structured pentest. Lovable's Aikido partnership covers part of that gap on the platform side.
- Some teams add an external review against OWASP MASVS for the compiled mobile build before App Store Connect or Google Play submission. PTKD.com (https://ptkd.com) is one of the platforms focused on that pre-submission step for AI-coded apps.
