STRIDE GPT: an LLM threat modeling front end with a CLI, a Streamlit app, and a diagram editor

The gap STRIDE GPT fills is the blank page, not the review

Threat modeling sessions stall for a mundane reason. Someone has to write down the system, enumerate the trust boundaries, and then walk the STRIDE categories against each one before the interesting conversation can start. That first draft is mechanical work, and it is the part people skip. STRIDE GPT targets exactly that step: you supply application details such as the application type, authentication methods, and whether the app is internet-facing or processes sensitive data, and the model produces a threat model and attack trees against the STRIDE methodology. The audience is a security engineer or a developer who knows what a threat model is and does not want to spend an afternoon producing the skeleton. It is also aimed at teams who want standardized output rather than a free-form document, which is why the project emits SARIF and maps findings to MITRE ATT&CK and ATLAS technique IDs. The tool does not decide what matters. It proposes candidates.

Two entry points, one prompt pipeline, and a diagram that becomes the system model

The project ships a Streamlit web interface and a terminal experience, described in the README as a full-featured CLI with an interactive REPL, tab completion, history and real-time progress. Both feed the same generation step. The mechanism that separates STRIDE GPT from a chat wrapper is the DFD handling. You can generate a data flow diagram from the application description, edit the Mermaid source live, and then feed the confirmed diagram back into the threat model and attack tree prompts as the authoritative system model. That ordering matters: the diagram is not decoration, it is the input the later prompts are conditioned on. The embedded draw.io editor takes the same idea further. Diagrams are parsed as XML to extract components, connections and trust boundaries, which the README contrasts with image analysis alone. A vision model looking at a PNG guesses at boxes and arrows. An XML parse reads them. The README states the existing image upload workflow is unchanged, so the two paths coexist. Provider routing runs through LiteLLM, which is how a single codebase reaches OpenAI, Anthropic, Google AI, Mistral, Groq, DeepSeek and LM Studio Server for local hosting. The README also lists architectural pattern detection for RAG pipelines, multi-agent systems, code execution environments and tool ecosystems, credited as inspired by the CSA MAESTRO framework.

Installing it and the environment variables that actually change behaviour

The README documents installation via pip and a Docker container image. The release notes for version 0.19 state that dependency management was consolidated onto uv, with uv.lock as the single source of truth, that the duplicated requirements.txt files were retired, and that pip install stride-gpt users see no change. The Docker UI image and the security-scan workflow install from uv.lock via uv export, so the scanned dependency set and the shipped one cannot drift apart. That is a real supply-chain improvement, not a cosmetic one. Configuration is environment-variable based. STRIDE_GPT_DRAWIO_URL is the one the README names explicitly: the editor loads from the hosted embed.diagrams.net by default, and you point it at your own draw.io for self-hosted or air-gapped deployments. Provider credentials follow the LiteLLM convention for whichever backend you select. Version 0.19 added a --version flag so you can confirm what you are running without opening the UI. The README points to docs/operationalization-guide.md for injecting organizational security controls and compliance requirements, which is the documented path for teams that need output shaped by internal standards rather than generic advice.

The output formats are where this tool earns its place in a pipeline

Markdown, JSON, SARIF and a self-contained HTML view are the four documented outputs. SARIF is the interesting one. The README states it imports into GitHub, GitLab, Azure DevOps and IDEs, and that MITRE ATT&CK mappings surface as a mitre_attack property in SARIF, as columns in markdown, and as linked pills in HTML. That means a generated threat model can land in the same code scanning surface your team already reads, next to static analysis findings, instead of in a wiki page nobody opens. The HTML view is described as self-contained and intended for sharing with stakeholders, which is a different audience from the SARIF consumer. The project also generates Gherkin test cases from identified threats and supports DREAD risk scoring. DREAD has been deprecated in much of the industry for years, so its presence is a compatibility choice rather than a recommendation, and the README does not argue for it. Treat the scoring as a rough sort order, not a measurement.

