Journal · Security

Threat modelling for services that are still small

A one-afternoon method for mapping assets, trust boundaries and mitigations before a service gets large enough to hurt.

Published
2026-07-30
Read time
10 min
Author
DevCSE Platform
Desk
Security desk

Start with a drawing

List the assets that matter — credentials, personal data, money movement, availability — then draw where each one crosses a trust boundary. Almost every real incident lives on one of those crossings.

Enumerate, then rank

Walk each boundary and ask what an attacker gains by controlling one side of it. Rank the results by blast radius and by how cheap the attack is to attempt, not by novelty.

  • Authentication and session handling at the client boundary.
  • Authorisation checks on every server-side data path, not just the UI.
  • Third-party callbacks: verify signatures before parsing anything.
  • Secrets: server runtime only, never shipped to the browser.

Mitigate and record

Each ranked threat gets a mitigation, an owner and a test. The test is the part most teams skip, and the part that keeps the model true as the service changes.

Revisit on change

New integration, new data class, new region: each is a reason to reopen the drawing. A threat model is a living artefact or it is decoration.

Questions

Questions, answered

01Who writes the journal?

The platform team and reviewing engineers. Every post comes out of work that actually shipped, not from a content calendar.

02How often is it published?

Weekly on average. A post goes out when the reasoning is worth reading, not to fill a slot.

03Can I republish a post?

Quote freely with attribution and a link back. Ask the contact desk before republishing in full.

04Can members contribute?

Yes. Write up a build or an incident, send it through the contact composer, and the editorial desk will review it.