Best practices · Security
Threat Modeling Best Practices
Opens with creditsA practical guide to threat modeling for development teams who want it to be a normal part of design, not a yearly workshop. It covers the four questions, data flow diagrams and trust boundaries, STRIDE and abuse cases, rating and responding to threats, turning them into tickets and tests, keeping models current, and threat modeling features built on language models and agents.
Written by Tauseef Fayyaz6 chapters, 24 practicesAbout 28 min22 quiz questionsReviewed 13 October 2026What you will learn
6 chapters · about 28 min
1The four questions and the right mindsetWhat threat modeling is for, when to do it, and who should be in the room. The four questions give every session the same simple shape.4 practices · 5 min
2What are we working on: diagrams and trust boundariesA shared picture of the system is the foundation. This chapter covers data flow diagrams, trust boundaries, scope, and keeping the model where the team can update it.4 practices · 5 min
- What can go wrong: STRIDE, abuse cases and attack treesStructured prompts find more threats than open brainstorming. This chapter covers STRIDE per element, abuse cases, attack trees and privacy threats.4 practices · 5 minOpens with credits
- What are we going to do about it: decisions, tickets and testsA threat model is only worth the changes it causes. This chapter covers choosing a response, ranking threats, and turning decisions into work the team tracks and tests.4 practices · 4 minOpens with credits
- Making threat modeling routine and keeping models currentThreat modeling pays off when it is a normal step for every significant change. This chapter covers a lightweight per-feature practice, checking the work, and keeping models alive.4 practices · 4 minOpens with credits
- Threat modeling LLM and agent featuresFeatures built on language models add new trust boundaries: text that can act like instructions, outputs that reach other systems, and tools the model can call. The OWASP Top 10 for LLM Applications (2026 edition) gives the prompts.4 practices · 5 minOpens with credits
About this guide
Threat modeling is the habit of asking, before you build, how a design could be attacked or misused and what you will do about it. It finds the problems that scanners and code review cannot see, because they live in the design: a trust boundary nobody drew, an internal API that assumes every caller is friendly, an admin action without an audit trail, or an AI assistant that can call tools with the user's full permissions. Fixing those on a whiteboard costs minutes; fixing them after release can mean a redesign.
The good news is that threat modeling does not need a specialist or a week of meetings. The Threat Modeling Manifesto, written by a group of practitioners, reduces it to four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Adam Shostack, who created the framework, puts it plainly: sometimes asking those four questions is all you need, and that is far better than no threat modeling at all.
This guide follows those questions chapter by chapter. It shows how to draw a data flow diagram with trust boundaries, use STRIDE and abuse cases to find threats, rate and respond to them, and turn the results into tickets and tests your team already tracks. It then covers how to make the practice lightweight enough to run for every significant feature and keep models current, and closes with threat modeling for LLM and agent features using the OWASP Top 10 for LLM Applications. The advice draws on the Manifesto, the OWASP Threat Modeling Cheat Sheet, Microsoft's STRIDE guidance and Shostack's resources.
Common questions
What are the four questions of threat modeling?
What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? The Threat Modeling Manifesto and the OWASP Threat Modeling Cheat Sheet both structure the work around them, and Adam Shostack notes that simply asking them is far better than no threat modeling at all.
What does STRIDE stand for?
Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Each is the violation of a security property: authentication, integrity, accountability, confidentiality, availability and authorization. Walk the six categories across each element and trust boundary crossing in your data flow diagram.
When should a team do threat modeling?
Early, during design, and again whenever the design changes in a way that matters: a new service, integration, data store, permission, kind of sensitive data, or LLM feature. OWASP calls the model a living artifact, so update it after incidents as well.
How long does a threat modeling session take?
It depends on scope. Keeping each session to one feature or flow and time-boxing it makes it fit into normal design reviews; Shostack notes that many efforts start fast and cheap and grow from there. The output that matters is a response and an owner for every threat, not the length of the meeting.
What tools can I use for threat modeling?
A whiteboard or text diagrams in the repo are enough to start. OWASP Threat Dragon is a free, open-source tool supporting STRIDE, LINDDUN and other methods, and Microsoft offers the Threat Modeling Tool built around STRIDE. Track mitigations in your normal issue tracker.
How do you threat model an LLM application?
Draw every input to the model context as crossing a trust boundary, treat model output as untrusted input to whatever uses it, and treat each tool the model can call as a privilege. The OWASP Top 10 for LLM Applications (2026 edition) gives the categories to walk through, from prompt injection to excessive agency and unbounded consumption.
Sources (6)
Checked against these, last on 13 October 2026.
- Threat Modeling Manifesto, Threat Modeling Manifesto working groupwww.threatmodelingmanifesto.org/
- Threat Modeling Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
- Threats: Microsoft Threat Modeling Tool (STRIDE), Microsoft Learnlearn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
- Threat Modeling resources and the Four Question Framework, Shostack + Associatesshostack.org/resources/threat-modeling
- OWASP Threat Dragon, OWASPowasp.org/www-project-threat-dragon/
- OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Projectgenai.owasp.org/llm-top-10/
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
- Authorization Best PracticesGet access control right: deny by default, object-level checks against IDOR, RBAC vs ABAC vs ReBAC, tenant isolation with row-level security, audits and tests.
Checklists
See all- API Security ChecklistCheck your REST or GraphQL API against the OWASP API Security Top 10: authentication, object authorization, rate limits, input validation, SSRF, CORS and logging.
- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
Project structures
See all- AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
- Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks. - Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com