Practical security for people who build software. Threat modeling, cryptography you can actually use, software supply chain risk, identity and access, and the new attack surface created by AI agents and data pipelines. Less checklist compliance, more understanding how attacks actually work and how to design systems that resist them.

Threat Modeling for Engineers - Finding the Flaws Before Attackers Do Banner

Threat Modeling for Engineers: Finding the Flaws Before Attackers Do

TL;DR A scanner finds bugs in code that already exists. Threat modeling finds flaws in a design before the code exists - which is the cheapest possible time to find them It is a structured conversation built around four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job STRIDE gives you a vocabulary for “what can go wrong”: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege You do not need a tool or a certificate. You need a diagram, the people who understand the system, and an hour The highest-value moment to threat model is when the design is still cheap to change - and the most common mistake is treating it as a one-off audit instead of a habit Most security work, as people experience it day to day, is reactive. A scanner flags a vulnerable dependency. A penetration test produces a report. An alert fires. Someone patches the thing, closes the ticket, and moves on. This is necessary work, but it has a structural weakness: it can only find problems in systems that already exist. By the time a scanner can see a flaw, you have already built it, shipped it, and possibly run it in production for months. ...

May 20, 2026 · 9 min · James M