Cette page n'est disponible qu'en anglais.

Threat Modeling

Pathrule1 règle • 1 mémoire • 2 skills

Threat modeling is a repeatable design activity that asks what is being built, what can go wrong, what will be done, and whether the response is sufficient. This bundle maps data flows and trust boundaries, ranks concrete attacker paths, records decisions, and converts mitigations into owned tests. Unlike Web Security, it chooses and validates controls for a specific system before implementation instead of supplying request-layer defenses.

Carte des chemins suggérée

Pathrule place chaque élément sur le chemin correspondant, pour que votre assistant ne le voie que là où il a sa place. C'est la portée appliquée à l'import ; vous pouvez l'ajuster dans votre espace de travail.

/ racine de l'espace de travail

run-threat-model

docs/

security/

Every material threat receives a recorded response

The model is a map of trust, not a diagram of components

review-threat-model

Règles

Every material threat receives a recorded response/docs/securityhautestricteThreats are mitigated, eliminated, transferred, or explicitly accepted with evidence and ownership.

1	Threats are mitigated, eliminated, transferred, or explicitly accepted with evidence and ownership. An unranked threat list creates the appearance of review while leaving the team unable to tell which risks block delivery. Enforce this boundary in /docs/security so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Describe the attacker capability, targeted asset, trust boundary crossed, preconditions, and plausible impact in system-specific terms.
4	- Choose a response and connect mitigation responses to a concrete requirement, implementation owner, and verification method.
5	- Require a named risk owner and review date for acceptance or transfer; developers cannot accept business risk by omission.
6	- Reopen the decision when data sensitivity, exposure, identity, dependency, or architecture assumptions change.
7
8	Verification: Sample every high-impact path and trace it from model to code or test evidence; fail review for orphan threats, orphan controls, and expired acceptances.

Mémoires

The model is a map of trust, not a diagram of components/docs/securityComponent boxes alone do not reveal where data changes authority, validation, ownership, or confidentiality.

1	Component boxes alone do not reveal where data changes authority, validation, ownership, or confidentiality. Show actors, assets, processes, stores, external systems, data flows, and trust boundaries, then annotate identity and protection on each crossing.
2
3	Split broad diagrams until reviewers can reason about one sensitive flow without guessing hidden hops. Include control-plane, support, recovery, CI, and third-party paths because attackers do not stay on the happy-path architecture. Record assumptions such as private-network reachability or upstream validation as testable dependencies, not facts. Keep the decision explicit at /docs/security; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /src/api for enforcement points and /infra for workload and network trust boundaries. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

run-threat-model/rootRun a structured threat-model workshop and turn findings into owned, testable security work.

1	---
2	name: run-threat-model
3	description: Run a structured threat-model workshop and turn findings into owned, testable security work.
4	---
5
6	# Run Threat Model
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Define scope, assets, security objectives, attacker capabilities, and out-of-scope assumptions before discussing controls.
11	2. Draw data flows with identities, stores, external systems, protocols, and trust boundaries; walk one real scenario end to end.
12	3. Use STRIDE or another prompt set at each boundary, then write concrete abuse paths and rank them with product and operations input.
13	4. Choose responses, create mitigation requirements and verification tasks, assign risk owners, and schedule the next review trigger.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

review-threat-model/docs/securityReview an existing threat model for architecture drift, unresolved risks, and ineffective mitigations.

1	---
2	name: review-threat-model
3	description: Review an existing threat model for architecture drift, unresolved risks, and ineffective mitigations.
4	---
5
6	# Review Threat Model
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Compare the model with current deployment manifests, routes, identities, stores, third parties, and privileged support or recovery paths.
11	2. Re-run abuse-path prompts for changed boundaries and identify assumptions that no longer have evidence.
12	3. Trace each open and high-impact threat to a current response, owner, test, monitoring signal, and acceptance expiry where relevant.
13	4. Publish the delta, create follow-up work with measurable outcomes, and record the event that will trigger the next review.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Pourquoi ce pattern

Agents jump from a feature description to familiar controls without mapping assets, data flows, trust changes, attacker goals, or untested assumptions.

Public visé : Teams designing new services, sensitive flows, integrations, privilege changes, or major architecture revisions.

Ce que votre assistant évite :

Security reviews that list generic threats unrelated to the design
Mitigations with no owner, requirement, or verification method
Threat models that become stale after architecture and trust boundaries change

Voir en Markdown

Licence: Apache-2.0
Version: 1.0.0
Mis à jour: 2026-08-25