The Minimum Viable Security Program for a Solo Vibe-Coding Founder

You are a solo founder. You did not write the code. Claude or Cursor or Bolt or Lovable wrote it. You shipped it to production last week. You have customers. You also have a vague sense that something in the codebase might be exposing a database, and you cannot actually read the code well enough to know.

Every "build a security program" guide on the internet is written for someone who knows their code. This is the program for the founder who does not.

---

Who this post is for

There is a category of founder that traditional "small-team security" advice does not address. The product is built end-to-end by AI tools — Claude Code, Cursor, Bolt, Lovable, v0, Base44, Replit Agent. The founder's contribution is product judgment, customer development, marketing, and operational decisions. The code is the AI's contribution, and the founder cannot reliably audit it because they did not write it and cannot read it at the depth needed to evaluate it.

This is not a degenerate case. This is a real and growing fraction of the small-software economy. The advice for traditional one-engineer orgs (which we covered in a sibling post) assumes the engineer can read the code. The advice here has to start from the assumption that the founder cannot.

If you write your own code or can read it at a level sufficient to audit it, that other post is the program for you. If you do not, this one is.

What the threat surface actually looks like

The WIRED / RedAccess research earlier in May surveyed roughly 380,000 publicly-deployed vibe-coded apps. The findings are the calibration:

• Approximately 5,000 apps shipped with no authentication at all — every endpoint accessible to anyone with the URL.
• Approximately 2,000 apps were actively leaking data — exposed databases, public storage buckets, unrestricted API endpoints.
• The platforms involved spanned Lovable, Replit, Base44, Netlify deployments, and direct Vercel and Cloudflare hosting of AI-generated code.

The founders who shipped those apps did not intend to ship them without authentication. The default on most vibe-coding platforms is "no auth" — the app starts as a public sketch and the founder is expected to lock it down before shipping. Most founders shipped without locking it down because the platform did not enforce the step and the founder could not read the code well enough to notice it was missing.

The threat surface that matters is not novel attack classes. It is the default behaviors of the platforms producing the code. The same defaults that let you ship in an afternoon are the defaults that ship without auth, without RLS, with secrets in code, and with publicly-readable databases. The platforms do not aggressively warn about this because their pitch is "easy"; aggressive warnings would undermine the pitch.

Your program has to compensate for the platform's defaults, because the platform will not.

Start with what you are not doing

You are not reading the AI's generated code line by line and auditing it. You cannot. If you could, you would have written it yourself.

You are not hiring a security engineer. The labor market for security engineers is the labor market for very-senior people, and the rate is not compatible with a solo founder's runway.

You are not running an annual pen test. Same reasoning as in the one-engineer-org case: the engagement costs more than your monthly runway and produces a report you do not have the bandwidth to remediate from.

You are not learning to read code well enough to audit it yourself. That is a valid long-term plan, but it is not the program for shipping this quarter. The program below is what to do while you build that skill (or while you decide not to).

What you are doing is one continuous control plus three operational habits adapted to a profile that cannot read its own code.

The one control: automated code-security scanning on every change

A scanner is the audit layer when you cannot audit yourself. It reads the code the AI wrote and tells you when something looks dangerous, in language you can act on.

The bug classes that matter for the vibe-coding profile are the ones the WIRED research surfaced and that the Spring AI and Semantic Kernel five-CVE week made into a public embarrassment for two large vendors:

• Endpoints missing authentication.
• Database tables missing row-level security.
• Secrets committed to the codebase.
• SQL injection, path traversal, and other classical-OWASP-Top-10 mistakes the AI happily ships when the prompt did not specifically prohibit them.
• Insecure-by-default configurations on storage buckets, CORS headers, and API endpoints.

A code-security scanner — one that runs automatically on every change to the codebase, before the change goes live — surfaces these. The output is "this endpoint is unauthenticated, here is the file and line." That is information you can act on even if you cannot read the surrounding code. You tell the AI "the scanner says line 47 of this file has no auth check, add one." The AI fixes it. You scan again to confirm.

The scanner is not optional in the vibe-coding profile. It is the audit layer that lets you ship code you cannot read.

Three operational habits that compound

1. Auth-first, always

The default on every vibe-coding platform is "no authentication." That default is the bug. Before you tell the AI to add any feature that touches data, tell it to require sign-in for the parts of the app it touches.

The discipline, concretely:

• Every new page, every new API endpoint, every new database query: state the auth requirement to the AI before it generates the code. "Build feature X. Require authenticated users only. Reject anonymous requests with a 401."
• Test the protected paths in a browser without logging in. If you can reach the protected content, the auth is not enforced. Tell the AI to fix it and re-test.
• If a feature genuinely needs to be public (a landing page, a marketing form, a public API for partners), say so explicitly. The default should be "auth required" with a deliberate carve-out for the public surface, not the inverse.

This is the cheapest defense-in-depth you can run, because it does not require code reading. The browser does not lie about whether the endpoint required a session. If you visited a URL while signed out and it served the protected content, the protection is not in place.

