Threat modelling skills
employers want

Threat modelling is structured thinking about what could go wrong in a system's design. The Threat Modeling Manifesto summarises it in four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job?¹ Practically, that means building a model of the system (usually a data flow diagram with components, data stores, flows and trust boundaries), identifying threats using frameworks such as STRIDE, attack trees or attacker techniques from MITRE ATT&CK,² prioritising them, choosing mitigations, tracking them to completion and updating the model as the system changes.

The payoff is fixing flaws when they're cheapest. Verizon's 2026 Data Breach Investigations Report found 31% of breaches now start with exploited software vulnerabilities,³ and OWASP's Top 10 includes insecure design as a category of risk.⁴ Threat modelling is a core skill for security architects, who earn a typical ₹28.4–31.4 lakh in India, according to AmbitionBox.⁵

Key questions (Threat Modeling Manifesto)

4

STRIDE threat categories

6

Breaches starting with exploited software vulnerabilities (Verizon DBIR 2026)

31%

Typical security architect pay in India (AmbitionBox)

₹28.4–31.4 lakh

Table: How threat modelling skills are assessed (editorial summary)

Table: STRIDE applied to a statement-sharing API (illustrative)

Table: How threat modelling developed (editorial summary)

• A DFD with trust boundaries for a real feature
• A STRIDE analysis
• Prioritised threats with mitigations
• Mitigations tracked to completion
• A session you facilitated
• A verified threat modelling certificate

Show prevention: "Ran threat models for 12 new features; identified consent-bypass and token-logging flaws before launch; mitigations delivered in design phase."

"Threat model a login page."

Draw the flow, then consider credential stuffing, session hijacking, enumeration, MFA bypass and logging — with mitigations.

"Where do threats usually appear?"

At trust boundaries, data stores with sensitive data and privileged operations.

"How do you prioritise threats?"

By likelihood and impact in context, considering existing controls and exposure.

"How do you get developers involved?"

Short sessions on features they're building, with their diagrams and practical outcomes.

"How do you threat model an AI feature?"

Add prompt injection, data leakage, model misuse and excessive agent permissions to the threat list.

• "When in the lifecycle does modelling happen?" — timing.
• "Who participates?" — collaboration.
• "How are mitigations tracked?" — follow-through.
• "Are models kept up to date?" — maturity.

Table: Security design roles and typical pay in India (AmbitionBox, October 2026; indicative)

Table: Common threat modelling tools (editorial guidance)

• Developer / security analyst — joins sessions.
• AppSec engineer — runs feature models.
• Security architect — system and platform models.
• Principal security engineer — programme design.
• Head of product security — secure-by-design culture.

1. Week 1: Model — Draw a DFD for an app you know.
2. Week 2: Threats — Apply STRIDE; prioritise; propose mitigations.
3. Week 3: Prove it — Run a session with a friend; take the Threat Modeling Certification.

Related: Application Security, Cloud Security and Ethical Hacking. Guides: application security, cloud security and ethical hacking.

• Design reviews — new features.
• Sessions — with development teams.
• Tracking — mitigations to completion.
• Updating — models after changes.
• Coaching — security champions.
• Templates — reusable patterns.

"What's an attack tree?"

A diagram with an attacker's goal at the root and ways to achieve it as branches.

"Threat modelling vs penetration testing?"

Modelling finds design flaws early; testing finds implementation flaws later. Both are needed.

Table: A first-90-days plan (editorial guidance)

Start by modelling one important system with its engineers. Then make sessions part of feature design, keeping them short and practical. Create templates and track mitigations so the practice scales.

AI features bring new threat categories: prompt injection, sensitive data in prompts and outputs, model or training data theft, and AI agents with excessive permissions. Threat models for AI systems map data flows into and out of models, tools agents can call and where humans review outputs. AI assistants can also help draft DFDs and suggest threats, but they produce generic lists; the real value comes from people who know the system challenging assumptions together.

Invite the developers, a product owner and a security person. Spend 15 minutes drawing the data flow on a whiteboard, marking trust boundaries and sensitive data. Spend 25 minutes going boundary by boundary asking what could go wrong, using STRIDE as prompts. Spend 15 minutes prioritising and agreeing mitigations with owners. Use the last five minutes to agree when to revisit the model. Record everything in tickets. Short, regular sessions build a habit far more effectively than rare multi-day workshops.

Pick familiar systems: a food delivery app, a UPI payment flow, a college portal. Draw their likely data flows from what you can see as a user, mark trust boundaries and apply STRIDE. Compare your threats with public breach reports and OWASP guidance. Then model something you've built yourself, where you know the internals. Publishing a couple of clear models with mitigations is a strong portfolio piece for AppSec and architecture roles.

"It needs security experts only." Developers know the system best; security guides the process.

"It takes weeks." Focused sessions can take an hour.

"Do it once." Models age as systems change.

Rate each threat by likelihood and impact in your context, considering existing controls and exposure. Fix high-likelihood, high-impact threats first, accept low-risk ones with documented reasons and revisit priorities when the design changes.

• Threat lists without a system model.
• Using STRIDE as a rigid checklist.
• No prioritisation.
• Mitigations without owners.
• Stale models.

Threat modelling principles come from the Threat Modeling Manifesto; breach patterns from Verizon's 2026 DBIR; risk categories from OWASP; attacker techniques from MITRE ATT&CK; and India pay from AmbitionBox (read October 2026). The STRIDE example, session guide and history are editorial. Science of Apps publishes the free test linked here. Last reviewed October 2026.

• Threat model — structured analysis of what can go wrong.
• DFD — data flow diagram.
• Trust boundary — where trust levels change.
• STRIDE — six threat categories.
• Mitigation — a control that reduces a threat.