[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X7YFXDXBWG7A01ZCANF5ZB":3,"skill-same:01M6X7YFXDXBWG7A01ZCANF5ZB":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":61,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6X7YFXDXBWG7A01ZCANF5ZB","threat-modeling",null,"Use when adding auth, webhooks, uploads, queues, secrets, tenant boundaries, or public endpoints — produces trust boundaries + abuse cases mapped to files, BEFORE implementation.","event4u-app\u002Fagent-config","event4u-app","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199339632?v=4","01M6X5TWBNCQCE1VDKT4E9KF7N","event4u.app","01M6X5TWF4HRM266RG2Q5VVH1X",19,"MIT","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"threat modeling","modeling","threat","when","security","queues","tenant","case","deep","trust","endpoints","uploads","files","webhooks","engineer","use","model","secrets","threat model","auth","2026-11-10 10:12:30",false,"---\nmodel_tier: high\nname: threat-modeling\ndescription: \"Use when adding auth, webhooks, uploads, queues, secrets, tenant boundaries, or public endpoints — produces trust boundaries + abuse cases mapped to files, BEFORE implementation.\"\npersonas:\n  - security-engineer\ndomain: quality\ncouncil_depth: deep\nworkspaces:\n  - engineering\npacks:\n  - engineering-base\ntriggers:\n  - phrase: \"threat model\"\n  - phrase: \"abuse case\"\n---\n\n# threat-modeling\n\n\n> **Grounded corpus (Tier-1 consultation):** before enumerating from\n> memory, ground surface → threats → controls in the adopted corpus —\n> `node \u003Cskills-root>\u002Fcorpus-grounding\u002Fscripts\u002Fground.mjs ground\n> --manifest \u003Cskills-root>\u002Fthreat-modeling\u002Fdata\u002Fmanifest.json\n> \"\u003Csurface description>\"` returns the surface class, ATT&CK\u002FCWE-cited\n> threats, required controls, and negative tests, with confidence +\n> evidence-gap. Propose grounded findings; the human confirms. Corpus:\n> [`data\u002Fthreats.csv`](data\u002Fthreats.csv) (MITRE ATT&CK v19.x \u002F OWASP\n> ASVS 5.0.0-derived, owner + cadence in the manifest).\n\n> You are a reviewer specialized in **pre-implementation threat analysis**.\n> Your only job is to produce a compact threat model for a planned change —\n> actors, assets, trust boundaries, abuse cases, and the minimum controls\n> the implementer must add. You do **not** audit existing code end-to-end,\n> you do **not** review diffs, you do **not** implement controls — sibling\n> skills handle those.\n\n## When to use\n\n* The change adds or modifies authentication, authorization, or permission checks\n* The change adds a public endpoint, webhook, file upload, queue worker,\n  scheduled task, or third-party integration\n* The change touches sensitive data, tenant boundaries, secrets, billing flows,\n  or admin-only capabilities\n* A `security-sensitive-stop-rule` trigger fired and the agent must produce a\n  risk review before patching\n\nDo NOT use when:\n\n* The change is a cosmetic refactor or documentation-only edit — skip entirely\n* The change is a diff ready for review — route to\n  [`judge-security-auditor`](..\u002Fjudge-security-auditor\u002FSKILL.md)\n* The concern is a full-codebase security posture review — route to\n  [`security-audit`](..\u002Fsecurity-audit\u002FSKILL.md)\n* The concern is end-to-end authorization enforcement — route to\n  [`authz-review`](..\u002Fauthz-review\u002FSKILL.md)\n* The concern is implementing the controls once identified — route to\n  [`security`](..\u002Fsecurity\u002FSKILL.md)\n\n## Procedure\n\n### 1. Anchor on the planned change\n\nRead the task description (ticket, feature plan, spec) and the entrypoints\nthe change will touch. You are modelling **the stated change**, not the\nwhole system. If the change is unclear from available context, stop and ask\nbefore continuing — never invent a threat model for an imagined feature.\n\n### 2. Inspect the execution path\n\nTrace the path once through existing code:\n\n- Where does untrusted input enter? (route, webhook, queue payload, CLI arg,\n  uploaded file, imported record)\n- Which actor types cross this path? (anonymous, authenticated user, admin,\n  service account, queue worker, cron)\n- What assets does the path touch? (PII, credentials, internal IDs, billing,\n  tenant-scoped records, files, secrets)\n- Where are the privilege boundaries? (auth gate, authorization layer, tenant\n  scope, admin gate)\n\n### 3. Model the risks\n\nFor every distinct abuse case, answer:\n\n| Field | What to fill in |\n|---|---|\n| Entry point | route \u002F job \u002F webhook + concrete file |\n| Actor | who can trigger it |\n| Precondition | what must be true (auth state, data state) |\n| Impact | concrete damage (data loss, privilege escalation, DoS, leakage) |\n| Current control | what exists today |\n| Missing control | what the change must add |\n\nPrioritize by **impact × plausibility**, not by novelty. Skip generic\nOWASP bullets unless you can anchor them in a concrete file or line.\n\n### 3b. STRIDE coverage check\n\nSweep the six STRIDE categories once against the change so no threat class\nis silently skipped. Each row names the question to ask and the control\nfamily the suite already teaches — anchor any hit in a concrete file per § 3.\n\n| STRIDE category | Ask about this change | Control family (suite reference) |\n|---|---|---|\n| **S**poofing | Can an actor claim another identity on this path? | Authentication at the boundary; token\u002Fsession verification — [`security`](..\u002Fsecurity\u002FSKILL.md) |\n| **T**ampering | Can the payload or stored state be modified in transit or at rest? | Request-boundary validation + signed webhooks + parameterized queries — [`laravel-validation`](..\u002Flaravel-validation\u002FSKILL.md) \u002F [`sql-writing`](..\u002Fsql-writing\u002FSKILL.md) |\n| **R**epudiation | Could the actor later deny having performed the action? | Audit logging of security events (actor + outcome, no credentials) — [`logging-monitoring`](..\u002Flogging-monitoring\u002FSKILL.md) |\n| **I**nformation disclosure | What leaks if this path errors, over-serializes, or logs? | Field whitelisting + scrubbed errors\u002Flogs — [`domain-safety-pii`](..\u002F..\u002Frules\u002Fdomain-safety-pii.md) |\n| **D**enial of service | Can this path be made expensive or unbounded by an attacker? | Rate limiting + bounded queries\u002Fuploads — [`security-audit`](..\u002Fsecurity-audit\u002FSKILL.md) § rate limiting, [`performance`](..\u002Fperformance\u002FSKILL.md) |\n| **E**levation of privilege | Can a lower-privilege actor reach a higher-privilege action or object? | Per-object authorization + tenant scope — [`authz-review`](..\u002Fauthz-review\u002FSKILL.md), [`broken-access-control`](..\u002F..\u002Frules\u002Fbroken-access-control.md) |\n\nA category with no plausible abuse case for this change is marked \"n\u002Fa —\nno boundary crossed\", not silently omitted.\n\n### 4. Convert risks to engineering actions\n\nFor each prioritized abuse case, propose the **smallest effective control**\nand name the exact file\u002Flayer it belongs in:\n\n- input validation → where\n- authorization check → where\n- rate limiting → where\n- output filtering → where\n- safer default → where\n- logging \u002F alerting → where\n\nState whether a new **negative test** is required and what condition it\nmust assert (e.g. *\"POST \u002Fimports with tenant-B id from tenant-A session\nreturns 403\"*).\n\n## Validation\n\nBefore finalizing the threat model, confirm:\n\n1. Every entry point has at least one identified control owner\n2. Every ? abuse case has either an existing control or a required new one\n3. Every ? abuse case has at least one proposed negative test\n4. You have NOT produced generic advice — every risk cites a file, route, or job\n5. You have NOT proposed offensive testing steps, exploit chains, or bypass ideas\n6. If the change is out of scope for threat modelling (no trust boundary\n   crossed), you have said so explicitly and stopped\n7. On a deployed product, every new entry point names the lever that switches it\n   off and what happens when that lever's store is down\n   ([`control-section`](..\u002Fsecurity-audit\u002Freferences\u002Fcontrol-section.md))\n\n## Output format\n\n```\nSkill:   threat-modeling\nTarget:  \u003Cfeature \u002F ticket \u002F change summary>\n\nActors:   \u003Clist, one per line>\nAssets:   \u003Clist, one per line>\nEntry points:   \u003Croute \u002F job \u002F webhook — file:line>\nTrust boundaries:   \u003Cwhere untrusted → trusted crossings happen>\n\nAbuse cases (prioritized):\n  ?  \u003Cname> — entry point · actor · precondition\n      Impact: \u003Cconcrete damage>\n      Current control: \u003Cwhat exists>\n      Missing control: \u003Cwhat to add, where>\n      Required test: \u003Cnegative assertion>\n  ?  ...\n  ?  ...\n\nImplementation plan:\n  1. \u003Ccontrol>, \u003Cfile\u002Flayer>\n  2. ...\n\nMissing tests:\n  1. \u003Cassertion>, \u003Ctest file>\n```\n\nSeverity: ? exploitable by external actor with current or no privilege \u002F\n? exploitable only with elevated privilege or partial auth \u002F ? defense-in-depth\nimprovement, not a concrete exploit path.\n\nRequired fields (ordered):\n\n1. **Skill** and **Target** — one-line change summary\n2. **Actors**, **Assets**, **Entry points**, **Trust boundaries**\n3. **Abuse cases** — prioritized; every entry cites entry point + actor + impact + current + missing control + required test\n4. **Implementation plan** — ordered controls mapped to files\u002Flayers\n5. **Missing tests** — ordered negative assertions\n\nRuntime confirmation (e.g. *\"reproduce the abuse against staging\"*, *\"query\nthe DB to confirm scope leakage exists today\"*) is a follow-up for the\nimplementer — **this skill does not execute tools, reproduce exploits, or\nrun tests**.\n\n## Gotcha\n\n* **Generic OWASP bullets without a file anchor** — \"SQL injection risk\" is\n  noise unless you cite the query. Drop it or anchor it.\n* **Confusing authentication with authorization** — a logged-in user is not an\n  authorized user. Model authorization as a distinct boundary even when auth\n  is already enforced upstream.\n* **Treating queue workers and webhooks as trusted** — they carry attacker-\n  influenced payloads. Model them as untrusted entry points.\n* **Modelling the whole system when the change is narrow** — the model is\n  scoped to the planned change. Out-of-scope risks belong to `security-audit`.\n* **Producing offensive test steps** — you name abuse cases and required\n  controls, not exploit procedures.\n\n## Do NOT\n\n* NEVER produce exploit chains, payloads, or bypass techniques — if the task\n  asks for offensive work, stop and refuse. A negative test against the\n  project's own code in its own suite is not an offensive step\n* NEVER return a threat model out of politeness when no trust boundary is crossed — say so and stop\n* NEVER treat \"internal\" or \"behind the WAF\" as a substitute for a control\n* NEVER approve a plan without at least one negative test per ? abuse case\n* NEVER silently fall back to a generic checklist when the diff context is missing — ask instead\n\n## References\n\n- **STRIDE threat model** — Microsoft Security Development Lifecycle, Shostack\n  *Threat Modeling: Designing for Security* (2014). Framing basis for the\n  Actors \u002F Assets \u002F Entry Points \u002F Trust Boundaries \u002F Abuse Cases rubric.\n  [learn.microsoft.com\u002Fen-us\u002Fsecurity\u002Fengineering\u002Fthreat-modeling-tool-threats](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fsecurity\u002Fengineering\u002Fthreat-modeling-tool-threats)\n- **OWASP ASVS v5.0.0** — Authorization (V8), Encoding and Sanitization (V1)\n  + Validation and Business Logic (V2), Session Management (V7) — default\n  baseline for \"Missing control\" entries. Renumbered from 4.0.3's V4\u002FV5\u002FV3\n  per the standard's own 4.0→5.0 migration guide (`5.0\u002Fen\u002F0x05-For-Users-Of-4.0.md`\n  in the ASVS repo) — 5.0.0 splits the old V5 Validation\u002FSanitization\u002FEncoding\n  chapter into separate Encoding-and-Sanitization and Validation-and-Business-Logic\n  chapters, and drops direct CWE\u002FNIST cross-mappings from the requirements.\n  [owasp.org\u002Fwww-project-application-security-verification-standard\u002F](https:\u002F\u002Fowasp.org\u002Fwww-project-application-security-verification-standard\u002F)\n- **OWASP ASVS v5.0.0 V6 Authentication** and **NIST SP 800-63B** (Digital\n  Identity Guidelines, Authentication and Lifecycle Management — read the\n  CURRENT revision, the series is re-issued). The authority the account-flow\n  rows defer to for password storage, verifier behavior, rate limiting and\n  recovery. Named as chapters, never quoted as values: a number copied out of\n  a standard goes stale silently where a pointer does not.\n  [pages.nist.gov\u002F800-63-3\u002Fsp800-63b.html](https:\u002F\u002Fpages.nist.gov\u002F800-63-3\u002Fsp800-63b.html)\n- **OWASP ASVS v5.0.0 V5 File Handling** and the **OWASP File Upload Cheat\n  Sheet** — the authority the `file-upload` rows defer to for validation,\n  storage, the processor and the serving origin. 5.0.0 reuses the number V5 for\n  this new chapter; the 2026-09-27 re-derivation mapped the old V5 forward and\n  missed the new one, which is why the upload rows arrived later than the rest.\n  Named as chapters, never quoted as values.\n  [cheatsheetseries.owasp.org\u002Fcheatsheets\u002FFile_Upload_Cheat_Sheet.html](https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FFile_Upload_Cheat_Sheet.html)\n- **OWASP Top 10 2021** — A01 Broken Access Control, A04 Insecure Design,\n  A05 Security Misconfiguration — cross-reference when naming abuse cases.\n  [owasp.org\u002FTop10\u002F](https:\u002F\u002Fowasp.org\u002FTop10\u002F)\n- [`authz-review`](..\u002Fauthz-review\u002FSKILL.md),\n  [`security`](..\u002Fsecurity\u002FSKILL.md),\n  [`security-audit`](..\u002Fsecurity-audit\u002FSKILL.md) — sibling review \u002F implementation skills.\n- Prompt-injection \u002F agent-config defense: [`untrusted-input-defense`](..\u002F..\u002Frules\u002Funtrusted-input-defense.md),\n  [`lethal-trifecta-guard`](..\u002F..\u002Frules\u002Flethal-trifecta-guard.md) — always-on authoring rules; consult when modelling injection abuse cases.\n- Attack surface documentation: [`docs\u002Fthreat-model.md`](..\u002F..\u002Fdocs\u002Fthreat-model.md) — package trust boundaries, assets, and known risks.\n","# threat-modeling\n\n\n> **Grounded corpus (Tier-1 consultation):** before enumerating from\n> memory, ground surface → threats → controls in the adopted corpus —\n> `node \u003Cskills-root>\u002Fcorpus-grounding\u002Fscripts\u002Fground.mjs ground\n> --manifest \u003Cskills-root>\u002Fthreat-modeling\u002Fdata\u002Fmanifest.json\n> \"\u003Csurface description>\"` returns the surface class, ATT&CK\u002FCWE-cited\n> threats, required controls, and negative tests, with confidence +\n> evidence-gap. Propose grounded findings; the human confirms. Corpus:\n> [`data\u002Fthreats.csv`](data\u002Fthreats.csv) (MITRE ATT&CK v19.x \u002F OWASP\n> ASVS 5.0.0-derived, owner + cadence in the manifest).\n\n> You are a reviewer specialized in **pre-implementation threat analysis**.\n> Your only job is to produce a compact threat model for a planned change —\n> actors, assets, trust boundaries, abuse cases, and the minimum controls\n> the implementer must add. You do **not** audit existing code end-to-end,\n> you do **not** review diffs, you do **not** implement controls — sibling\n> skills handle those.\n\n## When to use\n\n* The change adds or modifies authentication, authorization, or permission checks\n* The change adds a public endpoint, webhook, file upload, queue worker,\n  scheduled task, or third-party integration\n* The change touches sensitive data, tenant boundaries, secrets, billing flows,\n  or admin-only capabilities\n* A `security-sensitive-stop-rule` trigger fired and the agent must produce a\n  risk review before patching\n\nDo NOT use when:\n\n* The change is a cosmetic refactor or documentation-only edit — skip entirely\n* The change is a diff ready for review — route to\n  [`judge-security-auditor`](..\u002Fjudge-security-auditor\u002FSKILL.md)\n* The concern is a full-codebase security posture review — route to\n  [`security-audit`](..\u002Fsecurity-audit\u002FSKILL.md)\n* The concern is end-to-end authorization enforcement — route to\n  [`authz-review`](..\u002Fauthz-review\u002FSKILL.md)\n* The concern is implementing the controls once identified — route to\n  [`security`](..\u002Fsecurity\u002FSKILL.md)\n\n## Procedure\n\n### 1. Anchor on the planned change\n\nRead the task description (ticket, feature plan, spec) and the entrypoints\nthe change will touch. You are modelling **the stated change**, not the\nwhole system. If the change is unclear from available context, stop and ask\nbefore continuing — never invent a threat model for an imagined feature.\n\n### 2. Inspect the execution path\n\nTrace the path once through existing code:\n\n- Where does untrusted input enter? (route, webhook, queue payload, CLI arg,\n  uploaded file, imported record)\n- Which actor types cross this path? (anonymous, authenticated user, admin,\n  service account, queue worker, cron)\n- What assets does the path touch? (PII, credentials, internal IDs, billing,\n  tenant-scoped records, files, secrets)\n- Where are the privilege boundaries? (auth gate, authorization layer, tenant\n  scope, admin gate)\n\n### 3. Model the risks\n\nFor every distinct abuse case, answer:\n\n| Field | What to fill in |\n|---|---|\n| Entry point | route \u002F job \u002F webhook + concrete file |\n| Actor | who can trigger it |\n| Precondition | what must be true (auth state, data state) |\n| Impact | concrete damage (data loss, privilege escalation, DoS, leakage) |\n| Current control | what exists today |\n| Missing control | what the change must add |\n\nPrioritize by **impact × plausibility**, not by novelty. Skip generic\nOWASP bullets unless you can anchor them in a concrete file or line.\n\n### 3b. STRIDE coverage check\n\nSweep the six STRIDE categories once against the change so no threat class\nis silently skipped. Each row names the question to ask and the control\nfamily the suite already teaches — anchor any hit in a concrete file per § 3.\n\n| STRIDE category | Ask about this change | Control family (suite reference) |\n|---|---|---|\n| **S**poofing | Can an actor claim another identity on this path? | Authentication at the boundary; token\u002Fsession verification — [`security`](..\u002Fsecurity\u002FSKILL.md) |\n| **T**ampering | Can the payload or stored state be modified in transit or at rest? | Request-boundary validation + signed webhooks + parameterized queries — [`laravel-validation`](..\u002Flaravel-validation\u002FSKILL.md) \u002F [`sql-writing`](..\u002Fsql-writing\u002FSKILL.md) |\n| **R**epudiation | Could the actor later deny having performed the action? | Audit logging of security events (actor + outcome, no credentials) — [`logging-monitoring`](..\u002Flogging-monitoring\u002FSKILL.md) |\n| **I**nformation disclosure | What leaks if this path errors, over-serializes, or logs? | Field whitelisting + scrubbed errors\u002Flogs — [`domain-safety-pii`](..\u002F..\u002Frules\u002Fdomain-safety-pii.md) |\n| **D**enial of service | Can this path be made expensive or unbounded by an attacker? | Rate limiting + bounded queries\u002Fuploads — [`security-audit`](..\u002Fsecurity-audit\u002FSKILL.md) § rate limiting, [`performance`](..\u002Fperformance\u002FSKILL.md) |\n| **E**levation of privilege | Can a lower-privilege actor reach a higher-privilege action or object? | Per-object authorization + tenant scope — [`authz-review`](..\u002Fauthz-review\u002FSKILL.md), [`broken-access-control`](..\u002F..\u002Frules\u002Fbroken-access-control.md) |\n\nA category with no plausible abuse case for this change is marked \"n\u002Fa —\nno boundary crossed\", not silently omitted.\n\n### 4. Convert risks to engineering actions\n\nFor each prioritized abuse case, propose the **smallest effective control**\nand name the exact file\u002Flayer it belongs in:\n\n- input validation → where\n- authorization check → where\n- rate limiting → where\n- output filtering → where\n- safer default → where\n- logging \u002F alerting → where\n\nState whether a new **negative test** is required and what condition it\nmust assert (e.g. *\"POST \u002Fimports with tenant-B id from tenant-A session\nreturns 403\"*).\n\n## Validation\n\nBefore finalizing the threat model, confirm:\n\n1. Every entry point has at least one identified control owner\n2. Every ? abuse case has either an existing control or a required new one\n3. Every ? abuse case has at least one proposed negative test\n4. You have NOT produced generic advice — every risk cites a file, route, or job\n5. You have NOT proposed offensive testing steps, exploit chains, or bypass ideas\n6. If the change is out of scope for threat modelling (no trust boundary\n   crossed), you have said so explicitly and stopped\n7. On a deployed product, every new entry point names the lever that switches it\n   off and what happens when that lever's store is down\n   ([`control-section`](..\u002Fsecurity-audit\u002Freferences\u002Fcontrol-section.md))\n\n## Output format\n\n```\nSkill:   threat-modeling\nTarget:  \u003Cfeature \u002F ticket \u002F change summary>\n\nActors:   \u003Clist, one per line>\nAssets:   \u003Clist, one per line>\nEntry points:   \u003Croute \u002F job \u002F webhook — file:line>\nTrust boundaries:   \u003Cwhere untrusted → trusted crossings happen>\n\nAbuse cases (prioritized):\n  ?  \u003Cname> — entry point · actor · precondition\n      Impact: \u003Cconcrete damage>\n      Current control: \u003Cwhat exists>\n      Missing control: \u003Cwhat to add, where>\n      Required test: \u003Cnegative assertion>\n  ?  ...\n  ?  ...\n\nImplementation plan:\n  1. \u003Ccontrol>, \u003Cfile\u002Flayer>\n  2. ...\n\nMissing tests:\n  1. \u003Cassertion>, \u003Ctest file>\n```\n\nSeverity: ? exploitable by external actor with current or no privilege \u002F\n? exploitable only with elevated privilege or partial auth \u002F ? defense-in-depth\nimprovement, not a concrete exploit path.\n\nRequired fields (ordered):\n\n1. **Skill** and **Target** — one-line change summary\n2. **Actors**, **Assets**, **Entry points**, **Trust boundaries**\n3. **Abuse cases** — prioritized; every entry cites entry point + actor + impact + current + missing control + required test\n4. **Implementation plan** — ordered controls mapped to files\u002Flayers\n5. **Missing tests** — ordered negative assertions\n\nRuntime confirmation (e.g. *\"reproduce the abuse against staging\"*, *\"query\nthe DB to confirm scope leakage exists today\"*) is a follow-up for the\nimplementer — **this skill does not execute tools, reproduce exploits, or\nrun tests**.\n\n## Gotcha\n\n* **Generic OWASP bullets without a file anchor** — \"SQL injection risk\" is\n  noise unless you cite the query. Drop it or anchor it.\n* **Confusing authentication with authorization** — a logged-in user is not an\n  authorized user. Model authorization as a distinct boundary even when auth\n  is already enforced upstream.\n* **Treating queue workers and webhooks as trusted** — they carry attacker-\n  influenced payloads. Model them as untrusted entry points.\n* **Modelling the whole system when the change is narrow** — the model is\n  scoped to the planned change. Out-of-scope risks belong to `security-audit`.\n* **Producing offensive test steps** — you name abuse cases and required\n  controls, not exploit procedures.\n\n## Do NOT\n\n* NEVER produce exploit chains, payloads, or bypass techniques — if the task\n  asks for offensive work, stop and refuse. A negative test against the\n  project's own code in its own suite is not an offensive step\n* NEVER return a threat model out of politeness when no trust boundary is crossed — say so and stop\n* NEVER treat \"internal\" or \"behind the WAF\" as a substitute for a control\n* NEVER approve a plan without at least one negative test per ? abuse case\n* NEVER silently fall back to a generic checklist when the diff context is missing — ask instead\n\n## References\n\n- **STRIDE threat model** — Microsoft Security Development Lifecycle, Shostack\n  *Threat Modeling: Designing for Security* (2014). Framing basis for the\n  Actors \u002F Assets \u002F Entry Points \u002F Trust Boundaries \u002F Abuse Cases rubric.\n  [learn.microsoft.com\u002Fen-us\u002Fsecurity\u002Fengineering\u002Fthreat-modeling-tool-threats](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fsecurity\u002Fengineering\u002Fthreat-modeling-tool-threats)\n- **OWASP ASVS v5.0.0** — Authorization (V8), Encoding and Sanitization (V1)\n  + Validation and Business Logic (V2), Session Management (V7) — default\n  baseline for \"Missing control\" entries. Renumbered from 4.0.3's V4\u002FV5\u002FV3\n  per the standard's own 4.0→5.0 migration guide (`5.0\u002Fen\u002F0x05-For-Users-Of-4.0.md`\n  in the ASVS repo) — 5.0.0 splits the old V5 Validation\u002FSanitization\u002FEncoding\n  chapter into separate Encoding-and-Sanitization and Validation-and-Business-Logic\n  chapters, and drops direct CWE\u002FNIST cross-mappings from the requirements.\n  [owasp.org\u002Fwww-project-application-security-verification-standard\u002F](https:\u002F\u002Fowasp.org\u002Fwww-project-application-security-verification-standard\u002F)\n- **OWASP ASVS v5.0.0 V6 Authentication** and **NIST SP 800-63B** (Digital\n  Identity Guidelines, Authentication and Lifecycle Management — read the\n  CURRENT revision, the series is re-issued). The authority the account-flow\n  rows defer to for password storage, verifier behavior, rate limiting and\n  recovery. Named as chapters, never quoted as values: a number copied out of\n  a standard goes stale silently where a pointer does not.\n  [pages.nist.gov\u002F800-63-3\u002Fsp800-63b.html](https:\u002F\u002Fpages.nist.gov\u002F800-63-3\u002Fsp800-63b.html)\n- **OWASP ASVS v5.0.0 V5 File Handling** and the **OWASP File Upload Cheat\n  Sheet** — the authority the `file-upload` rows defer to for validation,\n  storage, the processor and the serving origin. 5.0.0 reuses the number V5 for\n  this new chapter; the 2026-09-27 re-derivation mapped the old V5 forward and\n  missed the new one, which is why the upload rows arrived later than the rest.\n  Named as chapters, never quoted as values.\n  [cheatsheetseries.owasp.org\u002Fcheatsheets\u002FFile_Upload_Cheat_Sheet.html](https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FFile_Upload_Cheat_Sheet.html)\n- **OWASP Top 10 2021** — A01 Broken Access Control, A04 Insecure Design,\n  A05 Security Misconfiguration — cross-reference when naming abuse cases.\n  [owasp.org\u002FTop10\u002F](https:\u002F\u002Fowasp.org\u002FTop10\u002F)\n- [`authz-review`](..\u002Fauthz-review\u002FSKILL.md),\n  [`security`](..\u002Fsecurity\u002FSKILL.md),\n  [`security-audit`](..\u002Fsecurity-audit\u002FSKILL.md) — sibling review \u002F implementation skills.\n- Prompt-injection \u002F agent-config defense: [`untrusted-input-defense`](..\u002F..\u002Frules\u002Funtrusted-input-defense.md),\n  [`lethal-trifecta-guard`](..\u002F..\u002Frules\u002Flethal-trifecta-guard.md) — always-on authoring rules; consult when modelling injection abuse cases.\n- Attack surface documentation: [`docs\u002Fthreat-model.md`](..\u002F..\u002Fdocs\u002Fthreat-model.md) — package trust boundaries, assets, and known risks.\n",{"name":5,"packs":44,"domain":46,"personas":47,"triggers":49,"model_tier":53,"workspaces":54,"description":7,"council_depth":27},[45],"engineering-base","quality",[48],"security-engineer",[50,51],{"phrase":37},{"phrase":52},"abuse case","high",[55],"engineering","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Fthreat-modeling",1,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config","https:\u002F\u002Fevent4u.app","https:\u002F\u002Fgithub.com\u002Fevent4u-app","Your events in your hand","2026-11-14 02:29:41",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add event4u-app\u002Fagent-config --skill threat-modeling",{"tool":71,"command":72},"bunx","bunx skills add event4u-app\u002Fagent-config --skill threat-modeling",{"tool":74,"command":75},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill threat-modeling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",true,[79,85,91,95,99,103],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"data\u002Fmanifest.json","REFERENCE","参考文档",5841,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002Fdata\u002Fmanifest.json",{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"data\u002Freasoning.csv","ASSET","资产文件",4056,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002Fdata\u002Freasoning.csv",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"data\u002Fsurfaces.csv",3389,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002Fdata\u002Fsurfaces.csv",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"data\u002Fthreats.csv",40285,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002Fdata\u002Fthreats.csv",{"path":100,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":101,"sourceHtmlUrl":102},"evals\u002Fevals.json",910,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002Fevals\u002Fevals.json",{"path":104,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":105,"sourceHtmlUrl":106},"evals\u002Ftriggers.json",2995,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fthreat-modeling\u002Fevals\u002Ftriggers.json",[108,126,138,149,161,171],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":119,"publishedAt":39},"01M6X84PK96XBPENXH66JCTSD1","unknown-key-fixture","Declares a key the schema does not know.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Funknown-key\u002FSKILL.md",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[120,121,122,123,124,125],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":39},"01M6X84HW7NAHZ7GZMQ9RXK1XJ","portable-fixture","Declares only semantics the MCP-lite carrier transports whole.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fportable\u002FSKILL.md",[132],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[122,134,135,33,136,125,137],"portable","portable fixture","only","MCP",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":39},"01M6X84F29FE0RGGZ1ZTFGZTX2","non-portable-fixture","Declares a runtime semantic the carrier drops.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fnon-portable\u002FSKILL.md",[144],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[135,146,134,122,147,53,148,125],"non portable fixture","semantic","runtime",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":39},"01M6X848F706PT9MDCX75JKJ6B","candidate-zero-width","A candidate whose prose carries an invisible joiner.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fzero-width-injection\u002FSKILL.md",[155],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[157,158,159,160],"candidate zero width","candidate","ZeRO","prose",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":39},"01M6X841SSC2T31VDF41SA6DG1","candidate-disclosure-suppression","A candidate whose prose tells the agent to withhold from the user.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdisclosure-suppression\u002FSKILL.md",[167],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[169,158,160,170],"candidate disclosure suppression","user",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":39},"01M6X83TFS5AGPBPVTQNWP0BB3","candidate-dangerous-frontmatter","A candidate claiming an unscoped tool grant and a permission bypass.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdangerous-frontmatter\u002FSKILL.md",[177],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[179,158,180,181,182,183],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]