The blind spot that gets expensive
Every founder we work with has a budget for design and a budget for engineering. Almost none of them, until something goes wrong, have a budget for security. The result is a fairly consistent pattern: a startup ships a product, grows for two or three years, has a near-miss or an actual breach, and discovers in the post-mortem that the security work that would have prevented it would have cost a fraction of the breach itself.
This post is the briefing we wish every founder had before they wrote their first line of production code. It is opinionated, it is specifically for non-security-expert technical founders, and it skips the parts you can pay a vendor to handle later.
The mental model: assume compromise
The first conceptual shift is to stop treating security as a perimeter ("keep the bad people out") and start treating it as a depth strategy ("when bad things happen, contain them, detect them, recover"). This is sometimes called "assume compromise" or "defence in depth", and it changes most of the practical decisions you make.
A perimeter mindset asks: "How do I make my login flow unbreakable?" That is the wrong question because no login flow is unbreakable. The right questions are: "If an attacker compromises one user's account, how much can they access? How quickly will I know? How fast can I lock them out and recover?" These are answerable, and the answers tell you where to invest.
The OWASP Top 10, but practical
The OWASP Top 10 is the canonical list of web application risks. We rephrase it for founders as a checklist:
Broken access control. The most common breach pattern. Users accessing data they shouldn't because the application checked authentication but not authorisation. The fix: every database query must filter by the authenticated user's ID, every admin route must check role, and these must be tested explicitly with end-to-end tests.
Cryptographic failures. Sensitive data stored or transmitted without proper encryption. Fix: TLS everywhere, AES-256 for data at rest, never invent your own crypto, and rotate secrets on a schedule.
Injection. SQL injection, NoSQL injection, command injection, prompt injection. Fix: never concatenate user input into queries or shell commands. Use parameterised queries. For LLM applications, be very explicit about what user-controlled text is allowed to influence what system behaviour.
Insecure design. Architecture-level vulnerabilities. Fix: threat-model every feature before it ships. Ask "what could go wrong" with the same energy you ask "what could go right".
Security misconfiguration. Default credentials, exposed S3 buckets, debug endpoints in production, verbose error messages that leak stack traces. Fix: production deployments must lock down anything not explicitly required, and a security review is part of every infra change.
Vulnerable components. Out-of-date dependencies with known CVEs. Fix: automated dependency scanning (Dependabot, Renovate, Snyk). Patch on a schedule, not when something hurts.
Auth failures. Brute force, credential stuffing, weak password policies, missing MFA. Fix: rate-limit login attempts, support TOTP and WebAuthn, ban known-breached passwords (Have I Been Pwned API), and require MFA for any admin role.
Data integrity failures. Tampered software updates, deserialisation of untrusted data, supply chain attacks. Fix: verify package signatures, lock dependency versions in CI, and audit any third-party code paths that handle privileged data.
Logging and monitoring failures. A breach can sit undetected for months because the team isn't watching the right signals. Fix: centralise logs, alert on anomalies, retain enough history to investigate. We typically use Datadog, Sentry, or similar; the choice matters less than the discipline of actually reading the alerts.
SSRF. Server-side request forgery — your server fetches a URL that the attacker controls. Fix: block private IP ranges from any URL-fetch path that's user-controllable, especially for cloud-hosted apps where SSRF can leak instance metadata.
What to do this week if you have nothing
If you are a founder reading this and you have no security baseline, here is the smallest set of things to put in place this week. None of them are expensive, all of them prevent the most common attacks.
Multi-factor authentication everywhere. Every admin login, every cloud console, every code repository. No exceptions, including for the founder. Most breaches we audit start with a stolen password that should have required MFA.
Secret management. No API keys in the repo. No .env files committed by accident. Use a secret manager (AWS Secrets Manager, Doppler, 1Password) and rotate secrets on a schedule. Audit your repo for accidentally-committed secrets — there are tools (TruffleHog, GitLeaks) that can do this in five minutes.
Backups. Automated, tested, off-site. The test is the part teams skip. A backup that has never been restored is a backup that probably doesn't work.
Patch automation. Turn on Dependabot or equivalent. Merge the security PRs. The interval between a CVE being disclosed and being exploited at scale is now measured in hours.
Principle of least privilege. Every IAM role, every database user, every API token should have the minimum permissions necessary. The default for "I'm not sure" should be "less".
When to hire help
You can run the basics yourself. The decision point for hiring help is usually one of these:
You're going to handle regulated data. Healthcare (HIPAA), payments (PCI), or anything in the EU (GDPR). The compliance overhead is genuinely outside what most engineering teams can self-manage.
You're approaching a security review for an enterprise sale. Customers in the Fortune 500 will require a SOC 2 report, sometimes ISO 27001. Both are workable, but neither is fast — six to twelve months end to end, and starting six months before you need it is wise.
You've grown past 50 employees. At this scale the attack surface — number of devices, accounts, repos — is large enough that a part-time security lead pays for themselves in incidents avoided.
The unsexy truth
Most security work is not glamorous. It is mostly hygiene: patch your dependencies, rotate your secrets, log your events, review your access regularly, train your team to spot phishing. The exotic attacks (zero-day exploits, nation-state APTs) get the headlines, but the breaches we actually see in the wild are mostly the result of a missing patch, an unrotated key, or a team member who clicked a bad link. You can avoid most of them with discipline that costs almost nothing relative to the size of the loss.
If you are a founder and you take one thing from this post, take this: security is a budget you build slowly and never finish. Start the budget now. The day after a breach is the worst time to start.