ワンクリックでManusで任意のスキルを実行

始める

sec-diff-review

スター2

フォーク0

更新日2026年5月19日 02:27

PR・ブランチの変更差分（git diff）を静的解析してセキュリティ脆弱性を検出する。開発中・PRレビュー時に使用。手動呼び出し専用: /sec-diff-review

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

studiogadget

studiogadget/skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

sec-diff-review

役割: 差分ベース静的解析スキル（PR単位・開発中に使用）

このスキルは git diff で変更されたファイルのみを対象とする。全ファイルの静的解析は /sec-full-scan が担当する。

スコープの誠実な開示: このスキルは変更差分のみを検査するため、既存コードに潜む脆弱性は検出しない。全ファイルを対象にしたい場合は /sec-full-scan を使用すること。

引数

引数	必須	説明
`コメント`	任意	レビューの文脈や注目してほしい点

前提条件

git リポジトリ内で実行すること
サーバーの起動は不要（静的解析のみ）

手順

Step 1: 変更差分の収集

デフォルトブランチを git symbolic-ref refs/remotes/origin/HEAD で検出する。失敗した場合は main → master → develop の順にフォールバックする。確定後 git diff {default}...HEAD で変更ファイル一覧と差分を取得する
変更ファイル数・追加行数を報告する
スコープを明示する: 「このレビューは X ファイルの変更差分のみを対象とします」と伝える

Step 2: リポジトリコンテキストの調査（Phase 1）

変更ファイルを分析する前に、既存の安全なパターンを把握する：

既存の認証・認可ミドルウェアの実装を確認する
既存の入力バリデーション・サニタイズパターンを確認する
プロジェクトの認証モデルを把握する（ミドルウェア認証・リバースプロキシ認証・アプリ内認証など）
変更ファイルが触れているドメイン（API ルート・データアクセス層・認証等）を特定する

Step 3: 差分の比較分析（Phase 2）

変更されたコードを既存の安全なパターンと比較する：

新しいコードが既存のセキュリティパターンから逸脱していないか確認する
新たな攻撃面（新しい API エンドポイント・外部入力受付箇所）を特定する
既存の認可チェックをバイパスするコードが追加されていないか確認する

Step 4: 脆弱性アセスメント（Phase 3）

各変更ファイルについて、以下カテゴリで脆弱性を検査する。

検出対象（>80% の信頼度があるもののみ報告）:

インジェクション: SQL / NoSQL / コマンド / テンプレートインジェクション、パストラバーサル
認証・認可: 認証バイパス、認可不備、セッション管理の欠陥、JWT の誤実装
暗号・シークレット: ハードコードされた認証情報・APIキー、弱い暗号アルゴリズム
XSS: dangerouslySetInnerHTML / bypassSecurityTrustHtml 等の危険なメソッドのみ
データ露出: PII・パスワード・トークンのログ出力、センシティブデータの意図しない返却

除外ルール（報告しない）:

DoS・リソース枯渇・レート制限
React / Angular の通常コンポーネントでの XSS（dangerouslySetInnerHTML 不使用の場合）
クライアントサイドの認証チェック欠如（バックエンドが責任を持つ）
AIシステムプロンプトへのユーザー入力混入
環境変数・CLI フラグを経由した攻撃（信頼済みとして扱う）
ドキュメントファイル（Markdown）
既存の依存関係の既知 CVE（/sec-full-scan が担当）
ログスプーフィング
パスのみ制御できる SSRF（ホスト・プロトコルを制御できる場合のみ報告）
UUID はランダムで推測不能と仮定

Step 5: 偽陽性フィルタリング

信頼度 8 以上の発見のみ報告する。各発見について確認する：

具体的な攻撃経路が存在するか（理論上ではなく実際に悪用可能か）
実際のセキュリティリスクか（ベストプラクティスの欠如ではないか）
具体的なコード箇所と再現手順があるか

Step 6: レポート保存・履歴インデックス更新

日付付きファイル名でレポートを保存する
- 保存先: ./security-reports/YYYY-MM-DD-security-review.md
- 日付は実行時の ISO 8601 形式（例: 2026-05-01）
- ディレクトリが存在しない場合は作成する
./security-reports/index.md に1行追記する
- ファイルが存在しない場合はヘッダーから作成する
- 追記フォーマット:
```
| YYYY-MM-DD | sec-diff-review | <ブランチ名> | <変更ファイル数>ファイル | 0 | <High件数> | <Medium件数> | <CI結果> | [レポート](YYYY-MM-DD-security-review.md) |
```
- CI結果: High 以上の発見が 0 件なら ✅ pass、1件以上なら ❌ fail

出力フォーマット

# セキュリティレビュー結果

**スコープ**: <変更ファイル数> ファイルの差分のみ（全ファイル解析は /sec-full-scan を使用）
**対象ブランチ**: <ブランチ名>

