Threat Modeling in Thirty Minutes

This post started as a note to my future self. Every few months I relearn the same lessons about threat modeling, so this time I'm writing them down.

Most of the complexity was accidental. Over the years we'd layered three different approaches to threat modeling on top of each other, and each one made sense at the time.

Some background

The setup was ordinary: OWASP ZAP at the edges, Vault doing most of the heavy lifting, and a handful of scripts nobody wanted to own. It worked well until usage roughly doubled over a single quarter.

When we finally measured, the numbers were worse than anyone guessed. Around 26% of the time spent on a typical change went into working around threat modeling rather than building anything.

How it works

We started by writing down the one rule we actually cared about, then deleted every bit of code that didn't serve it. It's not glamorous, but it works.

Stripped of the project-specific bits, it looks like this:

Content-Security-Policy: default-src 'self';
  script-src 'self' 'nonce-r4nd0m';
  style-src 'self';
  img-src 'self' data:;
  frame-ancestors 'none';
  base-uri 'self'

Nothing about this is clever, and that's the point. Anyone on the team can read it in a minute and know exactly what it does.

A few things that helped along the way:

Measure before and after, even if it's just a rough number in a spreadsheet.
Delete dead code aggressively; it's the cheapest refactor there is.
Write the migration guide before writing the migration.

What it cost us

None of this is free. The new approach is a bit more verbose, and newcomers occasionally ask why we don't just use Semgrep for everything. That's a fair question with a boring answer: we tried, and it made threat modeling harder to reason about.

We still haven't solved session management. That's a post for another day, and honestly, I'm not sure we'll get it right the first time either.

Takeaways

I don't think there's a universal answer here, but I hope this gives you a few ideas to try on your own project. If you do, I'd love to hear how it goes.