Where LLM threat modeling breaks down

The central limitation is structural. The model generates threats from the description you give it, and the README's own framing is that output depends on the provided information. Anything you omit is invisible to the tool. It cannot see your WAF rules, your existing compensating controls, your network segmentation, or the mitigation you already shipped last quarter, so it will happily propose threats you closed a year ago. The mitigation suggestions inherit the same blindness. A second limitation is that the model is a moving target. The README lists support for OpenAI GPT-5.4/5.5 series, Anthropic Claude 4.6/4.8 with Extended Thinking, Google Gemini 3 and Mistral Magistral, and routes them through LiteLLM. Model availability, naming and behaviour change on the provider's schedule, not this project's, so a prompt tuned against one model can produce noticeably different output on another. There is no evaluation harness described in the README, which means you have no documented way to tell whether a model swap degraded your results. Third, agentic codebase analysis is described as autonomous planning and exploration across subsystems. Autonomous exploration over a large repository costs tokens in a way that a single prompt does not, and the README gives no guidance on bounding that. Finally, the project states it stores no data, but that only describes the tool. The application description still travels to whichever provider you configured, and that provider's retention policy is outside this project's control.

How it compares to Microsoft Threat Modeling Tool

The obvious alternative is Microsoft Threat Modeling Tool, and the difference is in what each treats as the source of truth. Microsoft's tool is built around a structured diagram you draw in its own editor, with a fixed element vocabulary and a rule engine that generates threats from the diagram's structure. It is deterministic: the same diagram yields the same threats, and the rules are inspectable. STRIDE GPT inverts this. Its draw.io editor parses XML into components, connections and trust boundaries, but those extracted elements become context for a language model rather than input to a rule engine. The upside is flexibility: you can describe a RAG pipeline or a multi-agent system in prose and get threats that no fixed rule set would enumerate, and you can map them to ATLAS technique IDs for ML-specific attacks. The downside is reproducibility. Microsoft's tool gives you the same answer twice. STRIDE GPT gives you a plausible answer, and plausibility is not the same property. Teams that need an auditable, repeatable artifact for a compliance file should weigh that difference carefully. Teams that need a fast first pass on a system whose architecture does not fit a fixed element vocabulary will find the LLM route more productive.

Maintenance cost and the MIT licence in practice

STRIDE GPT is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum, and it is the reason the README can point at an operationalization guide that walks through forking and deploying internally. The practical cost of a fork is the prompt surface: the project ships prompts for threat models, attack trees, DFDs, Gherkin test cases and DREAD scoring, and any of those can shift when you customize them. The 0.19 changelog shows active movement on infrastructure rather than features, with the uv.lock consolidation and the --version flag, which suggests the maintainer is paying down packaging debt. Version 0.19.0 is dated 2026-07-19 and the last push to the default branch is 2026-09-07, so the repository is being touched between releases. The README solicits stars and coffee donations, which tells you the funding model is individual rather than corporate. Plan for the possibility that a provider changes a model name and your pinned configuration stops resolving. Pin your model identifiers and re-run a known application description after any dependency bump to see whether the output moved.

Editorial conclusion

Adopt STRIDE GPT if you already have a provider key, want a first-pass STRIDE draft in minutes, and are willing to treat the output as a checklist to argue with rather than a finished model. Do not adopt it as a replacement for a human threat modeling session on a system with real regulatory exposure, and do not expect the tool to know your compensating controls. Before rolling it out, verify three things: which model your chosen provider actually serves, whether the draw.io editor is pointed at embed.diagrams.net or your own instance via STRIDE_GPT_DRAWIO_URL, and what your provider's data retention policy does with the application description you paste in, since the project states it stores nothing itself.

Official sources

1. License: MIT
2. mrwadams/stride-gpt on GitHub
3. Project website
4. README
5. Releases