threat-model-generation

脅威モデルの生成

STRIDE 手法を使用して、リポジトリの包括的なセキュリティ脅威モデルを生成します。このスキルはコードベースのアーキテクチャを分析し、ほかのセキュリティスキルが参照できるよう、LLM 向けに最適化された脅威モデル文書を作成します。

このスキルを使用する場面

• 初回セットアップ - 新しいリポジトリに初期脅威モデルが必要な場合
• アーキテクチャの変更 - コンポーネント、API、データフローに大幅な変更があった場合
• セキュリティ監査 - 定期的なレビューやコンプライアンス要件がある場合
• 手動の依頼 - セキュリティチームから脅威モデルの更新を依頼された場合

入力

このスキルを実行する前に、以下の情報を収集するか、確認してください。

入力	説明	必須
リポジトリのパス	分析対象のルートディレクトリ	はい（デフォルト：現在のディレクトリ）
既存の脅威モデル	更新する場合の既存の .factory/threat-model.md のパス	いいえ
コンプライアンス要件	考慮するフレームワーク（SOC2、GDPR、HIPAA など）	いいえ
セキュリティ担当者	セキュリティチームへの通知に使用するメールアドレス	いいえ

手順

以下の手順を順番に実行してください。

ステップ 1：リポジトリ構造を分析する

コードベースを調査して、システムを把握します。

1. 言語とフレームワークを特定する

   • package.json、requirements.txt、go.mod、Cargo.toml などを確認します。
   • 主要な技術スタックを記録します（例：Next.js、Django、Go マイクロサービス）。

2. コンポーネントとサービスをマッピングする

   • apps/、services/、packages/ ディレクトリを確認します。
   • エントリーポイントを特定します：API ルート、CLI コマンド、Web ハンドラー。
   • データベース、キャッシュ、メッセージキューを記録します。

3. 外部インターフェースを特定する

   • HTTP エンドポイント（REST、GraphQL）
   • ファイルアップロードのハンドラー
   • Webhook の受信先
   • OAuth/SSO の統合
   • ユーザー入力を受け付ける CLI コマンド

4. データフローを追跡する

   • ユーザー入力はどのようにシステムに入りますか？
   • 機密データはどこに保存されますか？
   • どの外部サービスが呼び出されますか？

ステップ 2：信頼境界を特定する

セキュリティゾーンを定義します。

1. パブリックゾーン（信頼できない）

   • すべての外部 HTTP エンドポイント
   • 認証のない公開 API
   • ユーザーがアップロードしたファイル

2. 認証済みゾーン（部分的に信頼できる）

   • 有効なセッション／トークンを必要とするエンドポイント
   • ユーザー固有のデータアクセス
   • レート制限付き API

3. 内部ゾーン（信頼できる）

   • サービス間通信
   • 管理者専用エンドポイント
   • データベース接続
   • シークレット管理

信頼境界の場所と、各ゾーン間の移行を検証する方法を記録します。

ステップ 3：重要な資産を一覧化する

データを機密性に応じて分類します。

1. PII（個人を特定できる情報）

   • ユーザーのメールアドレス、氏名、住所、電話番号
   • 保護対策を記録します。

2. 認証情報とシークレット

   • パスワードハッシュ、API キー、OAuth トークン
   • JWT 署名キー、暗号化キー
   • ローテーションポリシーを記録します。

3. ビジネス上重要なデータ

   • 取引記録、顧客データ
   • 独自のアルゴリズム、企業秘密
   • アクセス制御を記録します。

ステップ 4：STRIDE 分析を適用する

主要な各コンポーネントについて、6 つのカテゴリすべてで脅威を分析します。

S - なりすまし（Spoofing Identity）

• 攻撃者がユーザーやサービスになりすますことは可能ですか？
• 認証メカニズムは安全ですか？
• 確認事項：脆弱なセッション管理、API キーの露出、多要素認証の欠如

T - データの改ざん（Tampering with Data）

• 攻撃者が転送中または保存済みのデータを変更できますか？
• 確認事項：SQL インジェクション、XSS、マスアサインメント、入力検証の欠如

R - 否認（Repudiation）

• ユーザーが自身の行った操作を否認できますか？
• 確認事項：監査ログの欠如、不十分なロギング、改ざん不能な記録の欠如

I - 情報漏えい

• 攻撃者が、本来アクセスできないデータにアクセスできる可能性はありますか？
• 確認する項目：IDOR、詳細すぎるエラー、ハードコードされたシークレット、ログ内のデータ漏えい

