mcpField
S
security-audit

security-audit

github.com/andrewvaughanセキュリティ15101 回インストール35 週間前に更新
リポジトリ

security-audit について

アプリケーションコードを体系的に評価し、優先度付きの修正案を作成するセキュリティ監査スキルです。静的解析、STRIDE 脅威モデリング、攻撃ツリー、アーキテクチャ評議会のレビューを組み合わせます。

主な機能

  1. 01自動 SAST とセキュリティ強化レビュー
  2. 02STRIDE 脅威モデリング
  3. 03高リスク項目の攻撃ツリー
  4. 04アーキテクチャ評議会レビュー
  5. 05優先度付きの指摘と修正案
  6. 06任意の修正と GitHub Issue の追跡

活用シーン

  1. 01リリース前のアプリケーション評価
  2. 02セキュリティインシデント後の監査
  3. 03認証や API の脅威分析
  4. 04監査指摘の GitHub Issue 化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/andrewvaughan/agent-council --skill security-audit

インストール後、Claude Code で/security-auditを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
backend-specialist.md
principal-engineer.md
security-engineer.md
councils/
architecture-council.md

詳細

セキュリティ監査ワークフロー

自動静的解析、脅威モデリング、多角的な審査会レビューを組み合わせて、包括的なセキュリティ監査を実施します。このスキルでは、優先順位を付けた監査レポートと、実行可能な修正手順を作成します。

対象範囲からの除外

重要

この監査の対象はアプリケーションレベルのセキュリティのみです。本番環境のインフラ（TLS 終端、リバースプロキシ、ネットワークセグメンテーション、ファイアウォールルール、DNS）は別のプロジェクトで管理されており、対象外です。TLS の欠落、リバースプロキシの設定、ネットワークレベルの MITM リスク、本番デプロイのトポロジーを指摘事項として挙げないでください。

ステップ 1：監査範囲の定義

ユーザーに次の点を尋ねます。

  • 範囲：コードベース全体ですか、それとも特定の領域ですか？（例：apps/api/src/auth/、apps/web/src/）
  • きっかけ：監査を実施する理由は何ですか？（定期監査、リリース前、セキュリティインシデント、新機能、依存関係の更新）
  • 重点領域：認証、API セキュリティ、データ保護、フロントエンドセキュリティ、またはすべてですか？
チェックポイント：次に進む前に、監査範囲と重点領域をユーザーに確認します。

ステップ 2：自動 SAST スキャン

定義した範囲に対して /security-scanning:security-sast を実行します。

次の項目をスキャンします。

  • インジェクション：SQL インジェクション、NoSQL インジェクション、コマンドインジェクション、LDAP インジェクション
  • XSS：反射型、格納型、DOM ベースのクロスサイトスクリプティング
  • CSRF：状態を変更するエンドポイントにおける CSRF 対策の欠落
  • 認証：脆弱なパスワードポリシー、認証フローの不備、セッション固定
  • シークレット：ハードコードされた API キー、パスワード、トークン、接続文字列
  • 依存関係：npm パッケージにおける既知の脆弱性（CVE）
  • デシリアライズ：安全でないデシリアライズのパターン
  • プロトタイプ汚染：JavaScript 固有のオブジェクト操作攻撃

次の情報を含めて、すべての指摘事項を収集します。

  • 重大度：Critical / High / Medium / Low / Info
  • カテゴリ：OWASP Top 10 との対応
  • 場所：ファイルパスと行番号
  • 説明：脆弱性の内容
  • 証拠：指摘のきっかけとなった具体的なコードパターン
  • 修正方法：修正方法

ステップ 3：セキュリティ強化レビュー

包括的なセキュリティ強化レビューのために /security-scanning:security-hardening を実行します。

HTTP セキュリティ
  • セキュリティヘッダー（HSTS、CSP、X-Frame-Options、X-Content-Type-Options）
  • CORS の設定（許可するオリジン、メソッド、ヘッダー）
  • Cookie のセキュリティフラグ（HttpOnly、Secure、SameSite）
API セキュリティ
  • すべての公開エンドポイントにおけるレート制限
  • 入力検証の完全性（すべてのユーザー入力を検証）
  • インジェクション防止のための出力エンコーディング
  • API キーとトークンの管理
  • リクエストサイズの制限
認証と認可
  • パスワードのハッシュ化アルゴリズム（bcrypt、argon2）
  • JWT の設定（アルゴリズム、有効期限、更新）
  • セッション管理（タイムアウト、無効化、ローテーション）
  • ロールベースのアクセス制御の適用
  • OAuth/OIDC の設定（該当する場合）
データ保護
  • PII の保存時の暗号化
  • 機密データの転送時の暗号化（TLS 1.2 以上）
  • ログに機密データを含めない
  • エラーメッセージから内部情報を漏えいさせない
  • データベース接続で SSL を使用
