threat-modeling

Threat Modeling (Chinese Version)

When to Use

You need to design security testing or review preparation around assets, trust boundaries, attack surfaces, threat scenarios, mitigations, and assumptions.
You need to deliver a reviewable initial version when materials are incomplete, and clearly state assumptions, gaps, and Human decisions.
You need to distinguish static security evidence, planned validation, and execution that has already occurred.

Default output is Markdown, organized by security risk, evidence, and priority.
When the user requests table, CSV, JSON, or ticket format, preserve the same finding fields and evidence status.
Before output enters an automated process, first confirm the schema, enum values, and required fields.

First read prompts/threat-modeling.md, and perform the input audit, coverage checklist, and output contract.
Extract scope, environment, version, roles, data, dependencies, constraints, and available evidence.
Build reviewable scenarios around assets, trust boundaries, attack surfaces, threat scenarios, mitigations, and assumptions, distinguishing known facts, inferences, and candidate validations.
For each item, record impact, priority, responsible role, closure conditions, and validation method.
When information is insufficient, deliver a limited initial version, and do not write risk assumptions as vulnerability confirmation or security pass.

Every execution must read prompts/threat-modeling.md.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory exists and the task requires it.

Based on the given components, draw subjects, entry points, data stores/flows, and trust boundaries, and list assets, sensitive data, and allowed actions; components not given must not be added on your own.
Deliver sourced data flows and per-path threat cards, where each threat has actual components/preconditions/assets; do not fabricate paths through attack category names.
When forming domain candidates, you must read and follow prompts/threat-modeling.md domain operations and determination process, retaining legitimate comparisons, evidence gaps, and validation actions item by item.

Only analyze assets, trust boundaries, attack surfaces, threat scenarios, mitigations, and assumptions; do not log in to systems, do not call real APIs, and do not read credentials.
Do not fabricate vulnerabilities, successful attacks, completed fixes, scan coverage, or security pass conclusions.
When evidence is missing, mark as pending confirmation, blocked, or unassessed, and provide isolated validation methods.
Risk acceptance, exception authorization, and release decisions must be left to Human.

The known, missing, conflicting, stale, out_of_scope, and assumptions audit has been completed.
Threat scenarios, trigger conditions, expected focus points, and evidence status have been covered.
Facts, inferences, recommendations, information gaps, and Human decisions have been separated.
Static findings or dry-run have not been written as real attacks, absence of vulnerabilities, or release approval.

Treating a generalized security review or API contract check as a complete replacement for threat modeling.
Listing only attack names, without writing applicability, evidence, expected results, and closure conditions.
When information is insufficient, directly determine that it is safe, or read real credentials for completeness.

Start with high-impact, hard-to-detect, privilege-sensitive, or data-sensitive paths.
Use sanitized materials, least privilege, isolated environments, and rollback-capable verification recommendations.
Enable another engineer to review each security conclusion based on its source and boundaries.