How do I install the Defense Threat Modeling skill?

Run npx skillmds@latest add noorqureshi/defense-threat-modeling in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Defense Threat Modeling safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Defense Threat Modeling?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Defense Threat Modeling free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Defense Threat Modeling?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Defense Threat Modeling by noorqureshi

Name: Defense Threat Modeling
Author: NoorQureshi

Defense Threat Modeling

Threat-model a system or feature (STRIDE + attack trees) to find design-level risk before code. Load on "threat model", a new design/architecture review, security design questions, or planning controls. Signals: architecture diagram, data-flow, "what could go wrong", pre-build security.

NoorQureshi Updated Sep 17, 2026

File contents

Threat modeling (STRIDE + attack trees)

When it applies

Before or during design — a new feature, service, or architecture — to find what can go wrong at the design level, where fixes are cheapest. Pairs offense knowledge with a structured method.

Why it works

Most breaches exploit design gaps, not just code bugs. Systematically walking each component and data flow against a threat taxonomy surfaces missing controls (authz, validation, isolation) that ad-hoc review misses, and produces a prioritized list of controls and tests.

Method

Model the system: draw the data-flow diagram — external entities, processes, data stores, and trust boundaries (where data crosses privilege levels). The boundaries are where threats concentrate.
Enumerate threats per element with STRIDE:
- Spoofing (authn), Tampering (integrity), Repudiation (logging), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authz).
Attack trees for high-value targets: root = attacker goal, branches = paths; map each to a real technique (link the relevant SploitAgent offensive skill).
Rate & prioritize: likelihood × impact (or DREAD); focus on trust-boundary crossings.
Define controls & tests: for each accepted threat, a mitigation and a test/detection (→ defense-hardening-baseline, defense-detection-sigma).

Anti-patterns

Modeling implementation detail instead of trust boundaries — boundaries are where risk lives.
A threat list with no owner, control, or test — it must produce actionable, tracked mitigations.
One-and-done — re-model when the design changes.

Verify

A DFD with trust boundaries, a STRIDE-derived threat list, and for each significant threat a mitigation + a validation test/detection.

References

Shostack "Threat Modeling"; Microsoft STRIDE; OWASP Threat Modeling Cheat Sheet.

---name: defense-threat-modelingdescription: Threat-model a system or feature (STRIDE + attack trees) to find design-level risk before code. Load on "threat model", a new design/architecture review, security design questions, or planning controls. Signals: architecture diagram, data-flow, "what could go wrong", pre-build security.---# Threat modeling (STRIDE + attack trees)## When it appliesBefore or during design — a new feature, service, or architecture — to find what can go wrong atthe design level, where fixes are cheapest. Pairs offense knowledge with a structured method.## Why it worksMost breaches exploit design gaps, not just code bugs. Systematically walking each component anddata flow against a threat taxonomy surfaces missing controls (authz, validation, isolation) thatad-hoc review misses, and produces a prioritized list of controls and tests.## Method1. **Model the system**: draw the data-flow diagram — external entities, processes, data stores, and trust boundaries (where data crosses privilege levels). The boundaries are where threats concentrate.2. **Enumerate threats per element with STRIDE**: - **S**poofing (authn), **T**ampering (integrity), **R**epudiation (logging), **I**nformation disclosure (confidentiality), **D**enial of service (availability), **E**levation of privilege (authz).3. **Attack trees** for high-value targets: root = attacker goal, branches = paths; map each to a real technique (link the relevant SploitAgent offensive skill).4. **Rate & prioritize**: likelihood × impact (or DREAD); focus on trust-boundary crossings.5. **Define controls & tests**: for each accepted threat, a mitigation and a test/detection (→ `defense-hardening-baseline`, `defense-detection-sigma`).## Anti-patterns- Modeling implementation detail instead of trust boundaries — boundaries are where risk lives.- A threat list with no owner, control, or test — it must produce actionable, tracked mitigations.- One-and-done — re-model when the design changes.## VerifyA DFD with trust boundaries, a STRIDE-derived threat list, and for each significant threat amitigation + a validation test/detection.## ReferencesShostack "Threat Modeling"; Microsoft STRIDE; OWASP Threat Modeling Cheat Sheet.

Frequently asked questions