Episode 52 · Module 10 · Infrastructure

Day Zero — Bootstrapping Security for a New Project

19 May 2026 · 8:10 · Security for Legal SaaS

8:10 8:10

Day one is too late. The security posture of your legal SaaS platform is largely determined by decisions made before the first feature is built: which framework, which authentication library, which hosting provider, how secrets are stored, whether logging exists. These choices compound. A good foundation makes every subsequent security decision easier. A poor one creates debt that grows faster than feature code — because every feature built on an insecure foundation inherits its weaknesses.

Today’s Lesson

Security for Legal SaaS — Episode 52: Day Zero — Bootstrapping Security for a New Project

The Decisions You Make Before Writing Code

OWASP's Secure by Design Framework formalises this principle: security controls should be embedded at the design phase, not bolted on after deployment.¹ The framework's checklist covers trust boundaries (the points where data crosses from one trust level to another, as we introduced in Episode 1), encryption requirements, authentication and authorisation design, and incident readiness — all before a single line of application code is written.

For a legal tech team bootstrapping a new case management system, contract review tool, or e-filing platform, the question isn't "when do we add security?" It's "which security decisions do we make right now so we don't have to rewrite everything in six months?"

Tech Stack Choices with Security Implications

Your framework and library choices have security consequences that persist for the lifetime of the project.

Decision	Secure Default	Insecure Default
Web framework	Frameworks with built-in CSRF protection, XSS escaping, and parameterised queries (Django, Rails, Next.js)	Minimal frameworks that leave all security to the developer (Express without middleware)
ORM vs raw SQL	ORM (Object-Relational Mapper — a library that generates database queries from code, as covered in Episode 7) with parameterised queries by default	Raw SQL string concatenation
Authentication	Established library (NextAuth, Passport.js, Django Auth) with MFA support	Hand-rolled authentication logic
Hosting provider	Provider with managed TLS, DDoS protection, and compliance certifications (SOC 2, ISO 27001)	Self-hosted on unmanaged infrastructure
Secrets management	Dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, as covered in Episode 30)	`.env` files committed to version control

Framework defaults matter more than you think. Django auto-escapes template variables (preventing XSS — cross-site scripting, as covered in Episode 9), enables CSRF middleware by default, and uses parameterised queries through its ORM. A developer has to actively opt out of these protections. Express.js, by contrast, provides none of these by default — each must be added manually. The framework's opinion on security becomes your application's baseline.

The First-Commit Security Checklist

Before your first user, before your first feature branch, these controls must exist:

1. Repository Hygiene

`.gitignore` from commit one. Include `.env`, `.pem`, `.key`, `credentials.json`, and any framework-specific secret files. Secrets committed to Git history are nearly impossible to fully remove — even after deletion, they exist in the repository's history forever.

Pre-commit hooks. Install automated hooks (scripts that run before code is saved to version control) that scan for secrets. Tools like `git-secrets`, `detect-secrets`, or `trufflehog` catch API keys and credentials before they enter the repository. This is the safety net for human error.

Branch protection. Require pull request reviews before merging to the main branch. No direct pushes. This ensures at least one other person reviews every change — including changes to security-critical code.

2. HTTPS Everywhere

TLS (Transport Layer Security, as covered in Episode 13) must be active from the first deployment. Not "we'll add it before launch" — from the first time anyone accesses the application. Let's Encrypt provides free, automated certificates. Most modern hosting platforms (Vercel, Railway, Fly.io, AWS App Runner) provide TLS by default. There is no excuse for HTTP in 2026.

3. Authentication Library, Not Custom Code

Do not build your own authentication system. Use an established, well-audited library or service. For legal SaaS specifically, choose one that supports:

Multi-factor authentication (as covered in Episode 21)
OAuth 2.0 / OpenID Connect for enterprise SSO (as covered in Episode 20)
Session management with proper expiry and re-keying (as covered in Episode 19)
Audit logging of all authentication events

4. Secrets Manager from Day One

Never store secrets in code, configuration files, or environment variables committed to version control. Use a secrets manager — a dedicated service that stores, rotates, and provides access-controlled access to sensitive values. Set this up before you have secrets to store, so there's never a temptation to "just put it in `.env` for now."

5. Structured Logging

Configure structured logging (logs in a consistent, machine-readable format like JSON) from the start. Log authentication events, authorisation decisions, data access patterns, and errors. Not for debugging — for security. When (not if) you need to investigate an incident, logs are the evidence. OWASP's Logging Cheat Sheet provides detailed guidance on what to log and what not to log (never log passwords, tokens, or full credit card numbers).²

6. Dependency Scanning in CI

