Guide Security audits
Vibe coding security audit: scanner, audit report or fixed-price fix?
Short answer
There are three kinds of help for a vibe-coded app. A scanner is an automated tool that tests your app and lists what it finds. An audit report is a person's written review of your app, with fixes you or your developer then make. With a fixed-price fix, someone makes the changes for you at a set price. Pick by what you need at the end: a list, a plan, or a fixed app. PatchAndShip does the third: AI agents run the checks and a human engineer approves every change.
Option 1: a scanner
An automated tool looks at your app, usually through its public URL or its code, and reports what it finds.
- You get: a list of findings, often within minutes, and usually guidance on how to fix them.
- You still do: the fixes, then a re-scan to confirm them.
- Good for: a fast first look, and re-checking after every change.
- Keep in mind: an automated check only flags what its rules look for. On our own demo project, Supabase's Security Advisor flagged the table with RLS turned off. It didn't flag a table whose RLS policy lets anyone read every row, because its always-true-policy check skips read policies by design, and it doesn't flag public buckets that serve files by link, which is how public buckets are meant to work but easy to misuse. (Our demo write-up)
Option 2: an audit report
A person reviews your code, database settings or live app and writes up what they found.
- You get: a prioritized report, usually with severity and suggested fixes.
- You still do: the fixes, unless you buy that work separately.
- Good for: a second opinion before a raise or a big launch, or when your own developer will do the work.
- Ask first: what's in scope, how long the report takes, and whether fixes are quoted separately.
Option 3: a fixed-price fix
Someone checks the app and makes the changes, for a price agreed up front.
- You get: the changes themselves (code changes, database migrations, settings), plus a short report of what was changed.
- You still do: give access, then review the changes.
- Good for: apps you already know have problems, or when you'd rather not learn database policies the week you launch.
- Ask first: what exactly is covered, what access they need, and what happens if they miss the deadline.
Side by side
| Scanner | Audit report | Fixed-price fix | |
|---|---|---|---|
| What you end up with | A list of findings | A written plan | Changes made in your app |
| Who makes the fixes | You | You (or a separate quote) | The provider |
| Price model | Varies; often a subscription | Varies; often quoted per project | One price, agreed up front |
| Good first step if | You want a quick look | You want a plan for your team | You want it fixed |
Your platform's own tools are worth running first, whichever you choose. Lovable's docs say its security tools "do not replace a thorough security review." (Lovable: Security overview) Supabase's Advisors "are deterministic checks that ship with the platform." (Supabase: Advisors)
What PatchAndShip does
We do fixed-price fixes for apps built with Lovable, Bolt, Replit or Cursor on Supabase. AI agents run the checks and draft the fixes as code changes and SQL migrations. A human engineer reviews and approves every change before anything reaches production. (How a job works)
- Security Fix, $149 one time: RLS fixes on every table, storage bucket policies, a scan for exposed keys, key rotation guidance and a short report.
- Fix & Deploy, $249 one time: everything in Security Fix, plus the production deploy (env vars, auth redirect URLs, custom domain and SSL).
Security Fix: every critical issue on our checklist fixed within 48 hours of working access. Fix & Deploy: fixed and live on your host within 48 hours. Otherwise, a full refund if you ask within 14 days of purchase. The Launch Pack is not covered. “Critical” and “live” are defined in our Refund Policy.
Refund Policy: https://patchandship.com/refunds.html#guarantee
What we check, item by item: What we check and fix.
Not sure yet? Start free
Free check: a passive check of your public homepage, its scripts and its security headers: exposed secret keys, missing headers and public storage links found in the code (the bucket itself is never opened or listed). No database queries, no logins, no changes. It can't see your database or RLS. Only check apps you own or are authorized to test. Run the free check
FAQ
Is a security audit the same as a penetration test?
No. NIST defines penetration testing as a test in which assessors, "typically working under specific constraints, attempt to circumvent or defeat the security features of a system." (NIST glossary: penetration testing) None of the three options above is a penetration test. If a customer or investor asks for a pen test report, none of them replaces it.
Can I use a scanner and a fix together?
Yes. Run a scanner first, then fix what it finds yourself or hand the list to someone else.
Is the Supabase anon key in my frontend a problem?
Not by itself. Supabase says publishable and anon keys are designed to be public. The secret or service_role key is different: "A secret key bypasses every Row Level Security policy you have." (Supabase: API keys)
Do you need my passwords?
No. "Least-privilege access only: collaborator access on your GitHub repo, a Supabase org invite with the lowest role your plan allows, and for Vercel a guided handoff or a scoped, expiring token. We never ask for passwords, tokens are shared only via a one-time link, and at handoff you revoke our access (we send a checklist)." (Security and access policy)