security-threat-model

security-threat-model の概要

security-threat-model で何ができるか

security-threat-model skill は、リポジトリやパスを AppSec の実態に即した脅威モデルへ落とし込みます。注目するのは、信頼境界、資産、攻撃者の目的、悪用経路、そして対策です。実際のコードベースに対して、判断に使えるセキュリティ観点を得たいときに選ぶべき security-threat-model for Threat Modeling です。汎用チェックリストではなく、意思決定にそのまま使える材料が必要な場面に向いています。

どんな人に向いているか

ソフトウェアをリリースしている、リスクの高い機能をレビューしている、あるいは AppSec レビューの準備をしていて、エンジニアと共有しやすい簡潔な Markdown 出力が欲しいなら、この security-threat-model skill を使ってください。対象の repo、service、subsystem をすでに把握していて、モデルを実装の具体に結びつけたいときに最適です。

どんなときに役立つか

この skill が特に強いのは、特定の repository、folder、service、CLI、workflow を脅威モデル化したいときです。現実的な攻撃経路を洗い出し、影響度を優先度づけし、仮定を明示するよう設計されているため、確認済みのアーキテクチャと推定ベースの挙動を切り分けやすくなります。

どんな用途には向かないか

全体アーキテクチャの要約、通常のコードレビュー、セキュリティ以外の設計作業には使わないでください。悪用ケース、attack surface、AppSec リスクが関係しない依頼なら、security-threat-model の導入は価値以上に手間を増やしがちです。

security-threat-model skill の使い方

インストールして repo を確認する

npx skills add openai/skills --skill security-threat-model を実行して skill をインストールします。インストール後は、まず SKILL.md を読み、そのあと references/prompt-template.md と references/security-controls-and-assets.md を開いて、期待される出力形式と、security-threat-model ガイドで使う資産・コントロールの語彙を確認してください。

入力は具体的に与える

強いプロンプトには、repo 名、対象範囲の path、runtime の形、そして既に分かっているデプロイ情報が含まれます。たとえば「この monorepo の services/api を脅威モデル化してください。インターネット公開で、JWT 認証を使い、ユーザーアップロードを保存し、payment provider と連携しています」といった具合です。「このコードをレビューして」よりずっと有効です。なぜなら、この skill が有用なモデルを作るには、スコープ、公開範囲、信頼前提が必要だからです。

うまく指示するコツ

security-threat-model の使い方としては、repo に根ざした脅威モデルを、証拠に基づく主張、優先度つきの脅威、明示的な未解決事項つきで出すよう依頼するのが基本です。repo の要約があれば含め、なければ要約を生成しつつ不明点を明示するよう求めてください。さらに、runtime の挙動、API、データ処理、サプライチェーンリスクのどれを重視するかも伝えると、出力の焦点がぶれません。

おすすめの進め方と読むべきファイル

まず SKILL.md でワークフローを把握し、次に references/prompt-template.md で脅威モデルの契約内容を確認し、references/security-controls-and-assets.md で資産/コントロールのチェックリストを見てください。repo に agents/openai.yaml やその他のサポートファイルがある場合は、それらを使って出力をプロジェクトの想定インターフェースや文言に合わせるとよいです。

security-threat-model skill の FAQ

これは AppSec チーム向けだけですか？

いいえ。リリース前や設計変更のタイミングで実践的な脅威モデルが必要な、開発者、プラットフォームエンジニア、セキュリティエンジニア、レビュアーに役立ちます。出力は技術的ですが、実装判断に使いやすいように書かれています。

通常のプロンプトと何が違いますか？

通常のプロンプトでは、リスクの一般的な一覧に終わりがちです。security-threat-model skill は repo の証拠を前提にし、runtime と test や tooling を切り分け、広い脆弱性雑学ではなく悪用経路を掘り下げるよう促します。そのため、security-threat-model usage の目的がブレストではなく、根拠のあるレビューである場合により適しています。

初心者でも使えますか？

はい。システムの内容、repo の path または要約を説明できるなら使えます。初心者が特に良い結果を得やすいのは、システムが何をするか、誰が使うか、どんなデータを扱うか、インターネット公開か他テナント公開かを明示できる場合です。

どんなときにインストールしないほうがいいですか？

高レベルな製品説明、コードの walkthrough、簡単なアーキテクチャ図だけが必要なら、security-threat-model の導入は見送ってください。十分な repo 文脈を与えられず、根拠のあるセキュリティ分析ができない場合も不向きです。

security-threat-model skill を改善する方法

スコープと根拠をもっと明確にする

品質が最も大きく上がるのは、スコープを精密にすることです。具体的には、正確な path、entrypoint、data store、外部 service、そしてデプロイ環境です。repo の要約、アーキテクチャメモ、ユーザー向け endpoint 一覧を提供できれば、security-threat-model skill は推測ではなく実在のコンポーネントに脅威を結びつけられます。

攻撃者の目的と境界を明示する

何を最も守りたいのかを伝えてください。たとえば、customer data、auth token、内部の admin 操作、可用性、tenant isolation などです。さらに、browser-to-API、worker-to-queue、service-to-third-party のような trust boundary も書き添えてください。こうした境界が、もっとも有益な悪用経路分析の起点になります。

優先順位と実行可能性のある出力を求める

より良い結果が欲しいなら、発生確率と影響度での優先順位づけと、特定の境界やコンポーネントに対応した mitigation を要求してください。そうすることで、抽象的な懸念の列挙ではなく、エンジニアが実際に動ける security-threat-model guide を出しやすくなります。

不足している情報を反映して反復する

1 回目の出力のあとで、auth 設計、upload 処理、background job、multi-tenant 前提など、特に重要な不明点を返してください。脅威の数を増やすよう頼むより、そのギャップを埋めていくほうが 2 回目の改善幅は大きくなりやすいです。モデルの推測が減り、実装に使える精度が上がるからです。