Add dependency scanning to your CI/CD pipeline (the automated system that builds and deploys your code, as we covered in Episode 46) from the first pull request. Tools like `npm audit`, `pip audit`, Snyk, or Dependabot continuously check your dependencies for known vulnerabilities. OWASP's Software Composition Analysis (SCA) project provides open-source options.³

The Minimum Viable Security Posture

What must exist before your first user accesses the system?

Control	Why It Can't Wait
HTTPS / TLS	Data in transit is readable without it; compliance requirement for any platform handling PII
Authentication with MFA	Single-factor auth on a platform storing client legal matters is a breach waiting to happen
Role-based access control	Without it, every user has the same permissions — including access to other clients' data
Input validation on all endpoints	First external request without validation is the first potential injection
Secrets in a secrets manager	First committed secret is a secret you'll spend days trying to remove from Git history
Automated dependency scanning	First unscanned dependency is a potential known-vulnerability in your supply chain
Structured security logging	First incident without logs is an incident you can't investigate

The legal standard: NYC Bar Formal Opinion 2024-3 clarified that lawyers' ethical obligations regarding cybersecurity extend to the technology platforms they choose. Selecting a platform that lacks basic security controls — or building one without them — is not a defensible "reasonable efforts" position under ABA Model Rule 1.6(c).⁴

Security Debt Compounds Faster Than Technical Debt

Technical debt — shortcuts in code quality that slow future development — is well understood. Security debt is worse. Every day a vulnerability exists in production is a day it can be exploited. And unlike technical debt, where the cost is developer time, security debt can cost you your clients' data, your professional obligations, and your business.

Consider a concrete example. Your team builds a case management system. On day one, authentication is username/password only, stored in a single database table. Six months later, a law firm customer asks for SSO integration with their Azure AD. You discover that your authentication system is so tightly coupled to the rest of the application that adding SSO requires rewriting the login flow, the session management, the permission checks, and the audit logging. A three-day integration becomes a three-month rewrite.

If you'd started with an authentication library that supported SSO from day one, the integration would have been configuration, not architecture.

OWASP SAMM (Software Assurance Maturity Model) provides a structured framework for measuring and improving your security posture over time, with maturity levels that scale from "getting started" to "optimised."⁵ Starting at Level 1 on day zero is realistic. Starting at Level 0 and trying to catch up later is where projects fail.

The Day-Zero Mindset

Bootstrapping security doesn't mean building a fortress before writing features. It means making choices that don't foreclose security later:

Choose frameworks with secure defaults — so developers fall into the safe path
Set up secret management before you have secrets — so there's no "temporary" plaintext
Install pre-commit hooks before the first commit — so secrets never enter history
Add dependency scanning before the first dependency — so nothing slips through unchecked
Configure logging before the first user — so the evidence exists when you need it
Pick an auth library that supports MFA and SSO — so you don't rewrite login in six months

The decisions you make before writing code determine how hard everything else will be. Make them well.

Next episode: we shift from building to watching — monitoring and alerting design for detecting attacks in progress.

Sources & references

OWASP, Secure by Design Framework.
OWASP, Logging Cheat Sheet.
OWASP, Dependency-Check: Software Composition Analysis.
NYC Bar Association, Formal Opinion 2024-3: Ethical Obligations Relating to a Cybersecurity Incident.
OWASP, Software Assurance Maturity Model (SAMM).
OWASP, Establishing a Modern Application Security Program — OWASP Top 10:2025.
OWASP, Secure Development and Integration — Developer Guide.
OWASP, OWASP in SDLC — Integration Standards.
ABA, Cybersecurity for Law Firms: ABA Compliance Guide.
NIST, SP 800-218: Secure Software Development Framework.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 52, and we're calling this one Day Zero. Alice, we've spent fifty-one episodes talking about specific security controls — authentication, encryption, input validation, cloud permissions, AI code risks. Today feels like we're stepping back and asking: if you're starting a new project from scratch, where do you actually begin?

Alice: And the key insight is that day one is already too late. The security posture of your application is largely determined by decisions you make before writing the first feature. Which framework you pick, how you store secrets, whether you set up logging. These are architectural choices, and if you get them wrong, fixing them later means rewriting, not patching.

Dan: Mm. That sounds abstract. Can you make it concrete?

Alice: Sure. Imagine you're building a case management system for law firms. On day one, you set up authentication as a simple username-and-password table in your database. You write the login flow yourself. Six months later, your first enterprise customer says: "we need single sign-on with our Azure Active Directory." You go to integrate it — and you discover that your custom login code is tangled into every part of the application. The session management, the permission checks, the audit logs — all of it assumed your hand-built auth. Adding SSO isn't a three-day integration. It's a three-month rewrite.

