STRIDE GPT レビュー: LLM で STRIDE 脅威モデルを生成する CLI と Streamlit アプリ

STRIDE GPT が埋めようとしている穴

脅威モデリングは、設計が固まる前に攻撃者の視点を混ぜ込む作業である。STRIDE は Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege の 6 分類で脅威を整理する枠組みとして知られるが、実際に手を動かすと、アプリケーションの構成を読み込み、6 分類それぞれについて妥当な脅威を書き出し、緩和策と対応づけるという反復作業になる。この反復が重い。設計が変わるたびに同じ棚卸しをやり直すことになり、レビューのたびに担当者の記憶と文章力に依存する。

STRIDE GPT はこの下書き部分を LLM に任せる。README によれば、利用者はアプリケーションの種類、認証方式、インターネット公開の有無、機微データを扱うかどうかといった情報を入力し、モデルがその情報をもとに出力を生成する。対象は Web アプリに限らない。リポジトリを指定してコードベースを解析させるモード、エージェント型 AI システム向けに OWASP Top 10 for Agentic Applications を組み込むモード、生成 AI アプリ向けに OWASP LLM Top 10 を組み込むモードが用意されている。

想定読者は、専任のセキュリティエンジニアを置けない開発チームだ。脅威モデルを初稿まで持っていく時間を削り、レビューで中身を詰める方向に工数を寄せる、という使い方になる。

入力から出力までの流れと、図を扱う仕組み

中心にあるのはプロンプトとモデル呼び出しの組み合わせで、入力は大きく 3 系統ある。テキストでアプリケーションを説明する系統、アーキテクチャ図などの画像を渡す系統、GitHub リポジトリを解析させる系統である。README はマルチモーダル対応を挙げており、視覚に対応したモデルであれば図を入力に使えるとしている。

図の扱いには段階がある。画像をそのままモデルに見せる経路と、埋め込みの diagrams.net エディタで作った図を XML として解析する経路だ。README は後者について、コンポーネント、接続、信頼境界を抽出し、画像解析だけの場合より明確に豊かな文脈を与えると説明している。つまり図を「絵」ではなく「構造データ」として読ませる方向に寄せている。

もうひとつ特徴的なのが Data Flow Diagram の扱いだ。アプリケーションの説明から DFD を生成する、あるいはアップロードされた DFD 画像を解析する。生成された Mermaid のソースはその場で編集でき、確定した図が脅威モデルと攻撃ツリーのプロンプトに「権威あるシステムモデル」として渡される。CLI の /analyze もシステムレベルの DFD を所見と一緒に出力する。

出力側は Markdown、JSON、SARIF、単体で完結する HTML の 4 形式。SARIF は GitHub、GitLab、Azure DevOps、IDE に取り込める形式で、脅威には MITRE ATT&CK の Enterprise、ML/LLM 固有の攻撃には ATLAS のテクニック ID が注釈として付く。Markdown では列、HTML ではリンク付きのピル、SARIF では mitre_attack プロパティとして現れる。

インストールと起動、設定キー

配布は PyPI 経由の pip と、Docker コンテナイメージ、そして Streamlit のホスト版 https://stridegpt.streamlit.app である。README の Installation 節と Repository layout 節が導入手順を示している。バージョン 0.19 の変更点として、依存管理が uv に一本化され、uv.lock が唯一の正とされた。重複していた requirements.txt は廃止され、Docker の UI イメージとセキュリティスキャンのワークフローは uv export 経由で uv.lock からインストールする。README は pip install stride-gpt の利用者には変更がないとしている。

CLI には対話型 REPL があり、タブ補完、履歴、進捗表示を備える。README は README 内の interactive REPL cheat sheet を参照先として挙げている。バージョン確認は stride-gpt --version で行い、対話 TUI のバナーにも実行中のバージョンが出る。

設定は環境変数で渡す。README が名前を明示しているのは STRIDE_GPT_DRAWIO_URL で、埋め込み draw.io エディタの読み込み先を既定のホスト版 embed.diagrams.net から自前の diagrams.net に差し替えるためのものだ。自己ホストやエアギャップ環境ではこれを使う、と説明されている。モデルの選択は LiteLLM 経由で行い、OpenAI、Anthropic、Google AI、Mistral、Groq、DeepSeek、そして LM Studio Server によるローカルホストに対応する。推論モデルとしては OpenAI の GPT-5.4/5.5 系、拡張思考を伴う Anthropic の Claude 4.6/4.8、Google の Gemini 3、Mistral の Magistral 系が挙げられている。

データは保存されない。README はアプリケーションの詳細が保存されないと明記している。

CLI のエージェント解析と、図を構造として読む設計

バージョン 0.19 系で目を引くのは、CLI のエージェント型コードベース解析だ。README の表現では、CLI をコードベースに向けると自律的で深い STRIDE 脅威モデルが得られ、エージェントが計画し、探索し、サブシステムをまたいで所見を統合する。単発のプロンプト応答ではなく、複数ステップの探索を前提とした作りになっている。

この設計は、脅威モデリングの入力が本質的に大きいという事実に対応している。アプリケーション全体の説明を 1 つのプロンプトに収めようとすると、どこかが薄くなる。エージェントに分割して探索させ、最後に統合するほうが、サブシステム間の境界を拾いやすい。ただしこれは、モデル呼び出しの回数が増えることを意味する。コストと待ち時間は入力の規模に比例して増える側に倒れる。

