Skip to content
cccskills
FreePublished on GitHub

sec-diff-review

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

The English summary is being prepared. Showing the original description.

See how to install

Files included (3)

  • SKILL.md6.8 KB
  • LICENSE.txt1.0 KB
  • NOTICE.md685 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

sec-diff-review

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

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

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


引数

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

前提条件

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

手順

Step 1: 変更差分の収集

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

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

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

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

Step 3: 差分の比較分析(Phase 2)

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

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

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 以上の発見のみ報告する。各発見について確認する:

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

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

  1. 日付付きファイル名でレポートを保存する

    • 保存先: ./security-reports/YYYY-MM-DD-security-review.md
    • 日付は実行時の ISO 8601 形式(例: 2026-05-01)
    • ディレクトリが存在しない場合は作成する
  2. ./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行追記されている

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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判定の順で進める。

The English summary is being prepared. Showing the original description.

studiogadget/skills3Updated May 25, 2026

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

The English summary is being prepared. Showing the original description.

studiogadget/skills3Updated May 25, 2026

CI環境で安定動作するPythonテスト(特にstructlogのログ検証)を書く際に使用。「CIで失敗する」「capture_logsが不安定」「ログアサーションがCIだけ落ちる」「caplogフォールバック」「ANSI混入」「xdistでログが取れない」という課題で起動。capture_logs→caplogフォールバック→ANSI正規化→アサーション設計の流れで堅牢なテストを書く。

The English summary is being prepared. Showing the original description.

studiogadget/skills3Updated May 25, 2026

GitHub Issueを作成してGitHubに投稿するスキル。「Issueを作成」「Issue作成」「Issueにして」「Issueとして投稿」「GitHubにIssue」「create issue」「open issue」「バグ報告」「機能追加をIssueに」「改善提案をIssueに」などの依頼でトリガーする。コンテキスト収集→Issue本文生成→ラベル存在確認・作成→gh issue create投稿の流れでIssueを作成する。

The English summary is being prepared. Showing the original description.

studiogadget/skills3Updated May 25, 2026

Dockerベースのアプリケーションのデプロイメント手順書(Markdown)を作成するスキル。「デプロイ手順書」「デプロイメント手順」「deployment guide」「本番環境への配置手順」「サーバーへの配置手順」などの依頼でトリガーする。Docker Composeビルド→イメージ転送→サーバー配置→設定→動作確認→cron設定の流れで手順書を生成する。

The English summary is being prepared. Showing the original description.

studiogadget/skills3Updated May 25, 2026

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

The English summary is being prepared. Showing the original description.

studiogadget/skills3Updated May 25, 2026

See all skills by studiogadget

Report a problem with this skill