2. Secrets in env vars, never in code

If the AI ever generated a line that includes a literal API key, password, database connection string, or token — that secret is compromised. Rotate it. Treat the original as if it has been published, because once it lived in any code file the AI's training pipeline or your platform's logging might have seen, it effectively has been.

Use the platform's secret manager from day one. Supabase has env vars. Vercel has env vars. Cloudflare has secrets. Every legitimate hosting platform has the capability. The discipline is "the only place a production credential lives is the secret manager; everywhere else is a reference to the manager."

If you have been shipping for more than a week, audit your git history now. Run a secrets check (rafter secrets . works locally with no signup) and rotate anything it finds. This is the cheapest action with the largest blast-radius reduction of anything in this post.

The secrets detection guide covers the underlying discipline in more depth. The short version for vibe-coding founders: assume anything that ever appeared in your codebase as a literal credential is now public, and rotate accordingly.

3. Data-scope from the first table

Row-level security (RLS) on every database table that holds user data. Default-deny, then grant per-user access explicitly. If the AI shipped a table without RLS, every authenticated user can read every other authenticated user's data. That is the default behavior of most databases — and most relevantly for the vibe-coding stack, the default behavior of Supabase, which backs the majority of vibe-coded apps.

The specific failure mode on Supabase:

• RLS is off by default on new tables.
• Without RLS, your anon-key clients can read every row of every table.
• The anon key is in your frontend JavaScript. Anyone who views your site source has it.
• The combination means: every customer can read every other customer's data, by default, on every Supabase table without RLS.

You do not need to read the AI's code to verify this. The Supabase dashboard tells you which tables have RLS enabled — look at the policy column on each table. If RLS is off for any table that holds user data, that is a defect. Fix it before the next customer signs up.

The Mexican government breach generalizes downward to this profile: the breach was possible because data access controls were not what the agencies assumed they were. Your app is smaller, but the failure mode is the same — broader access than the founder thought, exploited by anyone who probes.

What you are trading off

This program does not protect you from a determined attacker who knows your stack. It does not give you defense-in-depth. It does not satisfy enterprise security questionnaires. It does not eliminate the risk that the AI generated something subtle that the scanner missed.

What it does is catch the broad-spectrum mistakes that the WIRED research found in 7,000 of the 380,000 apps it audited. Most vibe-coded app breaches in the wild are these mistakes, not subtle ones. The minimum viable program defends against the threats you actually face.

The program also does not protect against attacks that route around your code — supply-chain compromises in the AI tool itself, in the platform hosting your app, or in your third-party integrations. Those threat surfaces matter and they are documented elsewhere in this corpus (year-retrospective on AI developer-tool supply-chain attacks, postinstall hooks bug class). For a vibe-coding founder, those threats are someone else's problem until you are big enough to be specifically targeted; the platform-default mistakes catalogued above are your problem from day one.

You will outgrow this program. The moment you have a customer who runs a security review on you, the program has to formalize. The moment you ship into a regulated vertical, you need a compliance posture. The moment your app handles significant amounts of money, you need a real security professional in the loop. All of those are good problems and you should expect to have them if the product works.

For now, run the scanner on every change and check the three defaults yourself. That is the program.

How Rafter fits

Rafter (rafter.so) runs the scanner above — SAST plus SCA plus secrets detection on every push to your codebase, before the code goes live — and surfaces findings in language a non-engineer can act on. --mode plus adds agentic deep-dives for code paths where pattern matching is not enough. rafter secrets . is a local-only secrets check with no signup if you want to audit your git history before doing anything else.

The product was designed for the audit-layer-when-you-cannot-audit-yourself use case specifically. The findings are written to be actionable by the founder, not by a senior security engineer. "This endpoint has no authentication check. Add auth.uid() enforcement to line 47" is the shape of the output, not "Critical-severity CWE-862 missing authorization at AST node 0x4a3b."

Rafter is on AppSumo as a lifetime deal right now. The vibe-coding profile is exactly the audience the lifetime pricing fits — you are going to ship features for years and the scanner has to run on every one of them. A subscription line item you renew every year is a meeting you do not have time for. A lifetime license is the version of "yes" that lets you stop having the budget conversation.

Search "Rafter" on AppSumo, or go to appsumo.com/s/1yvki7f/. Limited time.

The scanner is the audit layer for code you cannot read. The AppSumo deal makes that audit layer a one-time cost. The window closes when AppSumo says it does.

---

Further reading

• The minimum viable security program for a one-engineer org — the sibling piece, for founders who can read their own code
• Vibe-coded apps, public by default — the WIRED / RedAccess research that calibrates the threat surface
• A lifetime license for a lifetime threat — the AppSumo launch piece
• Mythos and the three-month window — the calibration shift on AI-assisted vulnerability discovery
• Five CVEs across AI agent frameworks — what happens when classical bug classes ship in AI-shaped surfaces
• Mexican government Claude/GPT breach — what data-scope failures look like at the largest scale
• Secrets detection guide
• Vibe-coding security audit, Q2 2026