環境変数
  • コードやログにシークレットをハードコードしない
  • 起動時の検証により、本番環境で脆弱なシークレットやデフォルトのシークレットを拒否する

ステップ 4：STRIDE 脅威モデリング

脅威を体系的にモデル化するために /security-scanning:stride-analysis-patterns を実行します。

なりすまし
  • ユーザー ID を偽装できますか？（認証の回避、トークンの窃取）
  • サービス ID を偽装できますか？（サービス間認証）
改ざん
  • 転送中のリクエストデータを改変できますか？
  • 認可なしにデータベースのレコードを変更できますか？
  • クライアント側のデータ（localStorage、Cookie）を改ざんできますか？
否認
  • セキュリティに関連するすべての操作がログに記録されていますか？
  • ユーザーは操作を実行したことを否認できますか？
  • データ変更の監査証跡はありますか？
情報漏えい
  • エラーメッセージを通じて機密データが漏えいする可能性はありますか？
  • 認可されていないユーザーが他のユーザーのデータにアクセスできますか？
  • タイミング攻撃やサイドチャネルによる漏えいはありますか？
サービス拒否
  • 過剰なリクエストによってシステムが過負荷になる可能性はありますか？
  • レート制限がなく、リソースを大量に消費するエンドポイントはありますか？
  • 大きなペイロードによってメモリが枯渇する可能性はありますか？
権限の昇格
  • 一般ユーザーが管理者機能にアクセスできますか？
  • 水平権限昇格（別のユーザーのリソースへのアクセス）が発生する可能性はありますか？
  • IDOR（安全でない直接オブジェクト参照）の脆弱性はありますか？

各脅威について、以下を記録します。

  • 可能性：高／中／低
  • 影響：重大／高／中／低
  • リスクスコア：可能性 × 影響
  • 既存の緩和策：すでに導入されている対策
  • ギャップ：不足している対策

Step 5: 攻撃ツリー分析

STRIDEで特定された最もリスクの高い脅威の上位3つについて：

/security-scanning:attack-tree-construction を呼び出し、以下を示す攻撃ツリーを作成します。

  • 攻撃目標：攻撃者が達成しようとしていること
  • 攻撃経路：目標に到達するさまざまな方法
  • サブ目標：必要となる中間ステップ
  • 必要なリソース：攻撃者に必要なスキルレベル、ツール、アクセス権
  • 既存の防御策：各経路における現在の緩和策
  • 最も弱い箇所：防御が最も手薄な箇所

Step 6: アーキテクチャ評議会によるセキュリティレビュー

セキュリティレビューのため、アーキテクチャ評議会（.claude/councils/architecture-council.md で定義）の一部を招集します。

モデルの選択：エージェントのモデル仕様と Task ツールのパラメーターの対応付けについては、README.md の モデルの選択 セクションを参照してください。

セキュリティエンジニア（リード）— consult: security-scanning
  • 自動検出結果を検証します（誤検知を特定します）
  • 実際のリスクに基づいて修正の優先順位を決定します
  • 全体的なセキュリティ態勢を評価します
  • 評価：強固／十分／改善が必要／重大なリスク
プリンシパルエンジニア — consult: full-stack-orchestration
  • 必要な修正がアーキテクチャに与える影響を評価します
  • 脆弱性を生み出す体系的なパターンを特定します
  • 多層防御のためのアーキテクチャ変更を提案します
  • 評価：アーキテクチャは健全／リファクタリングが必要／根本的な問題あり
バックエンドスペシャリスト — consult: backend-development
  • バックエンド固有のセキュリティパターンを評価します
  • API セキュリティの実装品質を評価します
  • データベースのアクセスパターンにインジェクションのリスクがないか確認します
  • 評価：十分に保護されている／いくつかのギャップあり／重大な懸念あり

Step 7: 監査レポートの提示

構造化されたセキュリティ監査レポートを作成します。

エグゼクティブサマリー
  • 全体的なセキュリティ態勢：強固／十分／改善が必要／重大
  • 検出事項の合計：深刻度別の件数（重大、高、中、低）
  • 主なリスク上位3件：対処すべき最も重要な問題
  • STRIDE の網羅状況：リスクレベルを含む脅威カテゴリの概要
重大および高リスクの検出事項（必須修正）

各検出事項について：

  • 深刻度、カテゴリ、OWASP との対応付け
  • ファイルと行番号
  • 根拠を含む説明
  • 段階的な修正手順
  • 作業量の見積もり（簡単な修正／中程度／大規模）
中リスクの検出事項（修正推奨）

上記と同じ形式で、リスク順に優先順位を付けます。

低リスクおよび情報提供の検出事項（追跡）

技術的負債として追跡するための一覧をまとめます。

脅威モデルの概要
  • STRIDE 分析結果の表
  • 攻撃ツリー上位3件（図または構造化されたテキスト）
  • 防御ギャップ分析