D - サービス拒否

• 攻撃者がサービスの可用性を妨害できる可能性はありますか？
• 確認する項目：レート制限の不備、リソース枯渇、アルゴリズムの計算量

E - 権限昇格

• 攻撃者が許可されていないアクセス権限を取得できる可能性はありますか？
• 確認する項目：認可チェックの不備、ロールの操作、権限昇格

特定した脅威ごとに、次の内容を記載します。

• 攻撃シナリオを説明する
• 脆弱なコンポーネントを列挙する
• 確認すべきコードパターンを示す
• 既存の緩和策を記載する
• 不足している点を特定する
• 深刻度（CRITICAL/HIGH/MEDIUM/LOW）と発生可能性を割り当てる

ステップ 5：脆弱性パターンを文書化する

このコードベースの技術スタックに特化したコードパターンのライブラリを作成します。

# Example: SQL Injection patterns for Python
# VULNERABLE
sql = f"SELECT * FROM users WHERE id = {user_id}"

# SAFE
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

次のパターンを含めます。

• SQL インジェクション
• XSS（クロスサイトスクリプティング）
• コマンドインジェクション
• パストラバーサル
• 認証バイパス
• IDOR（安全でない直接オブジェクト参照）

ステップ 6：出力ファイルを生成する

2 つのファイルを作成します。

1. .factory/threat-model.md

stride-template.md のテンプレートを使って、次の内容を含む包括的な脅威モデルを生成します。

• アーキテクチャの説明を含むシステム概要
• 信頼境界とセキュリティゾーン
• 攻撃対象領域の一覧
• 重要資産の分類
• 各コンポーネントの STRIDE 脅威分析
• 脆弱性パターンライブラリ
• セキュリティテスト戦略
• 前提条件と受容するリスク
• バージョン変更履歴

文書は自然な言葉で記述し、LLM が理解しやすいようにコード例を含めてください。

2. .factory/security-config.json

設定メタデータを生成します。

{
  "threat_model_version": "1.0.0",
  "last_updated": "<ISO timestamp>",
  "security_team_contacts": [],
  "compliance_requirements": [],
  "scan_frequency": "on_commit",
  "severity_thresholds": {
    "block_merge": ["CRITICAL"],
    "require_review": ["HIGH", "CRITICAL"],
    "notify_security_team": ["CRITICAL"]
  },
  "vulnerability_patterns": {
    "enabled": [
      "sql_injection",
      "xss",
      "command_injection",
      "path_traversal",
      "auth_bypass",
      "idor"
    ],
    "custom_patterns_path": null
  }
}

次の情報に基づいてカスタマイズします。

• 検出されたコンプライアンス要件（ドキュメント、設定、またはユーザー入力から）
• セキュリティチームの連絡先（提供されている場合）
• 技術スタック（関連する脆弱性パターンを有効化）

完了条件

次の条件を満たしたら、スキルは完了です。

• .factory/threat-model.md が存在し、すべてのセクションに内容が記載されている
• .factory/security-config.json が存在し、有効な JSON が記載されている
• 主要なすべてのコンポーネントに STRIDE 分析がある
• 脆弱性パターンが技術スタックに合っている
• 文書が自然な言葉で記述されている（LLM が読み取り可能）
• プレースホルダーのテキストが残っていない

検証

完了前に次のチェックを実行します。

# Verify threat model exists and is non-empty
test -s .factory/threat-model.md && echo "✓ Threat model exists"

# Verify config is valid JSON
cat .factory/security-config.json | jq . > /dev/null && echo "✓ Config is valid JSON"

# Check threat model has key sections
grep -q "## 1. System Overview" .factory/threat-model.md && echo "✓ Has System Overview"
grep -q "## 5. Threat Analysis" .factory/threat-model.md && echo "✓ Has Threat Analysis"
grep -q "## 6. Vulnerability Pattern Library" .factory/threat-model.md && echo "✓ Has Pattern Library"

実行例

初期の脅威モデルを生成する：

Generate a threat model for this repository using the threat-model-generation skill.

アーキテクチャ変更後に既存の脅威モデルを更新する：

Update the threat model - we added a new payments service in services/payments/.

コンプライアンス要件を指定して生成する：

Generate a threat model for this repository. We need to comply with SOC2 and GDPR.

参考資料

• STRIDE 脅威モデリング
• OWASP 脅威モデリング
• テンプレート：stride-template.md（このスキルのディレクトリ内）