同様の判断が architectural pattern detection にも現れている。RAG パイプライン、マルチエージェントシステム、コード実行環境、ツール群といったパターンをアプリケーションの説明から自動検出する。README はこの機能が CSA MAESTRO に着想を得たと記している。検出結果は脅威の選び方に効く。RAG があるなら検索経路への間接プロンプト注入が候補に入る、という具合だ。

図を XML として解析する判断も同じ線上にある。画像解析だけでは信頼境界の位置が曖昧になりやすい。コンポーネントと接続を明示的なデータとして取り出せば、境界をまたぐ通信を列挙できる。ここは実装の方向性として筋が通っている。

向かない場面と、出力をそのまま信じられない理由

最大の制約は、出力が LLM の生成物であるという点だ。README は脅威モデルと緩和策を生成すると書いているが、生成された脅威が対象システムに実在するかを検証する仕組みには触れていない。したがって、規制対象のシステムや、監査で根拠の追跡を求められる場面では、出力をそのまま成果物にできない。脅威モデルは下書きであり、採否の判断は人間が行う前提で運用する必要がある。

2 つ目の制約は入力の質への依存だ。アプリケーションの種類、認証方式、公開範囲、機微データの扱いといった項目をどれだけ正確に埋められるかで結果が変わる。逆に言えば、これらの情報が整理されていない段階で回しても、一般的な脅威の羅列に近いものが出る。設計が固まっていない初期段階のほうが使いどころがある、とは単純には言えない。

3 つ目は外部 LLM への依存である。LiteLLM 経由で LM Studio Server によるローカルホストも選べるため、完全な外部依存を避ける道は用意されている。ただしローカルで動かすモデルの能力が、脅威モデリングに足る推論を返すかは別問題で、README はこの点の比較を示していない。エアギャップ環境を謳うには、モデル選定の指針がもう少し欲しいところだ。

4 つ目はエージェント解析のコストだ。複数ステップの探索は呼び出し回数を増やす。大規模なリポジトリに向けたときの待ち時間と費用は、事前に小さめの対象で測っておかないと読めない。

代替手段との違い: 手作業のテンプレートか、汎用チャットか

比較対象として素直なのは、OWASP Threat Dragon のような図ベースの脅威モデリングツールだ。Threat Dragon はデータフロー図を描き、その図の上に脅威を手で置いていく。図が唯一の正であり、脅威は人間が選ぶ。STRIDE GPT は逆で、図や説明文を入力にして脅威の候補を機械が列挙し、人間が選別する。どちらが優れているという話ではなく、工数の置き場所が違う。図を正確に保つ規律がチームにあるなら Threat Dragon のほうが再現性は高い。脅威の洗い出しに時間がかかっていて、まず候補が欲しいなら STRIDE GPT が向く。

もうひとつの比較対象は、汎用のチャット UI に STRIDE のプロンプトを貼る運用だ。これは追加のツールを入れずに済むが、出力形式が毎回ばらつく。STRIDE GPT が提供するのは、STRIDE の 6 分類、攻撃ツリー、緩和策、DREAD によるリスクスコア、Gherkin のテストケース、そして MITRE ATT&CK と ATLAS の ID 注釈までを含む定型の出力だ。SARIF で出せば GitHub のコードスキャンに載せられる。この形式の固定が、汎用チャットとの実質的な差になる。

ただし汎用チャットに対する優位は、プロンプトと出力スキーマの作り込みに依存する。モデルを差し替えたときにスキーマが崩れないかは、実際に試すまで分からない。

ライセンスと保守の見取り図

ライセンスは MIT である。商用利用を含めて比較的自由度が高い条件だが、これは法的助言ではない。組織のポリシーに照らした判断は別途必要になる。

保守の面で材料から読み取れるのは、依存管理を uv に一本化したことの意味だ。uv.lock が唯一の正となり、Docker イメージとセキュリティスキャンが同じロックから派生する。ビルドされるものとスキャンされるものがずれなくなった、と README は説明している。サプライチェーンの観点では素直に良い変更で、追跡すべきファイルが 1 つに減ったことになる。

一方、モデル側の変化はツール側では制御できない。README が対応を挙げるモデル群は世代が明記されており、プロバイダの API 変更やモデル廃止のたびに追随が必要になる。LiteLLM がその差を吸収する層として入っているが、抽象化の層があることと、実際に動き続けることは別だ。導入時は、使う予定のプロバイダとモデル名を固定して、まず 1 つのアプリケーションで通しで回してみる。そこで得た出力を、チームが手で書いた既存の脅威モデルと並べて読み、抜けと過剰のどちらが多いかを確認する。その結果が、このツールを下書き生成器として残すか、別の手段に戻すかの判断材料になる。

編集部の結論

STRIDE の観点を毎回同じ形式で洗い出したい開発チーム、とくに脅威モデリングの初稿を人手でゼロから書くコストを下げたい小規模チームに向く。逆に、規制対象のシステムで根拠の追跡可能性が必須な場面や、ネットワークから切り離された環境で外部 LLM を呼べない場面では、そのままでは使えない。導入前に確認すべきは 3 点ある。第一に、社内のセキュリティ基準やコンプライアンス要件をプロンプトへ注入できるか。README は docs/operationalization-guide.md でその方法を示していると説明しているので、まずこの文書を読む。第二に、STRIDE_GPT_DRAWIO_URL を自前の diagrams.net に向けられるか。第三に、生成物をどの形式で既存のワークフローへ流すかで、SARIF を選ぶなら mitre_attack プロパティが期待どおり埋まるかを実際の出力で確かめる。これらが満たせないなら、このツールは脅威モデルの下書き生成器として割り切り、最終判断は人間が行う運用に固定したほうがよい。

公式情報源

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