What this prompt does
This prompt runs a one-hour STRIDE threat-modeling session on a single feature and keeps it concrete: every threat must tie to a real trust boundary in that feature, not a generic checklist. The model draws an ASCII data-flow diagram with boundaries marked, lists assets and actors, walks all six STRIDE categories per boundary with an example threat each, then ranks mitigations by effort versus risk reduced and names the three threats to fix before launch.
The variables anchor the session. [feature] defines the scope — a file upload to S3 has very different boundaries than a payments flow. [data_sensitivity] raises or lowers the stakes on information-disclosure threats. [trust_assumptions] is the most revealing input: stating what the feature currently trusts (say, a client-supplied filename and content-type) tells the model exactly where to probe, because trusted-but-unverified input is where real threats hide.
When to use it
- You are about to build a feature and want a fast, structured threat model before code
- You want STRIDE applied to actual trust boundaries, not an abstract list
- A background job or webhook trusts input it probably should not
- You need mitigations ranked by effort versus risk so you can pick what fits the timeline
- You want residual risks written down with explicit acceptance criteria
- You want a clear shortlist of the threats to fix before launch
Example output
The model returns an ASCII data-flow diagram with trust boundaries drawn in, a list of assets and actors, then a STRIDE threat table per boundary with a concrete example for each of the six categories. After that comes a mitigation list ranked by effort against risk reduced, a residual-risk section with acceptance criteria, and a final pick of the three threats to address before you ship.
Pro tips
- Make
[trust_assumptions]honest and specific — naming what you currently trust (client filename, content-type) is what points the model at the real threats - Scope
[feature]to one feature so the session stays inside an hour and actually happens - Set
[data_sensitivity]accurately; PII or financial data should pull information-disclosure threats up the ranking - Read the data-flow diagram out loud and check each boundary — the threats you skip are usually the ones you cannot see
- Watch for the forgotten boundary, often a background job or webhook trusting upstream input
- Use the effort-versus-risk ranking to negotiate scope, and record any accepted residual risk so the decision is explicit later
- Name internal actors as well as external ones in the assets-and-actors step; insider and service-to-service paths produce threats an external-only view misses
- Revisit the model when the feature changes; a new data flow or integration can introduce a boundary the original session never covered
