STRIDE GPT is an AI-powered threat modelling tool that leverages Large Language Models (LLMs) to generate threat models and attack trees for a given application based on the STRIDE methodology. Users provide application details, such as the application type, authentication methods, and whether the application is internet-facing or processes sensitive data. The model then generates its output based on the provided information.

Table of Contents

• Support the Project
• Features
• Enterprise Deployment
• Talk at Open Security Summit
• Changelog
• Installation
• Repository layout
• Usage
  • Interactive REPL cheat sheet
• Sample output
• Security Best Practices
• Contributing
• License

Support the Project

If you find STRIDE GPT useful, please consider supporting the project:

• ⭐ Star the repository on GitHub to help more people discover the tool
• ☕ Buy me a coffee to support continued development and maintenance

Features

• Agentic codebase analysis: Point the CLI at a codebase and get an autonomous, deep STRIDE threat model — the agent plans, explores, and synthesizes findings across subsystems
• CLI and interactive REPL: Full-featured terminal experience with tab completion, history, and real-time progress — no browser required
• Simple and user-friendly Streamlit web interface
• Generates threat models based on the STRIDE methodology
• Agentic AI support: Specialized threat modeling for agentic AI systems with OWASP Top 10 for Agentic Applications (ASI) integration
• Generative AI support: Threat modeling for GenAI applications with OWASP LLM Top 10 integration
• MITRE ATT&CK & ATLAS mapping: Threats are annotated with standardized adversary technique IDs (MITRE ATT&CK Enterprise for traditional infrastructure attacks, ATLAS for ML/LLM-specific attacks) — surfaced as columns in markdown, linked pills in HTML, and mitre_attack properties in SARIF
• Architectural pattern detection: Automatically detects RAG pipelines, multi-agent systems, code execution environments, tool ecosystems, and more from application descriptions (inspired by CSA MAESTRO)
• Embedded draw.io diagram editor: Create and edit architecture diagrams directly in STRIDE-GPT using the integrated diagrams.net editor — no external tool needed. Diagrams are parsed as XML to extract components, connections, and trust boundaries, providing significantly richer context for threat model generation than image analysis alone. The existing image upload workflow is unchanged. By default the editor loads from the hosted embed.diagrams.net; for self-hosted or air-gapped deployments, point it at your own draw.io via the STRIDE_GPT_DRAWIO_URL environment variable
• Multi-modal: Use architecture diagrams, flowcharts, etc. as inputs for threat modelling across all supported vision-capable models
• Data Flow Diagrams: Generate DFDs from your application description (or parse an uploaded DFD image), edit the Mermaid source live, and feed the confirmed diagram back into the Threat Model and Attack Tree prompts as the authoritative system model. CLI /analyze also emits a system-level DFD alongside its findings
• Generates attack trees to enumerate possible attack paths
• Suggests possible mitigations for identified threats
• Supports DREAD risk scoring for identified threats
• Generates Gherkin test cases based on identified threats
• GitHub repository analysis for comprehensive threat modelling (including GitHub Enterprise support)
• Multiple output formats: Markdown, JSON, SARIF (imports into GitHub, GitLab, Azure DevOps, IDEs), and a self-contained HTML view for sharing with stakeholders
• Advanced reasoning model support (OpenAI GPT-5.4/5.5 series, Anthropic Claude 4.6/4.8 with Extended Thinking, Google Gemini 3, Mistral Magistral series)
• Comprehensive LLM provider support via LiteLLM: OpenAI, Anthropic, Google AI, Mistral, Groq, DeepSeek, plus local hosting via LM Studio Server
• No data storage; application details are not saved
• Available as a Docker container image for easy deployment
• Environment variable support for secure configuration

Enterprise Deployment

Want to customize STRIDE-GPT for your organization? Check out our comprehensive Operationalization Guide to learn how to:

• 🎯 Inject organizational security controls and standards
• 📋 Customize threat models with your compliance requirements
• 🔧 Fork and deploy STRIDE-GPT internally
• 📊 Get context-aware, actionable threat models specific to your environment

