# Secure by Default — The CV Method Security Playbook

**The CV Method · The Playbook · v1 · Aug 2026**
*by Corina · @the_cv_method · hello.thecvmethod.com*

*The principles behind how every build gets secured. Security is a constraint from the first line of code — never a retrofit.*

---

## Why this exists

AI writes software fast. Left unchecked, it also ships fast mistakes: secrets committed to a repo, databases left open by default, endpoints with no rate limits, permission checks that live in the browser where anyone can skip them.

At The CV Method, security isn't a step at the end. It's a constraint we design in from the first line, verify adversarially before launch, and monitor after. Every build-out runs the same gate — no exceptions.

---

## Seven operating principles

1. **Assume it's broken.** Every build is reviewed as if at least three critical mistakes are already in it — because usually they are. We prove it's safe rather than assume it.
2. **Trust nothing from the browser.** Authorization and every critical decision live on the server. The client is treated as hostile input, always.
3. **Least privilege.** Every user, role, and service gets the narrowest access that still works — enforced at the data layer with row-level security, default-deny.
4. **Secrets never live in code.** API keys, credentials, and tokens sit in environment variables and are read only at runtime — never hardcoded, never committed.
5. **Every dependency earns its place.** Packages are verified as real and reputable before they're trusted — no hallucinated or unvetted libraries in the supply chain.
6. **Fail closed, fail friendly.** When something breaks, it denies access rather than leaking it — and shows the user a clean, on-brand message instead of a raw error.
7. **Nothing ships without a PASS.** An adversarial pre-deploy review returns one verdict: PASS or BLOCK. A BLOCK stops the launch until it's cleared or a specific item is consciously waived and logged.

---

## How the principles become a process

The principles run through a three-phase gate with one hard bar.

**Phase 1 — Pre-Build.** Security is designed in: input validation on both ends, server-side authorization, secrets in environment variables, row-level security, vetted dependencies, and standard security headers. Clean, modular code with no dead weight — because unreadable code hides bugs.

**Phase 2 — Pre-Deploy.** The gate. A strict, adversarial, pen-test-style audit of the whole codebase — exposed secrets, SQL injection / XSS / IDOR, broken auth, open CORS, missing rate limits, tables open by default. Every finding is explained and fixed before launch. The audit ends in a one-line verdict: **PASS** or **BLOCK**.

**Phase 3 — Post-Deploy.** Monitoring from day one: structured error capture, a health-check endpoint, abuse signals (failed logins, rate-limit hits, anomalous single-IP traffic), and the ability to block an offending IP quickly.

**The bar:** nothing ships until Phase 1 and Phase 2 pass. A Critical finding is an automatic BLOCK; a High finding blocks unless it's consciously waived with a logged reason.

---

## Honest scope

These are strong, standard security practices applied to every build — not a formal certification. Builds are **not** presented as HIPAA or SOC 2 certified unless that is separately scoped and contracted. Where a project collects personal data, involves consumer-facing AI output, or carries specific compliance obligations, those are flagged for review rather than self-certified.

---

## Want the runnable version?

This playbook is the **why**. For the **what** — the exact adversarial review prompt, step by step, so you can run it on your own build — use the free *Run an AI security review before you ship* playbook at **hello.thecvmethod.com/playbooks**.

More free guides live there too.

Questions: **hello@thecvmethod.com**