mcpField
F
find-bugs

find-bugs

github.com/sickn33テスト・品質48.7k285 回インストール今日更新
リポジトリ

find-bugs について

現在のブランチ差分からバグ、セキュリティ上の問題、リスクの高い変更を調べるコードレビュー用スキルです。コミット参照の検証、変更ファイル全体の確認、チェックリストによる検証を求め、具体的な根拠とともに報告します。

主な機能

  1. 01検証済みの基点から先端までの差分を確認
  2. 02入力・データアクセス・攻撃面を整理
  3. 03変更ファイルのセキュリティリスクを点検
  4. 04文脈とテストで懸念点を検証
  5. 05根拠を添えて優先度順に報告

活用シーン

  1. 01マージ前のブランチ監査
  2. 02変更コードの脆弱性確認
  3. 03差分に含まれる回帰の調査
  4. 04レビュー結果のみの報告書作成

インストール

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

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill find-bugs

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

詳細

バグを見つける

このブランチの変更をレビューし、バグ、セキュリティ脆弱性、コード品質の問題を確認します。

使用する場面

  • バグ、セキュリティ問題、リスクの高いコード変更に焦点を当てたレビューが必要な場合。
  • 新しい動作を実装するのではなく、現在のブランチの差分を監査する場合。
  • 変更されたファイルを対象に、チェックリストに基づいて検証する構造化されたレビュー手順が必要な場合。

フェーズ 1:入力情報をすべて収集する

  1. 指定されたベースとヘッドを、検証済みのコミット SHA として確定します。必要に応じてリモート/デフォルトブランチを確認し、古いローカルブランチが最新だと思い込まないでください。検証済みの参照を個別に引用符で囲んだ引数として使用し、git diff "$BASE_SHA...$HEAD_SHA" -- でブランチの差分全体を読みます。対象範囲に含まれる場合は、ステージ済みおよび未ステージの変更も含めます。チェックアウト状態は維持してください。
  2. 出力が途中で切れた場合は、変更された各ファイルを個別に読み、変更されたすべての行を確認します。
  3. 続行する前に、このブランチで変更されたすべてのファイルを一覧表示します。

フェーズ 2:攻撃対象領域をマッピングする

変更された各ファイルについて、以下を特定して一覧表示します。

  • すべてのユーザー入力(リクエストパラメーター、ヘッダー、本文、URL の構成要素)
  • すべてのデータベースクエリ
  • すべての認証/認可チェック
  • すべてのセッション/状態操作
  • すべての外部呼び出し
  • すべての暗号処理

フェーズ 3:セキュリティチェックリスト(各ファイルについて全項目を確認)

  • インジェクション:SQL、コマンド、テンプレート、ヘッダーへのインジェクション
  • XSS:テンプレート内のすべての出力が適切にエスケープされているか?
  • 認証:保護対象のすべての操作に認証チェックがあるか?
  • 認可/IDOR:認証だけでなく、アクセス制御も検証されているか?
  • CSRF:状態を変更する操作が保護されているか?
  • 競合状態:読み取り後に書き込む処理に TOCTOU がないか?
  • セッション:セッション固定、期限切れ、セキュアフラグに問題がないか?
  • 暗号処理:安全な乱数が使われているか、適切なアルゴリズムか、ログにシークレットが含まれていないか?
  • 情報漏えい:エラーメッセージ、ログ、タイミング攻撃
  • DoS:上限のない処理、レート制限の欠如、リソース枯渇
  • ビジネスロジック:エッジケース、状態遷移の違反、数値オーバーフロー

フェーズ 4:検証

潜在的な問題ごとに、以下を確認します。

  • 変更されたコード内の別の箇所ですでに対処されているか
  • 該当するシナリオを網羅する既存のテストがあるか
  • 問題が実際に存在するかを確かめるため、周辺のコンテキストを読む

フェーズ 5:結論前の監査

最終化する前に、必ず以下を行います。

  1. レビューしたすべてのファイルを一覧表示し、完全に読んだことを確認します。
  2. 該当するチェックリスト項目をすべて、レビュー対象範囲内で「問題として確認済み」「該当なし」「未検証」のいずれかとして列挙します。問題が見つからないことは、安全性の証明にはなりません。
  3. 十分に検証できなかった領域とその理由を列挙します。
  4. その後にのみ、最終的な指摘を提示します。

出力形式

優先順位:セキュリティ脆弱性 > バグ > コード品質

対象外:スタイルや書式の問題

各問題について:

  • ファイル:行 - 簡潔な説明
  • 重大度:Critical/High/Medium/Low
  • 問題:何が問題か
  • 根拠:具体的な発生条件、到達可能な経路、確認された影響または推論される影響。テストがないことだけではバグの証明になりません。
  • 修正案:具体的な提案
  • 参考資料:該当する場合は OWASP、RFC、その他の標準

重大な問題が見つからなかった場合は、その旨を伝えます。問題をでっち上げてはいけません。

レビューのみの依頼では、コードを変更せずに指摘事項を報告します。レビューと修正を明示的に組み合わせた依頼では、対象範囲内の修正と検証が許可されます。指摘事項と完了した修正は区別してください。

例

ユーザーの依頼:

現在のブランチの差分を確認し、実際のバグ、セキュリティ問題、リグレッションを、正確なファイル名と行番号を挙げて報告してください。

制限事項

  • このスキルは、説明されている範囲に明確に該当する場合にのみ使用してください。
  • この出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。

コメント