Threat-modeling this garden
Eating my own dog food: a security person's website should survive its own methodology.
Taking shape. Has structure and at least one real source or experiment.
If I review other people’s systems for a living, this site should survive the same treatment. So: a threat model for a digital garden, kept honest in public.
Assets
Almost none and that’s the design. No user accounts, no comments, no form submissions, no database. The assets are: integrity of the content (don’t let anyone publish as me), availability (stay up), and visitor privacy (collect nothing, leak nothing).
Architecture as mitigation
The site is statically generated and served from a CDN. That single decision deletes most of the classic attack surface: no server-side code to exploit, no sessions to hijack, no injection sinks, nothing stateful to corrupt. It’s the same blast-radius instinct as cloud-iam-blast-radius, applied to a website.
What remains, and what answers it:
- Supply chain (the real risk): compromised npm dependency or build pipeline → minimal dependency count, lockfile pinning, build in CI from a protected branch.
- Account takeover: registrar/DNS/repo hijack → hardware-key 2FA on Cloudflare and GitHub; DNSSEC on the domain.
- Content tampering in transit: HTTPS everywhere, HSTS, and a CSP strict enough that even a reflected script has nowhere to run.
- Visitor tracking by my own tools: refused by construction, with no analytics and no third-party origins. The CSP makes this promise enforceable, not aspirational.
The honest tension
There’s a second reason this site exists, and it cuts against everything above: building it by hand is how I sharpen my web red teaming. Reading other people’s code pays the bills, but writing your own and then turning on it is how the lessons actually stick. So read the mitigations above as intent, not warranty. Hand-rolled code has bugs. Some of them are mine, and I haven’t found them yet.
Which is a roundabout way of asking: please don’t actually hack my blog. If you go poking and something gives, that’s a win for both of us, so tell me about it instead of lighting it up. The responsible-disclosure route, a security.txt and a real mailbox, goes live with the domain. Until then I’m trusting you to be the kind of guest who spots the unlocked window and mentions it on the way out, not the kind who climbs through.
The meta-lesson belongs in the-attackers-mindset-is-systems-thinking: the cheapest vulnerability to fix is the component you never built.
Paths that lead here
- The attacker's mindset is systems thinking · Attackers don't break rules; they discover that the rules compose differently than the designers believed.
Where this note points
- Cloud IAM: measure blast radius, not policy count · The security of a cloud account isn't the sum of its policies; it's the reachability graph they create.
- The attacker's mindset is systems thinking · Attackers don't break rules; they discover that the rules compose differently than the designers believed.
More from these beds
- Learning in public · The operating philosophy of this whole garden: publish the process, not just the conclusions.
- Metacognition, Eileen Gu, and the Fear of Going Public · The thing elite performers and good thinkers share is not raw talent; it is metacognition, the skill of watching your own mind. Here is what it is, why putting yourself out there feels so irreversible, and why the spotlight effect means it matters less than you think.
- AI Slop and the Quiet Cost of Foraging · Maggie Appleton calls it jetspraying the web with AI slop. Here is why that cheap flood is so exhausting, told through Information Foraging Theory, and why your tiredness is a rational response, not a personal failing.
- Not a Toaster: The Secret Superpower Called 'Why?' · A toaster never asks whether it should toast. Humans do, and that pause has a name. A tour of philosophy: first principles, the Socratic method, epistemology, and why the annoying 'Why?' game is a real superpower.