05 — Security Best Practices — You Ship What the AI Wrote, Including the Holes

Security is the easiest thing to skip when the build is flying, which is exactly when the holes get in. Writing it down forced one idea to the front: the AI generates code that looks correct, and "looks correct" is the exact wrong standard for security. A working login form can still leak tokens. A functioning database layer can still be injectable. Plausibility hides holes, and the holes are mine when they ship [1]. The roadmap's framing is direct: _security is easy to overlook when you're moving fast_ — so the oversight has to be deliberate.

The model that clicked: vibe coding compresses the time it takes to ship a vulnerability. What used to take a junior a week to write (and a reviewer a day to catch) now takes an AI five minutes to generate and ships ten minutes later if no one's looking. The speed multiplies on both sides — more features per hour, and more holes per hour, unless I build the discipline in.

Why AI-generated code has a security shape

There are three reasons AI code lands with a particular security profile, and naming them is the first defense:

• It's trained on public code, including bad public code. The model has ingested millions of tutorials, and a lot of tutorial code is insecure by design — simplified to teach a concept, with auth stripped out, secrets hardcoded, queries concatenated. The model reproduces those patterns because they're common, not because they're safe [2].
• It optimizes for the request, not for threats. When I ask for "a login endpoint," the model builds one that works. It rarely adds rate limiting, account lockout, timing-attack resistance, or secret rotation unless I ask for them — because I didn't ask, and the model's job is to satisfy the request.
• It doesn't know my threat model. The AI has no idea whether this endpoint faces the public internet or an internal network, whether this secret is a test key or production, whether this input is user-controlled or trusted. Threat-relevant context has to be supplied, or the code defaults to "assume benign input."

The good news is that the AI is also a useful security reviewer — once I ask. The same model that wrote the hole can often find it when I explicitly request an audit. The asymmetry is that it won't offer; I have to ask.

Secrets: environment variables, always

The first concrete habit the roadmap names, and the cheapest to keep: _always use environment variables for sensitive information like API keys and passwords_ [1]. Hardcoded secrets are the single most common AI-introduced vulnerability, because the model writes the key inline to make the example self-contained, and the example becomes the implementation.

The rule I keep:

• Secrets live in .env files (gitignored) and reach the code through process.env.
• The AI never sees production secrets. I paste test keys into prompts, never live ones.
• Before commit, a pre-commit hook scans for high-entropy strings (strings random enough to look like a secret). Tools exist; I don't write my own.

The pattern is mechanical, and once it's in place, the AI follows it for the rest of the project — but only if I set it before the first secret appears.

The pre-launch audit: explicitly ask for holes

The second roadmap habit, and the one I most often skipped: _before going live, explicitly ask AI to audit your app for vulnerabilities_ [1]. The word _explicitly_ is doing all the work. A general "review this code" prompt gets a style review. A targeted "audit this for security vulnerabilities — list every one you find, with severity and fix" prompt gets a security review [3].

A useful audit prompt names the categories I care about:

Audit this codebase for security vulnerabilities. For each finding report:
- category (authn/authz, injection, secrets, headers, deps, SSRF, etc.)
- severity (critical / high / medium / low)
- file + line
- concrete fix
Do not skip findings to be polite. I want them all.

The AI won't catch everything — it's a starting point, not a pentest [3]. But it catches a surprising amount, and it does it in minutes. Pairing its output with a dependency scan (known CVEs in the lockfile) and a secret scan covers most of what a pre-launch check needs.

The honest ceiling

I want to be clear about what this is and isn't. An AI security audit is not a substitute for a real pentest (penetration test), a dependency policy, or threat modeling on anything that handles money, identity, or sensitive data. It's a high-value first pass that catches the common stuff fast. For anything high-stakes — payments, auth, medical, regulated data — the AI audit is _in addition to_ human review, not instead of it. The roadmap's guidance is for the long tail of apps where "no glaring holes before launch" is a reasonable bar. It is not the bar for a bank.

How I use this

Three habits, in order. First, secrets in environment variables before the first key is written, with a pre-commit secret scan as a backstop. Second, a targeted pre-launch audit prompt that asks for every finding by category and severity, run as a separate session from the build. Third, honest scoping — for anything high-stakes I treat the AI audit as a first pass, not a sign-off, and pair it with human review. The shortcut I never take: shipping AI code to production without an explicit security pass, because "it works" and "it's safe" are different sentences.

References

[1] roadmap.sh, "Security Best Practices," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/security-best-practices

[2] Databricks, "Passing the Security Vibe Check: The Dangers of Vibe Coding," 2026. [Online]. Available: https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding

[3] Legit Security, "Vibe Coding Security: Risks and Best Practices," 2026. [Online]. Available: https://www.legitsecurity.com/aspm-knowledge-base/vibe-coding-security