DevSecOps Practice Hub

Threat Modeling

Identify what can go wrong in a design before it is built, and record the mitigations chosen.

IntermediateSecure CodingApplicationGovernance

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Plan Threat modeling, requirements and security design decisions.

Overview

A lightweight threat model is a diagram of components and trust boundaries plus a structured discussion of what an attacker could do at each boundary, and what mitigates it.

Why it matters

Design-level flaws cannot be scanned for and are the most expensive to fix later.

How it works

  1. 01Draw the system: components, data flows, trust boundaries.
  2. 02Walk boundaries with STRIDE or a simple 'what could go wrong' prompt.
  3. 03Record threats, decisions and accepted risks in the repository.
  4. 04Revisit when the architecture changes materially.

Common tools

OWASP Threat DragonMiroGitHub

Implementation examples

markdownThreat model record
## Boundary: public API -> payments service- Threat: tenant A reads tenant B invoices (Elevation of privilege)- Mitigation: tenant ID derived from token claims, never from request body- Test: integration test asserts cross-tenant read returns 404- Status: implemented
Keeping the model in git makes it reviewable and keeps it current with the code.

Best practices

  • Timebox to one session per significant design.
  • Attach a test to every mitigation.

Common mistakes

  • Producing a large document nobody revisits.