Dan: Right.

Alice: If you'd started with an authentication library that already supported SSO — something like NextAuth or Django's built-in auth system — that integration would have been configuration, not surgery. The day-zero decision saved you three months.

Dan: Yeah. So what's on the day-zero checklist? If someone's starting a legal tech project tomorrow, what do they do first?

Alice: Framework choice matters enormously. Pick a framework with secure defaults. Django, for example, auto-escapes template output — that's protection against cross-site scripting, which we covered in Episode 9. It enables CSRF protection by default — that's protection against forged requests, Episode 12. It uses parameterised database queries through its ORM — protection against SQL injection, Episode 8. A developer using Django has to actively opt out of these protections. Compare that to a minimal framework like Express.js, where none of those protections exist by default. You have to add each one manually. The framework's opinion on security becomes your application's baseline.

Dan: Mm-hmm. What about secrets — API keys, database passwords?

Alice: Set up a secrets manager before you have secrets to store. AWS Secrets Manager, HashiCorp Vault — we talked about Vault back in Episode 15 — or even a simpler service if you're just starting. The point is: there should never be a moment where someone thinks "I'll just put this API key in the dot-env file for now." Because "for now" becomes "forever." And once a secret is committed to Git — to your version control history — it's there forever. Even if you delete the file, the secret exists in the history. Removing it properly requires rewriting Git history, which is painful and error-prone.

Dan: Hmm. And that's why the gitignore file matters from the first commit?

Alice: From commit zero. Your dot-gitignore should exclude dot-env files, private key files, credential JSON files, anything framework-specific that contains secrets. And install pre-commit hooks — those are automated scripts that run before code is saved to version control — that scan for secrets. Tools like git-secrets or detect-secrets will catch an API key before it enters the repository. It's a safety net for the inevitable moment when someone forgets.

Dan: Right. What about HTTPS? When does that go live?

Alice: From the first deployment. Not "before launch," not "when we get a domain" — from the first time anyone accesses the application over a network. Let's Encrypt provides free TLS certificates. Most modern hosting platforms — Vercel, Railway, Fly.io — handle it automatically. We covered TLS in Episode 13. There is no reason for unencrypted HTTP in 2026, especially for anything touching legal data.

Dan: And logging?

Alice: <sigh> Logging is the one that gets skipped the most, and it's the one you most regret skipping when something goes wrong. Set up structured logging — that means logs in a consistent, machine-readable format, usually JSON — from the start. Log every authentication event. Every authorisation decision. Every data access that touches client records. Not for debugging — for security. When you need to investigate an incident, logs are your evidence. If they don't exist, you're investigating blind.

Dan: Mm. OWASP has guidance on what to log and what not to log, right?

Alice: Their Logging Cheat Sheet is excellent. The key rule: log the event, not the secret. Log "user 47 attempted login at 14:32, failed" — don't log the password they typed. Log "API key rotated for service X" — don't log the new key value. And don't log full credit card numbers, social security numbers, or client document contents. The log itself becomes a target if it contains sensitive data.

Dan: Yeah. What about dependency scanning? When does that start?

Alice: Before the first dependency. Add a scanning tool — npm audit, pip audit, Snyk, Dependabot — to your CI/CD pipeline from the first pull request. Every dependency you add is code you didn't write and can't fully inspect. Scanning catches known vulnerabilities automatically. We talked about supply chain risks extensively in the last episode with AI-generated code. This is the same principle applied to all third-party code.

Dan: So to summarise the day-zero list: secure framework, secrets manager, gitignore and pre-commit hooks, HTTPS from first deployment, authentication library with MFA and SSO support, structured logging, dependency scanning in CI, and branch protection requiring code reviews.

Alice: That's the minimum viable security posture. None of it is exotic. None of it requires a security team. It's all choices you make at the start that prevent months of rework later. Security debt compounds faster than technical debt, because every day a vulnerability exists in production is a day it can be exploited. And unlike slow code that just frustrates users, a security flaw can cost you your clients' data and your professional obligations.

Dan: Mm. And there's an ethical dimension too, right? For anyone building software that lawyers use.

Alice: The NYC Bar issued a formal opinion in 2024 clarifying that lawyers' ethical obligations extend to the technology platforms they choose. If you're building legal SaaS and you haven't implemented basic security controls, you're making it harder for your lawyer-customers to meet their obligations under ABA Model Rule 1.6(c) — the rule requiring reasonable efforts to protect client information. "We'll add security later" is not a defensible position.

Dan: Next episode — monitoring and alerting. How to detect attacks in progress, and why alert design matters as much as detection logic.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.