Security as blast-radius reduction

October 12, 2025

Zero trust, threat modeling, and secure coding practices — framed not as a checklist but as a way of thinking about how badly things can go wrong.

The mental model shift

Most security thinking is defensive in the "build walls" sense: validate inputs, add auth checks, scan dependencies. This is necessary. It's not sufficient.

The more useful frame is blast radius. Not "can an attacker get in?" but "if they get in, what can they reach?" A compromised credential that only accesses a read-only reporting database is a bad day. A compromised credential with admin access to production and the ability to read secrets is a catastrophe.

Blast-radius thinking produces different decisions. You separate environments even when a single environment would be easier. You give services the minimum permissions they need, not the permissions that are convenient. You put the most sensitive data behind an extra authentication step even when users won't love it.

The defaults that actually help

Safe code is code you don't have to actively remember to secure. Every time a developer has to remember to escape output or parameterize a query, there's a chance they forget. Build the safe path into the tools and conventions:

// The query library forces parameterization — you can't accidentally interpolate
await db.query("SELECT * FROM users WHERE id = $1", [userId])

The same principle applies to output encoding, auth middleware, and serialization. If the safe path is the default, you're not relying on individual vigilance.

For authorization, centralize the checks. A pattern where every endpoint independently checks permissions means a new endpoint is one missing check away from a privilege escalation bug. A pattern where authorization is enforced by middleware or a policy object means a missing check is obvious.

Zero trust is about verification density

Zero trust isn't a product you buy or a network topology. It's the practice of verifying identity and authorization on every request, at every boundary, without assuming anything is trustworthy because it's "internal."

Practically:

  • Service-to-service calls need authentication (mTLS, signed JWTs, workload identity)
  • Tokens should be short-lived and scoped to the minimum capability needed
  • "The database is on a private network" is not the same as "the database is protected"

Separate roles per environment. A service account that can read production data should not be the same credential you use in staging. When credentials leak — and they do — blast radius is the variable you control.

Threat modeling without the workshop

Formal threat modeling sessions are valuable. They're also slow and happen infrequently. A lightweight version embedded in the engineering workflow is more useful:

For any new feature, ask four questions before writing the first line:

  1. What are we protecting? (data, money, admin capabilities)
  2. Who might attack this, and what do they already have access to?
  3. Where do trust boundaries cross? (browser → API, API → database, third-party webhook → your system)
  4. What's the worst realistic failure, and how bad is it?

The answers don't need to be perfect. They need to surface the assumptions you're making before they become incidents.

High-leverage controls

Given limited time, these compound the most:

Secret detection in CI — blocks credentials from entering source history before they proliferate. A secret in git is a secret you have to rotate everywhere it was ever deployed.

Dependency scanning with auto-update PRs — most breaches involving open-source dependencies exploit vulnerabilities with patches that existed months before the breach.

Rate limiting on public endpoints — not primarily for DDoS (that's a different problem), but for credential stuffing and enumeration attacks that are quiet enough to evade simple monitoring.

Structured logging with security context — you can't investigate an incident from logs that don't contain the user, the action, and the relevant identifiers. Add these from the start.

References

Hi, I'm Martin Duchev. You can find more about my projects on my GitHub.