Security by design.
Not a gate at the end of a feature. Not a checklist before the PR. Not a pentest before launch. A discipline woven through every phase of every build — and the philosophy behind everything on this site.
The defence is designed first.
Most security work happens at the end: build the feature, then scan it, then patch what the scan finds. That ordering is backwards — by the time the scan runs, the architecture has already decided what is defensible.
My discipline inverts it. Threats are modelled before the spec is written, the spec names its controls, an automated gate refuses to start a build with unresolved security gaps, and every phase leaves an evidence trail an auditor could follow.
It is not bureaucracy. It is the minimum viable process for building software that handles real user data — sized for a small team, enforced by tooling rather than memory, and self-improving: every solved problem feeds a pattern library so the next build starts further ahead.
How it actually works.
Threat-model
before you spec
STRIDE runs before a line of spec exists. Assets, threats, mitigations — decided before deciding what to build. You never write code you cannot defend, because the defence was designed first.
Controls chosen
at spec time
The specification names which security framework sections apply — OWASP, IAM, rate limiting, data classification, GDPR — and which controls will be implemented. Security requirements are requirements, not afterthoughts.
A gate that
can say no
Before implementation starts, an automated pre-flight reads the named sections and checks every mandatory control: satisfied, unsatisfied, or not applicable. One unsatisfied control and the build BLOCKS. Not a warning — a stop.
Evidence beats
assertion
After each security-relevant phase, an implementation note records the controls applied, the decisions made, the gaps found — referencing real code, tests and config. "Done" is not evidence. The audit trail is.
Patterns distil
over time
Solve the same security problem identically twice and the solution is promoted to a reusable pattern, linked back to the implementations that proved it. The library reflects what actually worked — not just what the standards say.
Risks are
never silent
When a control cannot be satisfied, it becomes a written risk decision: reason, owner, review date within 90 days, compensating mitigation. Accepted risks are visible. Invisible risks become incidents.
$ preflight --sections owasp,iam,rate-limiting
# extracting mandatory controls…
→ input validation SATISFIED
→ session lifecycle SATISFIED
→ rate limit + 429 contract UNSATISFIED
# one control unsatisfied
✗ status: BLOCKED # implement does not run
The gate in one trace: pre-flight reads the named framework sections, checks every control, and a single unsatisfied control blocks the build. Security debt cannot enter the codebase silently.
The whole scope.
The discipline runs on a maintained framework library — twenty documents spanning standards, models and regulation, each reviewed annually or immediately after an incident or standard change. A specification cites its sections by number; the gate enforces them.
OWASP reference
Web, API and Mobile Top-10s in one living document — the vulnerability map for every build.
Rate limiting
Limits, tiers and enforcement layers against abuse, brute force and resource exhaustion.
Identity & access
AuthN, authZ, RBAC, least privilege — broken access control is the #1 web and API risk.
Secrets management
Storage, rotation and audit of credentials. One exposed secret can compromise a system.
WAF & DDoS
Edge mitigation so malicious traffic dies before it reaches application code.
Threat modelling
STRIDE before code. Insecure Design is a Top-10 category because this step gets skipped.
ASVS checklist
Structured verification requirements — L1 for MVP, L2 before the first paying customer.
CIS benchmarks
Consensus hardening baselines that underpin SOC 2, PCI-DSS, ISO 27001 and NIST CSF.
Data classification
You cannot protect data you have not categorised. Four tiers, retention, encryption, deletion.
GDPR
Privacy by design as a competitive advantage, not just a legal requirement.
PCI-DSS
Tokenised payments that keep card data out of scope entirely — SAQ A, not SAQ D.
Disaster recovery
An untested DR plan is a hypothesis. RTO/RPO targets, runbooks, quarterly restore tests.
Vulnerability disclosure
A public, safe, legal channel for researchers — published before the first release.
Mobile (MASVS)
Mobile is a different attack surface. App-store review does not catch vulnerabilities.
Incident response
Six phases, tested — including the GDPR 72-hour breach notification clock.
SLA & uptime
Availability targets drive infrastructure decisions before customers depend on them.
SOC 2
Trust-services architecture built as habits first, certification second.
CCPA / PIPEDA
US and Canadian privacy law, staged in when users in those jurisdictions arrive.
Business continuity
DR covers systems; BCP covers the people, process and tooling around them.
Security by design
This page — the discipline that binds the other nineteen together.
Day one
Before the first line of production code
Pre-launch
Before the first real user
Early growth
First paying customer → 1,000 users
Scale
Beyond 1,000 users or regulated data
Not everything ships on day one — that would be theatre. Controls are staged by tier, and skipping a due control is only possible as a written risk decision with an owner and a 90-day review date.
Frameworks
Standards, models, controls, regulation. Authoritative; changes slowly; reviewed annually.
Implementations
Per-project, per-phase notes of what was actually built — real code, tests and config.
Patterns
Solved the same problem twice? It becomes a reusable pattern, linked to the builds that proved it.
Frameworks say what good looks like. Implementations prove it happened. Patterns stop the same problem being solved a third time. The library reflects what actually worked — not just what the standards say should.
Applied to the page you're reading.
This site runs a public endpoint and holds subscriber emails, so the discipline applies here too. All of this is verifiable — most of it in the privacy policy, the rest taught step by step in the newsletter security course.
Double opt-in
Newsletter consent is confirmed, not assumed — UK GDPR lawful basis by construction.
Rate limiting
20 requests/min/IP on the subscribe endpoint, standard 429 responses.
No raw PII in logs
The events table stores a numeric subscriber ID and salted IP/UA hashes — never an email address, raw or hashed. The logs cannot leak what they never held.
Secrets outside the webroot
.env lives above public_html, outside the webroot entirely; a global pre-commit hook screens every commit for identifier leaks.
Consent Mode v2, denied by default
No analytics cookies until the visitor accepts. Decline is a first-class path.
Incident response runbook
A written, newsletter-scoped IRP with a 72-hour breach SLA — before any incident, not after.