推奨アクション（優先順位順）
  1. 直ちに対応（重大）：次回のデプロイ前に必ず修正
  2. 今スプリント中（高）：現在の作業サイクル内に修正
  3. 次スプリント（中）：今後の作業に予定
  4. バックログ（低）：技術的負債として追跡
チェックポイント：監査レポート全体をユーザーに提示します。今すぐ修正する検出事項と、後で対応するために追跡する検出事項を確認します。

ステップ 8：修正（任意）

ユーザーが今すぐ指摘事項を修正することを選択した場合：

  1. 優先度の高い順（Critical、次に High）に指摘事項に対処します
  2. 修正ごとに、次のことを行います。
    • 修正を適用します
    • 関連する SAST スキャンを再実行し、修正を検証します
    • テストを実行し、リグレッションがないことを確認します
  3. 各修正を次の内容でコミットします。 
    fix(security): remediate <finding-description>

修正後、次のステップを提案します（以下を参照）。

ステップ 9：追跡対象の指摘事項の Issue を作成する

後で対応するためにユーザーが追跡することを選択した指摘事項（ステップ 8 ですぐに修正しないもの）については、GitHub Issue を作成し、見失わないようにします。

チェックポイント：続行する前に、Issue を作成する指摘事項の概要テーブルを提示します。
#指摘事項重大度推定規模build-ready ラベル？
1<description>MediumSはい

どの指摘事項を Issue にするか、ユーザーに確認します。承認されるまで作成しないでください。

メモ

明確で範囲が限定された修正（修正方法が分かっており、アーキテクチャ上の判断を必要としないもの）がある指摘事項には、build-ready ラベルを追加します。スキーマの変更、新しいインフラストラクチャ、横断的なアーキテクチャ上の判断が必要な指摘事項など、/plan-feature による追加計画が必要なものには、build-ready を付けません。

  1. 承認された指摘事項ごとに、GitHub Issue を作成します。

    ISSUE_URL=$(gh issue create \
  --title "security: <finding-description>" \
  --body "<body>" \
  --label "enhancement" \
  --label "security-audit" \
  --label "build-ready")

ISSUE_NUM=$(echo "$ISSUE_URL" | grep -o '[0-9]*$')

    追加の計画が必要な指摘事項には、--label "build-ready" を省略します（上記の注記を参照）。

    Issue の本文には、次の内容を含めます。

    • Context：この指摘事項を特定した監査と監査日
    • Problem：ファイルパスと行番号を含む説明
    • Recommended Fix：監査レポートに記載された、手順ごとの修正方法
    • Priority：重大度の評価と推奨される対応時期
    • Files：影響を受けるファイルパス

  2. 作成した各 Issue をプロジェクトボードに追加し、フィールドを設定します。

    ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "$ISSUE_URL" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {SIZE_FIELD_ID} --single-select-option-id <size-option-id>
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {START_FIELD_ID} --date <start-date>
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {TARGET_FIELD_ID} --date <target-date>

    指摘事項の優先度と現在のマイルストーンに合わせて、フェーズ、規模、日付を設定します。

    重大度一般的な規模スケジュール上の優先度
    Critical/HighM（3 日）または L（5 日）現在進行中のマイルストーン。キューの前方に配置
    MediumS（2 日）現在のマイルストーン。既存の予定項目の後に配置
    Low/InfoXS（1 日）現在または次のマイルストーン。キューの末尾に配置

  3. 作成したすべての Issue 番号（$ISSUE_NUM）と URL をユーザーに報告します。

重要

追跡対象の指摘事項は、すべて GitHub Issue とプロジェクトボードのエントリーの両方が必要です。Issue を作成してもプロジェクトボードに追加しないと、/build-feature が自動選択で見つけられない作業項目が取り残される原因になります。

ステップ 10：追跡用 Issue をクローズする（条件付き）

ユーザーが引数として GitHub Issue 番号を指定した場合（例：/security-audit #137）：

  1. gh issue edit を使用して、Issue 本文の監査チェックリスト項目にチェックを入れます
  2. チェックポイント：監査が完了したため Issue をクローズするか、ユーザーに確認します。確認のため Issue 番号とタイトルを提示します。
  3. 承認された場合、Issue をクローズします。 
    gh issue close <number> --reason completed

Issue 番号が指定されていない場合、このステップは省略します。

ステップ 11：引き継ぎ

次のステップをユーザーに提示します。

  • コードを変更した場合（修正を適用した場合）：/review-code を実行し、他の変更との関連も含めて修正を検証します
  • コードを変更していない場合（監査のみ）：追加の対応は不要です。指摘事項は Issue または技術的負債として追跡します
  • 新しい機能を開始する場合：監査の指摘事項を考慮して次の機能を開始するため、/plan-feature を実行します

パイプライン：/plan-feature → /build-feature または /build-api → /review-code → /submit-pr

単独実行：/security-audit はパイプラインの任意の時点で、または単独で実行できます。

コメント

Markdown 対応