STRIDE-GPT: KI-gestützte Threat Modeling mit STRIDE, MITRE ATT&CK und LiteLLM
An AI-powered threat modeling tool that leverages OpenAI's GPT models to generate threat models for a given application based on the STRIDE methodology.
Auf einen Blick
- Was ist das?
- STRIDE-GPT erzeugt aus Anwendungsbeschreibungen, Codebasen und Diagrammen Bedrohungsmodelle nach STRIDE, ergänzt um MITRE-ATT&CK-/ATLAS-IDs und Angriffsbäume. Ein Blick auf Mechanik, Betrieb und die Grenzen des Ansatzes.
- Für wen ist es gedacht?
- Wer STRIDE-Modelle als ersten Entwurf braucht und die Ausgabe ohnehin von Fachleuten prüfen lässt, findet in STRIDE-GPT ein brauchbares Werkzeug mit ungewöhnlich breitem Provider-Support. Wer ein auditierbares, reproduzierbares Modell ohne externen LLM-Aufruf benötigt, sollte es nicht einsetzen; dafür ist pytm die passendere Wahl.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem STRIDE-GPT adressiert
Threat Modeling ist Aufwand. Wer nach STRIDE arbeitet, muss ein System in Komponenten zerlegen, für jede Komponente die sechs Kategorien Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege durchgehen und daraus Maßnahmen ableiten. Der README beschreibt den Ablauf von STRIDE-GPT so: Nutzer liefern Anwendungsdetails wie Anwendungstyp, Authentifizierungsmethoden und ob die Anwendung internetzugewandt ist oder sensible Daten verarbeitet; das Modell erzeugt daraus seine Ausgabe. Das Werkzeug richtet sich damit an Security-Engineers, Architekten und Entwicklungsteams, die einen strukturierten ersten Entwurf brauchen, aber nicht bei null anfangen wollen. Der Nutzen liegt weniger in fertigen Ergebnissen als in der Abdeckung: ein generierter Entwurf zwingt zur Auseinandersetzung mit Kategorien, die in einem Ad-hoc-Review gern übersehen werden.
Der Ablauf: Prompt, Provider, Ausgabeformat
Die Architektur ist bewusst dünn. STRIDE-GPT ist ein Python-Projekt mit zwei Oberflächen: einer Streamlit-Web-App und einer CLI mit interaktiver REPL. Beide sammeln Eingaben und schicken sie an ein Sprachmodell. Die Modellanbindung läuft laut README über LiteLLM, wodurch OpenAI, Anthropic, Google AI, Mistral, Groq, DeepSeek und lokal gehostete Modelle über LM Studio Server erreichbar sind. Die Liste der unterstützten Reasoning-Modelle nennt unter anderem die GPT-5.4/5.5-Serie, Claude 4.6/4.8 mit Extended Thinking, Gemini 3 und die Mistral-Magistral-Reihe. Interessant ist, was zwischen Eingabe und Ausgabe passiert: Der Agentic-Modus für Codebasen plant laut Feature-Liste selbstständig, erkundet das Repository und synthetisiert Befunde über Subsysteme hinweg. Beim Einlesen von Diagrammen wird nicht das Bild allein ausgewertet, sondern das draw.io-XML geparst, um Komponenten, Verbindungen und Trust Boundaries zu extrahieren. Das ist der wichtigere Punkt: Struktur statt Pixel. Die Ausgabe erfolgt als Markdown, JSON, SARIF oder als eigenständige HTML-Ansicht. Im SARIF-Format tauchen MITRE-Zuordnungen als `mitre_attack`-Properties auf, in Markdown als Spalten, in HTML als verlinkte Elemente.
Installation und Betrieb: uv, Umgebungsvariablen, Docker
Die Installation erfolgt per `pip install stride-gpt`; für Nutzer dieses Wegs hat sich mit Version 0.19 nichts geändert. Wer aus dem Repository arbeitet, installiert über `uv`, denn seit 0.19 ist `uv.lock` laut Changelog die einzige Quelle für Abhängigkeiten. Die zuvor doppelt gepflegten `requirements.txt`-Dateien wurden entfernt; das Docker-UI-Image und der Security-Scan-Workflow installieren über `uv export` aus dem Lockfile. Das ist eine konkrete Verbesserung der Reproduzierbarkeit, weil das gescannte und das ausgelieferte Artefakt nicht mehr auseinanderlaufen können. Für abgeschottete Umgebungen gibt es den Umgebungsschalter `STRIDE_GPT_DRAWIO_URL`: Standardmäßig lädt der eingebettete Editor von `embed.diagrams.net`, mit dieser Variable lässt sich ein selbst gehosteter draw.io-Server eintragen. Weitere Konfiguration läuft laut Feature-Liste über Umgebungsvariablen. Ein `--version`-Flag gibt seit 0.19 die installierte Version aus, und das Banner der interaktiven TUI zeigt sie ebenfalls an. Wer den Agentic-Modus auf einer Codebasis nutzen will, startet die CLI und verwendet den `/analyze`-Befehl, der neben den Befunden auch ein systemweites Data Flow Diagram ausgibt.
Was das Werkzeug nicht leistet
Die zentrale Einschränkung steckt im Namen: Das Ergebnis ist ein Modell, das ein Sprachmodell erzeugt hat. Ob eine einzelne Bedrohung für das konkrete System relevant ist, kann STRIDE-GPT nicht verifizieren, weil es das System nicht kennt, sondern nur die Beschreibung davon. Die Qualität der Ausgabe hängt damit direkt an der Vollständigkeit der Eingabe. Wer eine Anwendung als "Web-App mit Login" beschreibt, bekommt ein Modell für eine Web-App mit Login, nicht für die tatsächliche Architektur. Der zweite Punkt ist der Datenabfluss: Die Anwendungsbeschreibung wird an einen externen Anbieter geschickt, sofern nicht ein lokal gehostetes Modell über LM Studio Server konfiguriert ist. Der README hält dazu fest, dass keine Daten gespeichert werden, was sich auf die Anwendung selbst bezieht, nicht auf den Modellanbieter. Drittens ist die Ausgabe nicht deterministisch. Zwei Läufe mit derselben Beschreibung können unterschiedliche Bedrohungen liefern. Für ein Audit, das einen reproduzierbaren Stand braucht, ist das ein Problem. Und schließlich: Die MITRE-Zuordnung ist eine Modellausgabe, keine verifizierte Attribution. Sie sieht in SARIF wie ein Befund aus, ist aber ein Vorschlag.
Modellwahl als Kostenfrage
Weil die Anbindung über LiteLLM läuft, ist die Modellwahl eine Konfigurationsentscheidung mit direkten Kostenfolgen. Ein Agentic-Lauf über eine Codebasis erzeugt viele Aufrufe: Der Agent plant, liest Dateien, verwirft Hypothesen und synthetisiert am Ende. Wer hier ein Modell der oberen Preisklasse mit Extended Thinking verwendet, zahlt pro Analyse entsprechend. Umgekehrt gilt: Ein kleines Modell liefert bei einer mehrstufigen Codeanalyse mit hoher Wahrscheinlichkeit oberflächliche Befunde. Der README nennt keine Token-Zahlen oder Kostenschätzungen, und ohne eigene Messung lässt sich hier keine belastbare Zahl angeben. Praktisch bedeutet das: Wer den Agentic-Modus regelmäßig in einer CI-Pipeline einsetzen will, sollte zuerst mit einem einzelnen Repository die Aufrufmenge beobachten, bevor er das in einen automatisierten Lauf überführt. Der lokale Weg über LM Studio Server umgeht die API-Kosten, verlagert aber die Rechenlast auf eigene Hardware und liefert je nach Modellgröße schwächere Ergebnisse.
Alternative: pytm und der Unterschied im Ansatz
Wer Threat Modeling als Code mit nachvollziehbaren Ergebnissen betreiben will, landet bei pytm. Der Unterschied ist grundsätzlicher Natur. pytm ist eine Python-Bibliothek, in der das System als Objektmodell beschrieben wird: Elemente, Datenflüsse, Grenzen. Die Bedrohungen ergeben sich aus Regeln, die auf dieses Modell angewendet werden. Das Ergebnis ist deterministisch, versionierbar und ohne externen Dienst reproduzierbar. Dafür deckt es nur ab, was als Regel formuliert wurde, und es verlangt, dass jemand das System von Hand modelliert. STRIDE-GPT dreht das um: Es akzeptiert eine vage Beschreibung und füllt die Lücken mit Modellwissen. Das erzeugt schneller einen breiten Entwurf, aber keinen prüfbaren. Die beiden Ansätze schließen sich nicht aus. Ein realistischer Ablauf wäre, mit STRIDE-GPT einen Entwurf zu erzeugen und die relevanten Teile anschließend in einem pytm-Modell festzuhalten, das dann im Repository versioniert wird.
Wartung, Lizenz und der Blick auf die Version
Das Projekt steht unter der MIT-Lizenz, was kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange der Copyright-Hinweis erhalten bleibt. Für Unternehmen, die STRIDE-GPT forken und intern betreiben wollen, ist das die passende Grundlage; der README verweist dafür auf einen Operationalization Guide unter `docs/operationalization-guide.md`, der beschreibt, wie eigene Sicherheitskontrollen und Compliance-Anforderungen in die Modelle injiziert werden. Wartungsseitig ist die Konsolidierung auf `uv.lock` in 0.19 ein Signal für aktive Pflege, ebenso das `--version`-Flag. Der Preis dafür ist eine gewisse Beweglichkeit an der Modellgrenze: Die unterstützten Modellversionen ändern sich, und ein Update kann die Ausgabequalität verändern, ohne dass sich am Code etwas tut. Wer STRIDE-GPT in einem regulierten Umfeld betreibt, sollte die Modellversion deshalb explizit pinnen und nicht dem Standard des Anbieters folgen. Ob das Projekt für einen konkreten Anwendungsfall passt, lässt sich am schnellsten über die gehostete Instanz unter stridegpt.streamlit.app prüfen, bevor man eine eigene Installation aufsetzt.
Redaktionelles Fazit
Wer STRIDE-Modelle als ersten Entwurf braucht und die Ausgabe ohnehin von Fachleuten prüfen lässt, findet in STRIDE-GPT ein brauchbares Werkzeug mit ungewöhnlich breitem Provider-Support. Wer ein auditierbares, reproduzierbares Modell ohne externen LLM-Aufruf benötigt, sollte es nicht einsetzen; dafür ist pytm die passendere Wahl. Vor dem Einsatz zu klären sind: welcher Provider und welche Modellversion verwendet werden, ob die Anwendungsbeschreibung das Haus verlassen darf, und ob die mitgelieferte Operationalization Guide tatsächlich die eigenen Kontrollen abbildet.
Community-Notizen