The guide includes step-by-step instructions, code examples, and deployment patterns for organizations looking to scale AI-powered threat modeling across their teams.

Talk at Open Security Summit

In January 2024 I gave a talk about STRIDE GPT at the Open Security Summit. During the talk, I discussed the project's inception, its core functionalities, recent updates, and some future plans. You can watch the full presentation below:

This video is an excellent resource for anyone interested in understanding how STRIDE GPT works and how it can be used to improve threat modelling.

Changelog

Version 0.20 (latest)

• Resume an interrupted analysis (closes #197): analyze now checkpoints the approved plan and each subsystem finding as it completes, next to the -o report. --resume <checkpoint> reuses the subsystems that finished and reruns the rest, then runs synthesis and the data flow diagram as usual. Resume refuses when the target's git SHA or the config hash no longer match, naming which changed, so stale findings can't be stitched into a run of different code. A dirty working tree or a missing git SHA refuses unless --force; a changed SHA refuses even with it. The run manifest records which subsystems were reused and which were rerun.
• Threats cite verified evidence (closes #195): Each threat is now reported through a tool call carrying the code it came from, and every quoted snippet is checked against the file on disk before the threat is recorded. SARIF locations point at the file and line range the evidence was found at, rather than giving every threat in a subsystem the same three files, and files_analyzed reflects what the agent actually read rather than what it claimed to.
• Every subsystem records why it stopped (closes #196): A SubsystemFinding now carries an outcome — completed, budget_exhausted, parse_failed, error, or skipped — so a subsystem that crashed is no longer indistinguishable from one that was analysed and found nothing. Findings always match the plan: subsystems the run budget never reached are recorded as skipped rather than dropped. run_summary.status is derived from those outcomes, so a run where subsystems crashed is reported as partial instead of completed, and a clean subsystem with zero threats no longer makes the console print "Analysis partially complete". Failures are classified from the exception type (context_overflow, rate_limited, auth, provider_error) rather than by searching the error text, and the markdown and HTML reports show failed and skipped subsystems explicitly. Findings files written before this change still load, treated as completed.
• Token usage recorded per phase and per subsystem (#198): Prompt and completion tokens are read off each provider response and aggregated per phase (planning, exploration, compression, synthesis, DFD), per subsystem, and as a run total. The console summary gains a token line and <stem>.run.json gains token_usage_total, token_usage_by_phase and token_usage_by_subsystem. "Unknown" stays distinct from zero: some providers never report usage, so an all-zero reading records as unavailable rather than free. These are token counts, not costs: cache hit and miss tokens are not yet split out (#225), so a provider that serves most of a conversation from its prefix cache bills well below what the totals imply.
• The planner represents every directory it found (#175, closes #180): The key-file sample sent to the planner was a flat alphabetical slice, so one early-sorting directory could consume the whole budget and a later-sorting service reached the planner with no file-level signal at all. On OWASP crAPI that dropped two of six services from the plan entirely while the run still reported complete. The sample now round-robins across the whole directory tree, at any depth, and its header says it is a sample rather than reporting the total over a silently truncated list. search_files' truncation marker is no longer mixed into that list as if it were a file.
• read_file pages by line range (closes #194): read_file takes optional 1-based start_line and end_line arguments and returns numbered lines under a header giving the total line count, the exact range shown, and whether the byte cap cut it short. Previously it returned the first 50 KB and nothing more, so the agent could not read past that point and had no line numbers to cite. When output is truncated, a hint gives the line to request next.
• OpenRouter as a model provider (#221): Routes through LiteLLM's openrouter/ prefix, authenticated with OPENROUTER_API_KEY, with a shortlist of six tool-capable models and any other slug available through the wizard's Custom option. CLI only for now. Also fixed: --worker-model naming a provider your saved config doesn't know about resolved the model from the flag but the API key from the config file, so the request could carry the wrong provider's secret (#222).
• Model registry refreshed (#223): Current lineups for OpenAI, Anthropic, DeepSeek, Mistral, Groq, Google and OpenRouter, with retired models dropped. supports_thinking now tracks which models actually accept the legacy extended-thinking parameter, since Claude 4.7 and later reject it, and the Streamlit thinking checkbox follows that flag rather than the provider.
• Security: the agent's file tools can no longer reach version-control metadata (#191, #190): read_file, grep_content and list_directory refuse any path resolving inside .git, .hg or .svn, directly or through a committed symlink. actions/checkout writes the job token into .git/config, and some clones embed a token in the remote URL, so analysing a CI checkout put credentials within reach of a model-driven read. grep_content also checked only its starting path before reading everything os.walk returned; it now applies the same resolved-path check to each file, matching read_file. list_directory no longer follows symlinks out of the sandbox when reporting type and size.
• Malformed model output can no longer destroy a run's intermediates (closes #208): A null byte in a planner-supplied file path crashed path redaction, which runs while persisting plan.json, findings.json and run.json — after every LLM call had been paid for. Redaction is now total, and an unresolvable path is still redacted rather than written out verbatim, so a home directory can't leak into a manifest that goes to git or a ticket. Genuine disk and serialisation failures still fail the run loudly.
• Supply chain and scan hygiene (#176, #177): Cleared 22 Dependabot alerts by updating gitpython, aiohttp and cryptography through the lockfile, cut Trivy base-image noise that was burying actionable findings, and cleared the remaining 18 CodeQL code-quality findings. Scheduled secret scanning no longer fails on model identifiers, and the CI security summary reports icons that follow the job result.

Version 0.19

• --version flag (#161): stride-gpt --version now prints the installed version and exits, and the interactive TUI banner shows the running version so you can confirm what you're on at a glance.
• Dependency management consolidated onto uv (closes #155): uv.lock is now the single source of truth for every dependency. The duplicated requirements.txt files are retired; the Docker UI image and the security-scan workflow install from uv.lock via uv export, so what ships and what gets scanned can no longer drift from what's locked. No change for pip install stride-gpt users.
• Documentation: Added a sample threat-model markdown output (#151) and an interactive REPL cheat sheet (#163) to the README.

Version 0.18

• Embedded draw.io diagram editor (#132, #138): The Streamlit Threat Model tab now embeds the diagrams.net editor so you can sketch an architecture diagram in-app; on save the diagram XML is parsed (components, connections, trust boundaries) and folded into the threat-model prompt. GitHub analysis, image upload, the diagram editor, and an AI-assisted guided builder are unified into one tabbed "describe your application" section over a single description canvas, so the optional inputs no longer crowd out the primary description field. The guided builder now calls the selected model to draft a description and suggest missing security-relevant details, replacing the previous static template and coverage checks. For self-hosted or air-gapped deployments the editor host is configurable via STRIDE_GPT_DRAWIO_URL (defaults to embed.diagrams.net), the iframe postMessage origin is scoped to it, and untrusted diagram XML is parsed with defusedxml.
• DeepSeek provider support (closes #133): DeepSeek is now a first-class model provider in both the CLI setup wizard and the Streamlit UI, offering deepseek-v4-pro and deepseek-v4-flash. Calls route through LiteLLM's native deepseek/ integration (hosted endpoint, no custom base URL needed); set your key via DEEPSEEK_API_KEY.
• Data Flow Diagram support (closes #56): New "Data Flow Diagram" tab in the Streamlit UI generates DFDs from the application description, parses uploaded DFD images via vision-capable models, and renders an editable Mermaid source pane with a live preview. Ticking "Use this DFD for the threat model" stores the confirmed diagram in session state and splices it into subsequent Threat Model and Attack Tree prompts as the authoritative system model — closing the description → DFD → review → refined threat model loop the issue asks for. The CLI's /analyze agent also produces a system-level DFD after synthesis, rendered as a Mermaid block in the markdown report, carried in the JSON data_flow_diagram field, and shown in the HTML view via a CDN-loaded Mermaid runtime. DFD generation is wrapped so a bad diagram never fails a good report.
• Graceful GitHub repo analysis errors (closes #92): The Streamlit UI now catches GitHub API failures during repository analysis instead of surfacing a raw stack trace, with actionable messages for 404 (including fine-grained PAT scoping, which 404s even public repos), 401, 403/rate-limit, and network errors. Repo URLs are normalised (trailing / and .git suffix stripped) before parsing so .../repo/ and .../repo.git no longer 404 spuriously.
• Structured intermediates alongside reports (closes #122): When -o <path> is passed to /analyze or /quick, JSON siblings are written next to the report — <stem>.plan.json (the AnalysisPlan), <stem>.findings.json (subsystem findings, cross-cutting threats, and the data flow diagram), and <stem>.run.json (a RunManifest recording models, config hash, version, timing, which reference cards actually loaded, and a run_summary marking whether the run completed or a call cap truncated it). Manifests exclude API keys and endpoints and redact filesystem paths, so they're safe to commit or attach to a ticket. The -f format flag governs only the report artefact; siblings are always JSON.
• Comma-separated MITRE ATT&CK recovery (closes #134): When a worker model returns MITRE_ATTACK as a comma-separated string (e.g. "T1190, T1059, AML.T0053") instead of the canonical list shape, the technique IDs are now recovered rather than dropped. Previously the markdown/HTML reports showed the "MITRE ATT&CK" column but left every cell blank, and the SARIF export lost the IDs entirely. All renderers (markdown, HTML pills, SARIF) and the column-visibility check now route through a single normaliser, and free-form prose that isn't a technique ID is filtered out so the column never fills with false positives.
• 0.18.1 patch (closes #159): Fixed LM Studio calls failing with The api_key client option must be set when no cloud provider key was present in the environment. LM Studio routes through LiteLLM's openai/ prefix, and the OpenAI SDK refuses to build a client without a key even when api_base points at localhost, so the CLI now passes a placeholder for providers that don't authenticate. Relatedly, the worker tier's last-resort environment scan no longer applies to those providers: a configured ANTHROPIC_API_KEY or OPENAI_API_KEY was previously sent to whatever host api_base named, which both masked this bug and put a real key on the wire. If you use LM Studio and have such a key set, it is no longer transmitted to your endpoint.

Version 0.17

• MITRE ATT&CK and ATLAS integration (closes #36): Threats emitted by /analyze and /quick can now carry standardized adversary technique IDs from MITRE ATT&CK Enterprise (v17.1) and MITRE ATLAS (2026.05). Two new progressive-disclosure reference cards (mitre_enterprise, mitre_atlas) instruct the agent to use only the catalogued IDs and names, eliminating ID hallucination. Cards are regenerated from upstream STIX/YAML via scripts/refresh_mitre_cards.py rather than written from model recall. Techniques render as a MITRE ATT&CK column in markdown tables, clickable sky-tinted pills in HTML, and properties.mitre_attack arrays in SARIF.
• HTML report companion: /analyze and /quick now emit a self-contained browser-viewable HTML report alongside the markdown / JSON / SARIF outputs, suitable for sharing with stakeholders.
• Anthropic Claude Opus 4.8: Added support for claude-opus-4-8, Anthropic's newest frontier-tier model, alongside the existing Opus 4.7. Either can be selected as the architect or worker model.
• UI image consolidation: The dual-namespace Docker setup (mrwadams/stridegpt-ui) is gone; the Streamlit web UI now lives at mrwadams/stridegpt only. CLI users should pip install stride-gpt rather than pulling a container.
• Dependency hygiene: Dropped the unused mistralai package (Mistral access already flows through LiteLLM). Refreshed the python:3.12-slim base for the UI image and dropped curl, clearing 21 medium/high CVE alerts across PRs #113–#115.
• Code quality cleanup: Cleared CodeQL note alerts (unused imports, bare except, dead code) (#116).

Version 0.16

• Standalone CLI: First release of STRIDE-GPT as a pip install stride-gpt CLI, separated from the legacy Streamlit web UI. Two main commands: /analyze (autonomous agentic codebase analysis with a planner, per-subsystem tool-using agent loops, and a cross-cutting synthesis pass) and /quick (single-shot threat model from a written application description).
• Progressive-disclosure reference cards: genai (OWASP LLM Top 10), agentic (OWASP ASI Top 10), and insider_threat cards self-describe via YAML frontmatter; the agent discovers them via list_references and pulls bodies via load_reference.
• Two-tier model routing: Architect + worker model split for cost-efficient analysis, with frontier-class models reserved for planning and synthesis.
• Interactive REPL: Full-featured terminal experience with tab completion, history, real-time progress, and a status line.
• Multi-format output: Markdown, JSON, and SARIF (imports into GitHub, GitLab, Azure DevOps, IDEs).
• 0.16.1 patch: Raised the LiteLLM logger to ERROR in stride_gpt/__init__.py so the Bedrock/SageMaker pre-load warnings don't appear on fresh installs that lack botocore.

Installation

Option 1: pip (CLI only)

pip install stride-gpt

This installs the stride-gpt command. The CLI and the Streamlit web UI are now distinct products — pip install stride-gpt gives you the lean CLI with no Streamlit footprint. To run the web UI from source, see Option 2 below.

Option 2: From source

1. Clone the repo:

   git clone https://github.com/mrwadams/stride-gpt.git
   cd stride-gpt
   

2. Install with uv (recommended — uv.lock is the single source of truth for dependencies):

   # CLI plus the Streamlit web UI deps
   uv sync
   

   Or install just the CLI with pip:

   pip install -e .
   

3. (Optional) Set up environment variables:

   cp .env.example .env
   

   Edit .env to add your API keys — or configure them later by running stride-gpt and using the /config command in the interactive REPL, or via the Streamlit UI.

Option 3: Docker (web UI)

The Streamlit web UI ships as a Docker image:

docker pull mrwadams/stridegpt:latest

For the CLI, use pip install stride-gpt — there's no separate CLI image. If you need a sandboxed CLI, roll your own from a minimal Python base image.

Repository layout

STRIDE-GPT is organised as a small monorepo: one shared Python library, one or more apps that consume it.

stride-gpt/
├── stride_gpt/    # shared library + Python CLI (core, agent loop, prompts, schemas, models)
├── apps/
│   └── web/       # Streamlit web UI
├── tests/         # pytest suite
└── pyproject.toml # single project file; web UI deps live in the `web` dependency-group

The apps/ directory is the slot for additional deployable frontends — for example, a future Node/TypeScript CLI would live alongside apps/web/. The Python CLI itself stays in stride_gpt/cli.py because it's tightly coupled to the shared library.

Usage

CLI

Agentic codebase analysis — the agent autonomously explores a codebase, plans its analysis, and produces a STRIDE threat model:

# Analyze the current directory
stride-gpt analyze .

# Specify a model and auto-approve the analysis plan
stride-gpt analyze ./my-app --worker-model anthropic/claude-sonnet-5 -y

# Export as JSON, SARIF, or browser-viewable HTML
stride-gpt analyze . -o report.json -f json    # also writes report.html alongside
stride-gpt analyze . -o report.sarif -f sarif
stride-gpt analyze . -o report.html -f html

Every analysis also auto-saves a JSON and an HTML companion to ~/.stride-gpt/reports/analyze/, so the browser-viewable view is always one click away even when you run without -o.

Note on cost: Agentic analysis is thorough — the agent makes many LLM calls and reads many files as it explores. Token usage and cost scale with codebase size and your chosen model, and a full run on a large repository against a frontier model can be expensive. Set spending limits in your provider dashboard before running, and consider faster/cheaper models for first passes.

Quick single-shot mode — generate a threat model from a text description (like the Streamlit UI, but in the terminal):

# Read description from a file
stride-gpt quick -i app-description.txt

# Pipe from stdin
echo "A web API that processes payments..." | stride-gpt quick

Interactive REPL — launch an interactive session with tab completion and history:

stride-gpt

Inside the REPL, type /help to see available commands and flags. The version is shown under the ASCII banner at startup. See the Interactive REPL cheat sheet below for the full command and shortcut reference.

Interactive REPL cheat sheet

Launch the REPL with stride-gpt (no arguments), then use these commands and shortcuts.

Commands — type a slash command at the prompt:

/analyze, /quick, and /reports accept flags: -o/--output <path>, -f/--format <markdown\|json\|sarif\|html>, -y/--yes, and -i/--input <path> (/quick). Type /help for the full list.

Keyboard shortcuts:

Check the installed version:

stride-gpt --version    # prints e.g. "stride-gpt 0.19.0" and exits

Common flags:

Each tier also accepts --worker-api-key / --worker-api-base / --worker-max-tokens (and the --architect-* equivalents). Run stride-gpt analyze --help or stride-gpt quick --help for the complete list.

Structured intermediates — when -o <path> is used, three JSON siblings are written alongside the report so the run can be audited or consumed by downstream tools:

A subsystem's outcome is one of completed, budget_exhausted (the call or tool budget ran out and it reported in a final round), parse_failed (its closing answer couldn't be read), error (it raised — see error_class), or skipped (the run budget ran out before it started). The first two count as analysed; the rest make the run partial, and the markdown and HTML reports say so under the affected subsystem.

The format flag (-f) controls the report artefact only; the siblings are always JSON. File paths in the manifest and findings are redacted (./… when under the working directory, ~/… when under $HOME) so a manifest is safe to share. The auto-archive at ~/.stride-gpt/reports/{analyze,quick}/ is unaffected — siblings are only emitted when you pass -o.

View previous reports:

stride-gpt reports        # List recent reports
stride-gpt reports 1      # View report #1
stride-gpt reports 1 -o r.json -f json  # Export a report

Streamlit Web UI

The web UI is a separate app from the CLI. Launch it with:

streamlit run apps/web/main.py

Open the provided URL in your browser and follow the on-screen steps.

Docker

docker run -p 8501:8501 --env-file .env mrwadams/stridegpt

Sample output

Every stride-gpt analyze and stride-gpt quick run emits a markdown report by default (with JSON, SARIF, and a self-contained HTML view available via -f). The markdown groups threats by subsystem in STRIDE tables, adds a cross-cutting section for threats that span components, and closes with a run summary. Optional columns (OWASP LLM/ASI, Insider Category, MITRE ATT&CK, Evidence) appear only when a run populates them.

Threats from analyze cite the code they came from. The agent quotes a snippet, the snippet is matched against the file on disk, and the matched line range is recorded — so the Evidence column shows app/auth/jwt.py:14-19, the HTML report shows the quoted code, and each SARIF result points at those exact lines rather than at the subsystem's file list. A snippet that can't be found is marked unverified rather than dropped, so you can see what the model claimed and judge it.

Below is the markdown from a run against a fictional payments API, so you can see the shape of the output before running the tool. It is a real render from the report engine, not a mock-up.

# STRIDE Threat Model: acme-payments-api

> Generated by STRIDE-GPT on 2026-07-16T09:42:00Z

## Overview

A Python FastAPI service that accepts card payments, stores customer profiles in PostgreSQL, and calls a third-party payment processor. Authentication is handled by JWT bearer tokens issued by an internal auth service; the API is internet-facing behind an API gateway.

## Data Flow Diagram

```mermaid
flowchart LR
    Client[Client App] -->|HTTPS + JWT| Gateway[API Gateway]
    Gateway --> API[Payments API]
    API -->|SQL| DB[(PostgreSQL)]
    API -->|HTTPS| Processor[Payment Processor]
```

## Authentication & Authorization

### Files Analyzed

- `app/auth/jwt.py`
- `app/auth/dependencies.py`

### Threats

| Threat Type | Scenario | Potential Impact | MITRE ATT&CK | Evidence |
|-------------|----------|------------------|--------------|----------|
| Spoofing | An attacker forges a JWT using a weak or leaked signing secret to impersonate another customer. | Full account takeover and unauthorized access to stored payment methods. | T1550.001 (Application Access Token) | app/auth/jwt.py:14-19 |
| Elevation of Privilege | A standard user calls an admin-only refund endpoint that only checks authentication, not role. | Unauthorized refunds and financial loss. | T1068 (Exploitation for Privilege Escalation) | app/auth/dependencies.py:31-38 |

### Recommendations

- Enforce role checks on every privileged route via a shared dependency, not per-handler logic.
- Rotate and store the JWT signing secret in a managed secrets store rather than an env file.

## Payments & Data Storage

### Files Analyzed

- `app/payments/routes.py`
- `app/db/models.py`

### Threats

| Threat Type | Scenario | Potential Impact | MITRE ATT&CK | Evidence |
|-------------|----------|------------------|--------------|----------|
| Information Disclosure | Full card numbers are logged in request debug logs when a payment fails. | PCI-DSS violation and exposure of cardholder data to anyone with log access. | T1552.001 (Credentials In Files) | app/payments/routes.py:88-91 |
| Tampering | The payment amount is taken from a client-supplied field and not re-validated server-side against the order. | A user pays less than the order total by editing the request body. |  | app/payments/routes.py:42-44 |

### Recommendations

- Redact PANs before logging and route logs through a PCI-scoped sink.
- Derive the charge amount from the server-side order record, never the request body.

## Cross-Cutting Threats

| Threat Type | Scenario | Potential Impact | MITRE ATT&CK | Affected Subsystems |
|-------------|----------|------------------|--------------|---------------------|
| Denial of Service | No rate limiting on the payment endpoint lets an attacker exhaust the processor quota and DB connections. | Legitimate payments fail during the attack; possible processor throttling. | T1499 (Endpoint Denial of Service) | Authentication & Authorization, Payments & Data Storage |

## Summary

- **Total threats identified**: 5
- **Subsystems analyzed**: 2
- **Cross-cutting threats**: 1
- **LLM calls**: 34
- **Tool calls**: 58
- **Architect model**: OpenAI API/gpt-6-sol
- **Worker model**: Anthropic API/claude-sonnet-5

stride-gpt quick produces the same table shape from a written description, collapsed into a single Application subsystem instead of per-subsystem findings.

Security Best Practices

STRIDE GPT is designed for local, single-user deployment. When using the tool:

Protecting Your API Keys

Your API keys are sensitive credentials that can incur charges on your account.

✅ DO:

• Enter API keys through the UI (they stay in your browser session)
• Use .env file for convenience on your personal machine
• Set spending limits in your LLM provider dashboard
• Regularly review your API usage and costs
• Clear session when using on shared computers

❌ DON'T:

• Commit .env files to version control (already in .gitignore)
• Share screenshots with API keys visible
• Run STRIDE GPT on untrusted/compromised systems
• Share your API keys with others
• Ignore unexpected API charges

Data Privacy Considerations

When you generate threat models, STRIDE GPT sends data to your chosen LLM provider:

• Application details (type, authentication methods, architecture)
• System architecture descriptions
• Uploaded architecture diagrams/images
• Generated threat models and mitigations

What this means:

• OpenAI, Anthropic, Google, etc. may log this data per their privacy policies
• Consider using generic/fictional system details for demonstrations
• Review your LLM provider's data retention and privacy policies
• For sensitive systems, consider:
  • Using local models (LM Studio)
  • Using providers with stricter privacy guarantees
  • Sanitizing system descriptions before input

For Team/Organization Deployments

If deploying STRIDE GPT for multiple users (not the default use case):

• Add authentication/authorization (not included by default)
• Use a secrets management service for API keys
• Deploy behind VPN or internal network
• Review the SECURITY.md document for additional considerations
• Consider data residency and compliance requirements
• Implement appropriate access controls for generated threat models

Dependency Security

We maintain dependencies and monitor for vulnerabilities:

• Dependencies are updated regularly via Dependabot
• Automated security scanning runs on every commit
• Security advisories are tracked in GitHub Security tab
• Run pip-audit to check for known vulnerabilities locally

See SECURITY.md for comprehensive security information including automated security scanning, vulnerability reporting, and secure development practices.

Reporting Security Issues

Found a security issue? Please report it responsibly:

• Create a security advisory via GitHub's private vulnerability reporting
• Don't post security issues publicly
• We'll acknowledge within 48 hours
• Fixes will be prioritized and released quickly

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

License

MIT