Stephan Smith Fractional CTO
← Vibe Coding 101

Chapter 4 of 5

Protect Your Business and Customers (i.e. security)

You need keys off your laptop and a straight answer when someone asks if you’re safe.

What you'll see developers say online

Security is the big cudgel: your vibe-coded app isn’t viable, you’ll leak API keys, customer data will be exposed. Developers use it as a veto. You can’t be secure without a security team. They’ll say if professional developers struggle with security, a non-coder definitely will, and your business will fail when keys leak or data gets breached.

The solution: security in plain language

Getting good enough at security isn’t that hard, and the prompts below get you there without pretending you need a security team on day one. People assume if developers struggle with security, vibe coders definitely will. Developers carry bad habits too, keys on laptops, Slack, text threads. Infisical (free tier) moves secrets off your machine: local dev, vibe coding, Claude, GitHub Actions, all without keys living in .env files on your laptop. Most devs don’t use it. You can.

If you do this yourself

You feel confident about what you built. Do the work once; it carries into everything after.

Developer perspective

Security concerns are legitimate: keys on laptops, data exposure, who can access what. Developers aren’t wrong to take that seriously; the answer is a clear posture, not shutting you out of your own app.

What to do

You don’t need to understand every implementation detail. You need the why. This process can take less than a day to set up and about a week to feel natural. Once it clicks, the anxiety drops.

If you skip this

Security stays the boogeyman that’s hard to refute when you’re non-technical. You lose confidence, and customers and teammates can smell that.

My Go To Prompts

I review codebases all the time. I’m a battle-tested CTO. I’ve built startups. Here are three prompts I use every day. These aren’t theoretical. They’re the actual prompts I run, tune, and build skills around.

1. Framing prompt

Your starting point. Security sounds like it takes a dedicated team and decades of war stories, but it is a set of patterns you can follow step by step. This tells the AI who to be so the rest of the conversation stays grounded in risk that fits your app and ICP, not fear-mongering or enterprise checkbox audits.

Assume the role of a senior CIO or security leader who has secured codebases for fintech and product companies, multiple audits, breaches prevented, and keys mishandled by well-meaning teams. You know how secrets leak, how security debt accumulates, and how to right-size protection for where a vibe-coded app actually is today. Hold that stance as we assess this app. Do not change anything yet. Help me see what a serious reviewer would flag and what we can adopt without a security team on day one.

Follow-up questions you can ask

Paste these after the framing prompt to tease out what security means for your app. Still no setup or code changes.

  • Priority

    Why is security the right focus for my app right now, given my ICP, data sensitivity, and stage?

  • If you skip

    What happens if we keep keys on laptops, in Slack, or in plain .env files? What breaks, what gets exposed, and when would a customer or investor use that against us?

  • Security building blocks

    Walk me through the core security building blocks (secrets management, auth, customer data, dependencies, CI/CD secrets) in plain language. For my app, where would each matter first and where would it be overkill?

  • Right-size it

    What is the minimum security bar that still looks professional for our stage, and what should we explicitly not pretend to have solved yet?

2. Current state prompt

Use this after the framing prompt. You are not asking the AI to rotate keys or install tools yet. You are building a picture of how secure the app is today and where secrets and data actually live. That stops panic refactors and helps you learn what security means for your business. Expect a table you can read and push back on with follow-up questions.

Using your senior security role, review what we have built so far, our code, stack, hosting, integrations, and how we handle sensitive data. Give me an overview of our current security posture: what is protected, what is exposed, and what would worry someone in a fintech or enterprise review. Do not make changes yet. Return a markdown table with one row per core security area (secrets and API keys, .env and local storage habits, secrets in repo or git history, authentication and access control, customer or PII data handling, dependency and supply-chain risk, CI/CD and deploy secrets, logging and error exposure of sensitive data). For each row include: the area, a score from 1-5 for where we are today, highest value / lowest effort / highest impact (rank or note), a plain-language sentence on why it matters for our ICP, and one question I should ask next to go deeper. Sort the table so the best next conversations are at the top.

Follow-up questions you can ask

Paste these after you have the table. Same chat, still no setup or code changes. They push into the details a senior reviewer would ask before trusting that we are safe.

  • Keys off the laptop

    Where do API keys and secrets live today, .env on disk, password manager, Slack, hard-coded in source? Score it and tell me the fastest path to get them off my machine without overbuilding.

  • Secrets in the repo

    Could a reviewer find keys in git history, config files, or screenshots, or are we clean? What would leak first if this repo went public tomorrow?

  • Secrets manager

    For our stage, does something like Infisical (or similar) earn its keep now, or is there a simpler step first? Compare effort vs. risk in plain language. Do not implement yet, recommend only.

  • Customer data

    What customer or user data do we store, where does it live, and who can access it? Map the gaps a privacy-conscious customer would ask about on a sales call.

  • Auth and access

    Are admin routes, APIs, and dashboards protected consistently, or does every feature invent its own gate? Where would an outsider get in first?

  • If we skip it

    For the lowest-scored rows in your table, what happens if we skip them for the next 30 days: what gets harder to fix, and when would this become a business-ending headline?

3. Capture the Wins and Patterns

Run this when you are ready to save what you learned. It creates a markdown file in your project root so the next security conversation picks up where you left off. You are not re-explaining your risk profile from scratch every time.

Using your senior security role, create a markdown file at the root of this project named security-status.md. Document what we found in this conversation: how keys and data are handled today, scores if we used them, gaps we flagged, priorities from low effort/high impact to high effort/low impact, patterns we agreed on, and open questions for our ICP. Write it in plain language so that in future chats about security you read this file first and treat it as the starting context. Do not make code changes in this step, only create or update the file.

Follow-up questions you can ask

Use this if you decided on new patterns or priorities after the file was created. Same chat.

  • Update priorities

    Take any patterns or priorities I outlined in our conversation and add or update them in security-status.md. Keep the file aligned with what I have decided matters for how we protect this business.

What you get

If you use this, you will have a security posture that matches your app and customer risk, not a compliance binder you will never finish. You will know where keys live, what gaps remain, and what to fix first. That turns off the “you need a security team” veto, because you can give a straight answer when someone asks if you are safe.
Infisical logo

Infisical is the newest addition to my fractional tools playbook, and it’s the golden path I point vibe coders at for secrets. Keys off the laptop, out of .env, into something Cursor, Claude, and GitHub Actions can use. Small enough to adopt in a day. 100% vibe-codable security without pretending you need a security team.

Infisical - Low-Code Playbook →