Threat-modeling this garden

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, measure what a compromise can reach and then cut the edges, 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.