# Threat Modeling > Threat Modeling - Skill: `handsomeboy990/threat-modeling` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/threat-modeling` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/threat-modeling/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/threat-modeling --- # Threat Modeling A threat model answers four questions in order: what are we protecting, who wants it, where do they cross into the system, and what do we do about each way they can. A model that stops at a diagram has answered none of them. The output is a ranked list of threats, each with a decision: mitigate, accept, or transfer. An unranked model is a list of fears. ## 1. What is being protected Name the assets before the attacks. An attack has no severity until it lands on something worth protecting. ``` data what data, whose, and what its exposure costs the user and the business function what the system does that an attacker would want to abuse or deny identity the accounts, roles and sessions that gate everything else trust the reputation and legal position that a breach damages ``` Rank the assets. The model spends its attention on the crown jewels, not equally on everything. ## 2. Who the adversary is Different adversaries reach different places and want different things. Name the ones that apply; ignore the ones that do not. ``` unauthenticated remote the internet, hitting every public surface authenticated user a real account, probing what it should not reach malicious insider legitimate access, abused compromised dependency code you shipped, working for someone else the user's own device malware, a shared computer, a stolen session a determined targeted actor only if the assets justify modelling them ``` A model that assumes a nation-state for a hobby project wastes effort. A model that assumes only accidental misuse for a payment system is negligent. Match the adversary to the assets. ## 3. Trust boundaries and data flow A trust boundary is a line where data or control passes from something you trust less to something you trust more. Every serious threat lives on a boundary. ``` client to server nothing from the client is trusted, ever service to service is the caller authenticated, is the call authorized application to database is the query parameterised, is the row scoped your system to a third party what leaves, what returns, what you now trust user to user content one user submits that another user renders ``` Draw the flow: where data enters, where it is stored, where it is rendered, where it leaves. Mark every boundary crossing. The crossings are the model. ## 4. What can go wrong: the six categories At each boundary crossing, walk the six. They are a checklist for generating threats, not a taxonomy to file them under. ``` spoofing can the attacker pretend to be someone they are not tampering can they change data in transit or at rest repudiation can they deny an action with no record to contradict them disclosure can they read what they should not denial can they make it unavailable to legitimate users elevation can they gain a capability they were not granted ``` For each crossing, ask each question. A yes is a candidate threat. Write it as a sentence: an attacker who is X can do Y because Z. ## 5. Ranking and deciding Every candidate threat gets a severity from `security-core` and a decision. ``` mitigate add a control that closes or narrows the threat; name the control accept the cost of mitigation exceeds the risk; record who accepted it transfer insurance, a third party who owns the risk, a contractual boundary ``` An accepted threat is a decision, not an omission. It is recorded with the reasoning and the accepting role, the way `decision-records` records any other trade. A threat nobody decided about is an unmodelled threat. ## 6. Keeping it alive A threat model written once and never revisited describes a system that no longer exists. Tie it to change. ``` revisit when a new trust boundary appears: a new integration, a new role, a new data type, a new entry point revisit when an asset's value changes: the feature that now handles payments revisit at a security review before a significant release retire a mitigation whose threat is gone, so the model stays readable ``` ## 7. Prohibitions - Never model attacks before naming assets; an attack on nothing is noise. - Never assume an adversary the assets do not justify, in either direction. - Never produce a model without a decision on every threat. - Never record a diagram alone and call it a threat model. - Never let an accepted risk be silent; name it and the role that accepted it. - Never model only the happy boundaries; the third party integration and the user-to-user content path are where the serious threats hide. ## 8. Protocol 1. List and rank the assets worth protecting. 2. Name the adversaries the assets justify. 3. Draw the data flow and mark every trust boundary crossing. 4. At each crossing, walk the six categories and write each candidate threat as a sentence. 5. Rank each threat with the `security-core` scale. 6. Decide each: mitigate with a named control, accept with a recorded reason, or transfer. 7. Hand the mitigations to the skills that implement them. 8. Record the model where the design lives, and tie it to the changes that should revisit it. ## 9. Auto-critique Score from 0 to 5: assets named and ranked, adversaries matched to assets, every trust boundary marked, six categories walked at each crossing, every threat written as a concrete sentence, every threat ranked, every threat decided, accepted risks named with their owner, the model tied to change. Threshold: no axis below 3, average at least 4. A model with an undecided threat, or with attacks but no assets, is rewritten. ## 10. Interfaces - Upstream: `security-core` for posture and severity, `architecture-design` and `architecture-proposal` for the system the model reasons about. - Downstream: `security-architecture` turns mitigations into design, `authentication-security`, `authorization-design`, `session-security`, `input-validation`, `security-headers` implement specific controls, `security-audit` verifies the controls exist in the code. - Lateral: `decision-records` for accepted risks, `data-privacy` when the assets are personal data.