Security for Builders: Threat Modeling and Secure-by-Default Systems

Most teams don’t “ignore security”.

They postpone it.

And then reality shows up in a very predictable way:

• a leaked API key
• a public bucket
• a dependency with a CVE you didn’t know you shipped
• a prod admin endpoint that was “temporary”
• an auth bug that turns “one user” into “everyone’s data”

Security failure is rarely one dramatic bug.

It’s usually a chain of reasonable decisions that never had a chance to be safe.

This post is about breaking that chain early — with two habits that scale:

1. Threat modeling you can actually run (without a security team)
2. Secure-by-default architecture (so mistakes don’t become incidents)

The Only Security Model That Matters: Trust Boundaries

If you remember one concept, make it this:

A system is secure when every trust boundary is explicit and defended.

A trust boundary is where you change assumptions:

• Internet → your edge
• edge → backend
• backend → database
• service A → service B
• your app → third-party API
• user input → business logic
• CI → production

Most incidents are boundary failures:

• “we assumed this request was internal”
• “we assumed this token was valid forever”
• “we assumed this bucket was private”
• “we assumed retries wouldn’t duplicate side effects”

So threat modeling is just… mapping boundaries and asking:
“what if the assumption is wrong?”

Threat Modeling That Fits a Real Team

Threat modeling has a reputation for being heavyweight.

It doesn’t have to be.

For most products, a small, repeatable exercise beats a perfect model you never run.

A pragmatic scope: “the 5 assets”

Start by naming the assets that would hurt to lose:

• Identity (sessions, tokens, MFA, password resets)
• Data (PII, invoices, policy docs, trade secrets)
• Money / side effects (payments, refunds, credits, emails, webhooks)
• Admin powers (support tools, impersonation, feature flags, backdoors)
• Availability (DoS, cost blow-ups, queue overload, dependency outages)

If you protect these five, you’re already ahead of most systems.

A 45-Minute Threat Model You Can Run Every Sprint

This is the cadence I’ve seen work: small, consistent, and tied to real changes.

Secure-by-Default: The Architecture Patterns That Prevent Incidents

“Secure by default” means:

• the safe behavior happens without remembering
• mistakes fail closed
• “unknown” does not become “allowed”

These patterns show up everywhere — in code, infrastructure, and operations.

Let’s make them concrete.

Identity: Authentication Is Not Authorization (And Both Need Boundaries)

Most “big” security failures are authorization failures.

Because auth is visible (“login worked”), while authz is subtle (“should this user access that resource?”).

Builder’s rules of thumb

• Authenticate at the edge, authorize in the service.
  • Edge can verify tokens.
  • Service must enforce resource-level authorization.
• Never trust a client-provided identifier.
  • If the client says accountId=123, treat it as a request, not truth.
• Prefer “scoped tokens” over “god tokens”.
  • Short lifetimes, specific audiences, specific permissions.
• Make admin different.
  • Separate domain, separate auth, separate logs, separate rate limits.

A simple authorization shape that scales

• global role (employee, user, partner)
• resource ownership (this policy belongs to this account)
• capability checks (can:view, can:edit, can:refund)
• policy enforcement at service boundaries (not in the UI)

When in doubt, centralize the rules logically (shared library / policy module),
but enforce them physically at every service boundary.

Data Protection: Classify It, Then Protect It

You don’t need a 200-page policy.

You need three classes and consistent handling.

Practical controls that matter

• Encrypt in transit: TLS everywhere (service-to-service too).
• Encrypt at rest: disk/db encryption + key management.
• Centralize keys: use a KMS, not “a secret in an env var forever”.
• Backups are part of security: ransomware is a security incident.
• Audit access to sensitive data (who accessed what, when).

Input Boundaries: Validate, Normalize, and Reduce Ambiguity

A surprising number of vulnerabilities come from the same root:

“We interpreted input in a way the attacker controlled.”

Builder-friendly rules:

• Prefer allowlists over blocklists.
• Validate at the boundary, not deep inside business logic.
• Normalize before validating (case, unicode, whitespace).
• Treat every parser as an attack surface (JSON, XML, CSV, image processing).

Safer API design reduces your security workload

• Use typed contracts (OpenAPI/JSON schema) and validate requests.
• Avoid “polymorphic” endpoints that do too many things.
• Make unsafe operations explicit (DELETE is different than UPDATE).
• Require explicit idempotency for side effects (payments, emails, webhooks).

Supply Chain Security: You Ship Other People’s Code (So Own It)

Modern apps are dependency graphs wearing a logo.

Supply chain failures are common because they exploit defaults:

• dependencies float to new versions
• build systems run with broad permissions
• images come from “latest”
• secrets end up in build logs

What “good” looks like (without boiling the ocean)

• Pin dependencies and update intentionally.
• Scan dependencies (SCA) and block known critical issues.
• Use minimal base images and patch regularly.
• Generate an SBOM for your releases (what did we ship?).
• Sign artifacts or use provenance where possible (who built this? from what?).

CI/CD Controls That Actually Improve Security

Security isn’t just “more scanners” — it’s making unsafe changes harder to ship.

A few deploy-time controls have outsized impact:

• Separate build and deploy identities
  • build can read source; deploy can change prod
  • ideally no single identity can do both
• Policy-as-code for infrastructure
  • public buckets, open security groups, wildcard IAM → block at PR time
• Secret scanning
  • prevent the leak from entering git or logs in the first place
• Two-person rule for dangerous changes
  • identity, money movement, network exposure, production admin

Observability for Security: You Can’t Defend What You Can’t See

Security incidents are debugging problems with worse consequences.

At minimum, make sure you have:

• audit logs for admin actions (who changed what, when)
• authentication logs (failed logins, token anomalies)
• permission denials (so you can detect probing)
• rate limit events (so you can detect brute force and cost attacks)
• high-signal alerts (not 200 “CPU high” alerts)

If it changes money, identity, or access… it must be observable.

Checklists You Can Actually Use

These are meant to be copy/paste-able into tickets.

Resources

FAQ

What’s Next

Security is mostly about constraints.

The next month is about the other place constraints matter:

data and workflows across boundaries.

In May:

Distributed Data

Because once you split systems apart, correctness becomes a design choice — and security depends on correctness more than people admit.