## Vuln N: <脆弱性種別>: `<ファイルパス>:<行番号>`

* Severity: High / Medium
* Confidence: <0.8〜1.0>
* Description: <具体的な問題の説明>
* Exploit Scenario: <攻撃シナリオ>
* Recommendation: <修正方法>

深刻度基準:

High: 直接悪用可能な RCE・データ漏洩・認証バイパス
Medium: 特定条件下で重大な影響をもたらす脆弱性

このスキルでカバーできない領域

領域	推奨手段
変更差分以外の既存コードの脆弱性	`/sec-full-scan`
依存関係の既知 CVE	`/sec-full-scan`
デプロイ後のランタイム挙動	`/sec-runtime-scan`
ビジネスロジックの欠陥（仕様知識が必要）	ペネトレーションテスト
インフラ・クラウド設定	インフラ担当者レビュー

完了条件

変更ファイルのスコープが明示されている
信頼度 0.8 以上の発見のみ報告されている
各発見に具体的な攻撃シナリオと修正方法が含まれている
カバーできない領域が明示されている
./security-reports/YYYY-MM-DD-security-review.md が保存されている
./security-reports/index.md に1行追記されている

このリポジトリの他の Skills

同じリポジトリ

cc-sdd-review-slice-stack

studiogadget/skills

cc-sdd実装用統合ブランチのコミット群（ベースブランチとの差分）をreview slice単位のstacked PRに再構成する際に使用。「review sliceに分割」「stacked PRを作成」「PRをスタックして」「レビュー用にPRを分けて」「review slice stack」という依頼でトリガーする。dry-run（既定）でslice計画を提示し、apply指示で実際にブランチ・PRを作成する。

2026-05-252

cc-sdd-restack-after-merge

studiogadget/skills

stacked PRの下位PRがマージされた後に上位branchをrestack（rebase/cherry-pick再構成）する際に使用。「restackして」「上位PRを更新して」「restack after merge」「PRのbaseを更新」「スタックを整理」という依頼でトリガーする。対象sliceの特定→rebase→変更ファイル確認と代表テスト実行→force-with-leaseでpush→PR base更新→auto-merge判定の順で進める。

2026-05-222

sec-full-scan

studiogadget/skills

リリース前の全ファイル静的解析スキル。プロジェクト構造を自動検出し、ソースモジュールごとのサブエージェントと依存関係スキャンを並列実行してコードベース全体の脆弱性を検出する。手動呼び出し専用: /sec-full-scan

2026-05-192

sec-runtime-scan

studiogadget/skills

ステージング環境にデプロイ済みのサーバーに対してランタイム検証を実行する。HTTPヘッダー・動的プローブ・認証テストに特化。手動呼び出し専用: /sec-runtime-scan [環境名]

2026-05-192

resolve-pr-review-threads

studiogadget/skills

PRの未Resolveレビュー指摘に対応するスキル。「PRの指摘に対応して」「Resolveされていないスレッドを解消」「PR reviewの対応」「未解決のレビューコメントを修正」「Copilotの指摘を直して」「Codexの指摘に対応」「chatgpt-codex-connectorの指摘」「レビュー対応」で起動。PR URL or 番号 → 未Resolveスレッド取得 → 対象ファイル修正 → ユーザーへ最終ゲートとプッシュの実行手順を案内、の流れで進める。

2026-05-162

hibernate-pc

studiogadget/skills

タスク完了後にPCを休止状態にする。Use when: ユーザーが「休止」「hibernate」「タスク完了後に休止状態」「作業後にPCをスリープ/休止」と明示的に指示した場合のみ。正常終了時だけでなく、エラーや未解決事項が残っていても、明示指示があれば最後に休止へ移行する。Windows only.

2026-05-042

name	sec-diff-review
description	PR・ブランチの変更差分（git diff）を静的解析してセキュリティ脆弱性を検出する。開発中・PRレビュー時に使用。手動呼び出し専用: /sec-diff-review
license	MIT (see LICENSE.txt)
disable-model-invocation	true

sec-diff-review

役割: 差分ベース静的解析スキル（PR単位・開発中に使用）

このスキルは git diff で変更されたファイルのみを対象とする。全ファイルの静的解析は /sec-full-scan が担当する。

スコープの誠実な開示: このスキルは変更差分のみを検査するため、既存コードに潜む脆弱性は検出しない。全ファイルを対象にしたい場合は /sec-full-scan を使用すること。

引数

引数	必須	説明
`コメント`	任意	レビューの文脈や注目してほしい点

前提条件

git リポジトリ内で実行すること
サーバーの起動は不要（静的解析のみ）

手順

Step 1: 変更差分の収集

