Threat Modeling: Anticipating Attacks Before Code Is Written

Most modern approaches follow Adam Shostack’s Four Question Framework (“Threat Modeling: Designing for Security”, 2014): What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? The four questions structure the process into system modeling, threat identification, mitigation planning and validation – regardless of which specific method is applied. The Threat Modeling Manifesto accordingly defines threat modeling as analyzing representations of a system to highlight concerns about its security and privacy characteristics. The decisive shift is one of perspective: not checking whether requirements are met, but systematically asking what an attacker could do with the design.

STRIDE – formulated in 1999 by Loren Kohnfelder and Praerit Garg at Microsoft and later a core element of the Microsoft Security Development Lifecycle – categorizes threats into six classes, each violating a security property: Spoofing (authentication), Tampering (integrity), Repudiation (non-repudiation), Information Disclosure (confidentiality), Denial of Service (availability) and Elevation of Privilege (authorization). PASTA (Process for Attack Simulation and Threat Analysis; UcedaVélez/Morana, 2015), by contrast, is risk-centric: across seven stages – from defining objectives through technical scope, decomposition, threat and vulnerability analysis to attack modeling and risk/impact analysis – the method links simulated attacks to their business impact. Attack trees (Bruce Schneier, 1999) model an attack goal as the root node and decompose it via AND/OR relationships into concrete attack paths that can be evaluated by cost or probability of success, for example. In practice, the approaches complement each other: STRIDE for systematic breadth, PASTA for the risk perspective, attack trees for in-depth analysis of individual scenarios.

The foundation of almost every analysis is a data flow diagram (DFD): external entities, processes, data stores and data flows map the system, while trust boundaries mark the transitions between zones of differing trust – between the internet and the backend, for instance, or between application and database. Threats concentrate at these boundaries, which is why they are the natural starting point for the systematic walkthrough. For complex systems, several diagrams at different levels of detail are common: an overview of the overall system, complemented by detailed views of critical components. The diagram remains a means to an end – a model that carries the team discussion matters more than perfect completeness.

In 2020, a group of 15 experts from industry and research published the Threat Modeling Manifesto, deliberately modeled on the Agile Manifesto. It formulates five values, including: a culture of finding and fixing design issues over checkbox compliance, people and collaboration over processes, methodologies and tools, and continuous refinement over a single delivery. Four principles make the implementation concrete – for instance, that early and frequent analysis improves security and privacy, and that threat modeling must align with the team’s development practices and iterations. In addition, the manifesto names beneficial patterns such as a systematic approach and varied viewpoints, as well as anti-patterns such as the “hero threat modeler” or striving for the perfect representation.

OWASP Threat Dragon provides a free modeling tool with OWASP production status that, as a web and desktop application, creates diagrams and documents threats according to STRIDE, LINDDUN and PLOT4ai, among others (current version 2.6.2, May 2026); the Microsoft Threat Modeling Tool is also well established. OWASP pytm (a lab project) takes a different route: the architecture is described as Python code, from which the framework generates data flow diagrams, sequence diagrams and threat reports. This threat modeling as code makes models versionable, reviewable in code reviews and automatable in CI/CD pipelines – architecture and threat model go through the same change process. Automation does not replace joint analysis in the team, it scales it: generated threat lists are a starting point, not the end result.

The NIST Secure Software Development Framework (SP 800-218, version 1.1) makes threat modeling an integral part of secure development: task PW.1.1 calls for forms of risk modeling – explicitly including threat modeling, attack modeling or attack surface mapping – to assess the security risk of a piece of software. In agile teams this does not work as a one-off large workshop but incrementally: security-relevant features, new interfaces or architecture changes trigger a focused analysis whose results flow into the backlog; anchored as a criterion in the Definition of Done, threat analysis becomes the rule rather than the exception. That is exactly what the manifesto demands: early and frequent analysis, adapted to the team’s iterations. For agentic AI systems, however, classic methods fall short – for these, the Cloud Security Alliance published MAESTRO in 2025, a dedicated seven-layer framework that we explore in depth in our knowledge article on MAESTRO in the Agentic AI Security topic area.