デフォルトブランチを git symbolic-ref refs/remotes/origin/HEAD で検出する。失敗した場合は main → master → develop の順にフォールバックする。確定後 git diff {default}...HEAD で変更ファイル一覧と差分を取得する
変更ファイル数・追加行数を報告する
スコープを明示する: 「このレビューは X ファイルの変更差分のみを対象とします」と伝える

Step 2: リポジトリコンテキストの調査（Phase 1）

変更ファイルを分析する前に、既存の安全なパターンを把握する：

既存の認証・認可ミドルウェアの実装を確認する
既存の入力バリデーション・サニタイズパターンを確認する
プロジェクトの認証モデルを把握する（ミドルウェア認証・リバースプロキシ認証・アプリ内認証など）
変更ファイルが触れているドメイン（API ルート・データアクセス層・認証等）を特定する

Step 3: 差分の比較分析（Phase 2）

変更されたコードを既存の安全なパターンと比較する：

新しいコードが既存のセキュリティパターンから逸脱していないか確認する
新たな攻撃面（新しい API エンドポイント・外部入力受付箇所）を特定する
既存の認可チェックをバイパスするコードが追加されていないか確認する

Step 4: 脆弱性アセスメント（Phase 3）

各変更ファイルについて、以下カテゴリで脆弱性を検査する。

検出対象（>80% の信頼度があるもののみ報告）:

インジェクション: SQL / NoSQL / コマンド / テンプレートインジェクション、パストラバーサル
認証・認可: 認証バイパス、認可不備、セッション管理の欠陥、JWT の誤実装
暗号・シークレット: ハードコードされた認証情報・APIキー、弱い暗号アルゴリズム
XSS: dangerouslySetInnerHTML / bypassSecurityTrustHtml 等の危険なメソッドのみ
データ露出: PII・パスワード・トークンのログ出力、センシティブデータの意図しない返却

除外ルール（報告しない）:

DoS・リソース枯渇・レート制限
React / Angular の通常コンポーネントでの XSS（dangerouslySetInnerHTML 不使用の場合）
クライアントサイドの認証チェック欠如（バックエンドが責任を持つ）
AIシステムプロンプトへのユーザー入力混入
環境変数・CLI フラグを経由した攻撃（信頼済みとして扱う）
ドキュメントファイル（Markdown）
既存の依存関係の既知 CVE（/sec-full-scan が担当）
ログスプーフィング
パスのみ制御できる SSRF（ホスト・プロトコルを制御できる場合のみ報告）
UUID はランダムで推測不能と仮定

Step 5: 偽陽性フィルタリング

信頼度 8 以上の発見のみ報告する。各発見について確認する：

具体的な攻撃経路が存在するか（理論上ではなく実際に悪用可能か）
実際のセキュリティリスクか（ベストプラクティスの欠如ではないか）
具体的なコード箇所と再現手順があるか

Step 6: レポート保存・履歴インデックス更新

日付付きファイル名でレポートを保存する
- 保存先: ./security-reports/YYYY-MM-DD-security-review.md
- 日付は実行時の ISO 8601 形式（例: 2026-05-01）
- ディレクトリが存在しない場合は作成する
./security-reports/index.md に1行追記する
- ファイルが存在しない場合はヘッダーから作成する
- 追記フォーマット:
```
| YYYY-MM-DD | sec-diff-review | <ブランチ名> | <変更ファイル数>ファイル | 0 | <High件数> | <Medium件数> | <CI結果> | [レポート](YYYY-MM-DD-security-review.md) |
```
- CI結果: High 以上の発見が 0 件なら ✅ pass、1件以上なら ❌ fail

出力フォーマット

# セキュリティレビュー結果

**スコープ**: <変更ファイル数> ファイルの差分のみ（全ファイル解析は /sec-full-scan を使用）
**対象ブランチ**: <ブランチ名>

## Vuln N: <脆弱性種別>: `<ファイルパス>:<行番号>`

* Severity: High / Medium
* Confidence: <0.8〜1.0>
* Description: <具体的な問題の説明>
* Exploit Scenario: <攻撃シナリオ>
* Recommendation: <修正方法>

深刻度基準:

High: 直接悪用可能な RCE・データ漏洩・認証バイパス
Medium: 特定条件下で重大な影響をもたらす脆弱性

このスキルでカバーできない領域

領域	推奨手段
変更差分以外の既存コードの脆弱性	`/sec-full-scan`
依存関係の既知 CVE	`/sec-full-scan`
デプロイ後のランタイム挙動	`/sec-runtime-scan`
ビジネスロジックの欠陥（仕様知識が必要）	ペネトレーションテスト
インフラ・クラウド設定	インフラ担当者レビュー

完了条件

変更ファイルのスコープが明示されている
信頼度 0.8 以上の発見のみ報告されている
各発見に具体的な攻撃シナリオと修正方法が含まれている
カバーできない領域が明示されている
./security-reports/YYYY-MM-DD-security-review.md が保存されている
./security-reports/index.md に1行追記されている