ディープスキャンとPR単位のセキュリティレビュー:いつ、どちらを使うべきか

PR単位のセキュリティレビューは、差分と関連するコードベースの情報を使ってマージ前の変更を確認する一方、ディープスキャンは現在の変更に限定せず、コミット済みのコードベースを調べます。PRレビューは作成者がまだ修正できる段階でリスクを見つけ、ディープスキャンは以前から存在するコードや、複数の変更にまたがる脆弱性を調査します。

対象には重なりがありますが、答える問いは異なります。PRレビューは変更がどのようなセキュリティリスクを持ち込むかを問い、ディープスキャンはコードベースにすでにどのような脆弱性が存在するかを問います。新しい変更をレビューし、リポジトリ内の既存コードを再評価するには、両方が必要です。

ディープスキャンとPR単位のセキュリティレビューの違い

それぞれが確認する対象

タイミングが違うと対応も変わる

PRには作成者と明示された目的があり、変更を受け入れるか判断する時点があります。一方、リポジトリのスキャンでは、すでにマージされたコードを広く確認できます。どちらのタイミングも完全な網羅を保証しないため、運用上の問いは、ワークフローによって検出結果の担当者が決まり、修正がレビューされるかどうかです。

PRセキュリティレビューで見つかるものと見逃すもの

マージ前にリスクを見つける

変更単位のレビューでは、対応しやすい段階で指摘を受けられます。作成者はまだ変更内容を把握しており、チームはコードを受け入れる前に問題へ対処できます。

注文を取得するエンドポイントを追加するPRを考えてみてください。認証は、呼び出し元がログイン済みであることを確認しますが、レビューでは、その呼び出し元が要求した注文にアクセスできるかも確認する必要があります。任意の注文IDを受け付けるルートに所有者の確認がなければ、ログイン済みのユーザーが他人の注文を取得できるおそれがあります。

PRに記載された目的は、その動作を判断する手がかりになります。顧客向けの注文取得エンドポイントと管理者向けのエンドポイントでは、データベースのクエリが似ていても、必要な権限が異なります。

GitHub CloudとGitHub Enterprise Serverでは、任意のCodeRabbit Securityチェックは初期状態で無効です。リポジトリのSecurity設定でPublish CodeRabbit Security checkを有効にし、デフォルトがCriticalのBlock onを、チェックを失敗させる最低の重大度に設定します。マージを止めるには、ブランチ保護またはルールセットでもこのチェックを必須にしてください。公開しただけではマージルールは変わりません。このチェックはPRのSecurityコメントを評価し、Deep Scanの検出結果とは分かれています。

既存コードと複数の変更にまたがるリスクに対応する

PRレビューは、導入前にマージされたコードをすべて体系的に再評価するわけではありません。変更に関係する既存の脆弱性を見つけることはできますが、無関係な古いコードは確認対象に入らない場合があります。

リスクは複数のPRにまたがって積み重なります。たとえば、ある変更で、呼び出し元が権限を確認する前提のヘルパーを追加し、後の変更で、ヘルパーが権限を確認する前提のルートからそれを再利用します。両方のレビューでこの食い違いを見逃すと、どこでも権限が確認されません。

CodeRabbitのSecurity Blast Radiusは変更行の外にあるつながりを可視化し、Security Architecture Reviewは変更されたコンポーネントや信頼境界にまたがるセキュリティへの影響を調べます。どちらもPRの調査に役立ち、リポジトリのスキャンでは、別の機会にコミット済みコードを再評価できます。

ディープスキャンで見つかるものと見逃すもの

コミット済みコード全体の脆弱性を調べる

ディープスキャンは、どれほど古いコードでも調べるため、引き継いだリポジトリや複数の変更にまたがる攻撃経路を調査できます。

Rohit KhannaはIntroducing CodeRabbit Securityで、「アプリケーションの他の部分との相互作用を確認して初めて、リスクが明らかになる」と述べています（原文からの訳）。注文取得エンドポイントの例では、ルートから認可ロジック、データベースの検索までをたどり、どこかの層で所有者を確認しているか調べることになります。

攻撃者も、こうしたつながりを調査できます。Khannaの記事は、ある一つのサイバースパイ活動で作業の80%から90%をAIが実行したとする、Anthropicの2025年11月の報告を引用しています。攻撃者が攻撃のそれほど多くの部分をAIに任せられるなら、チームは新しい変更をレビューするだけでなく、既存コードも再確認する必要があります。

CodeRabbitのDeep Scanは、ルールベースのシグナルとAIによる推論を組み合わせ、疑わしい経路を調査して候補をリポジトリの証拠と照合します。対応プラットフォームでは、選択したリンク先リポジトリから共有認証ライブラリなどの情報を参照できますが、リンク先自体の検出結果とカバレッジを得るには、別のスキャンが必要です。

カバレッジを確認し、依存関係の監視を続ける

結果とあわせて、カバレッジと証拠を確認してください。完了したスキャンでも、除外設定や分析上限によりカバレッジが部分的になることがあります。スキャンはある時点の状態を反映するため、その後の変更には新たな分析が必要です。

新しい攻撃手法によって、以前は理論上だけだった経路が実際に悪用可能になることがあり、新たに公開された依存関係の脆弱性は、変更のないコードにも影響します。Deep Scanはソフトウェアコンポジション解析を行わないため、依存関係の監視をワークフローに残してください。

現在の静的解析ツールも、対応する言語、フレームワーク、モデルの範囲内でデータフローを追跡します。アプリケーション固有の権限や業務ルールの確認には、追加の情報が必要な場合があります。SASTとSCAの比較ガイドでは、静的解析と依存関係スキャンの組み合わせを説明しています。

PRレビュー、フルスキャン、差分スキャンを使うタイミング

すべてのPRをレビューし、ベースラインを作る

作成者が変更内容を把握しているうちに、各PRをマージ前にレビューしてください。このプロセスを導入する際には既存コードも対象にするためディープスキャンを実行し、買収、ベンダー提供、移行によってコードを環境に取り込む際にもスキャンしてください。

証拠、影響を受けるデータ、攻撃者に必要なアクセスに基づいて検出結果の優先順位を決めます。担当者を決め、修正をPRにします。修正のレビューでは、攻撃経路を閉じたか、期待する動作を維持しているかを確認できます。

リポジトリの変更に合わせて再スキャンする

リポジトリの変化に合わせて再スキャンしてください。CodeRabbitはGitHubでの定期フルスキャンに対応しています。差分スキャンは、フルスキャンの間に、変更ファイルと、古くなった、または未検証のマッピング済みポイントを再確認します。

CodeRabbitの差分スキャンの公開ドキュメントでは、過去30日以内にリポジトリ全体のフルDeep Scanを実行していることが必要で、部分スキャンや特定ディレクトリだけのスキャンは対象外です。リポジトリに攻撃対象領域のマップがある場合、検証済みカバレッジは15%以上でなければなりません。差分スキャンを引き続き利用するには、少なくとも30日ごとにフルDeep Scanを実行し、自動化を設定する前に、課金を含む差分スキャンの要件を確認してください。

GitHubの差分スキャンの自動化は、デフォルトブランチへのマージ後に、設定したコミット数、日数、カバレッジの条件を確認します。日数の条件を設定しても、マージがなければスキャンは始まりません。差分スキャンの自動化を有効にすると既存のフルスキャン予定が置き換わるため、フルスキャンのベースラインを更新する方法も決めてください。

CodeRabbitで検出結果を修正につなげる

変更をレビューし、対応する検出結果を修正する

CodeRabbit Secureは、継続的なPRセキュリティレビューとDeep Scanに対応しています。対応する検出結果では、Fix with AIがPRまたはマージリクエストを作成し、チームがレビューしてからマージします。

その後のスキャンをガイドするために、アーキテクチャの情報、パスごとの指示、PRレビューのLearningsとは別のSecurity Learningsを提供してください。スキャンのガイドのページでは、利用できる設定を説明しています。

検出と、その後の対応を分けて評価する

CodeRabbitのベンチマークの方法では、オープンソースリポジトリの既知の脆弱性に対して検出をどう評価するかを説明していますが、検出結果だけでは修正の品質は判断できません。

変更後の対応には、ドキュメントの更新や、マージ後に残るその他の作業も含まれます。Post-Merge Actionsは、PRのマージ後にPRの情報を使い、変更履歴の更新やチケット関連の作業など、設定済みの後続タスクを実行します。スキャンのスケジュール設定とは目的が異なります。

無料トライアルを開始して新しい変更をレビューし、その後、既存コードにDeep Scanを実行してください。Deep Scanは別途従量課金の対象です。無料利用枠が適用されない場合は、従量課金を有効にする必要があります。

よくある質問

PRセキュリティレビューは既存の脆弱性も対象にするか

PRセキュリティレビューは、提案された変更に関係する既存の脆弱性を見つけることはできますが、それ以前にマージされたコードを体系的に再評価するわけではありません。リポジトリ全体のスキャンで古いコードや複数の変更間で見逃した相互作用を調べ、新たに公開される脆弱性に備えて依存関係の監視も続けてください。

CodeRabbitは疑わしい脆弱性をどう検証するか

CodeRabbitは検出結果を報告する前に、到達可能性、保護策、悪用に必要な条件をリポジトリの証拠で確認します。検証によって根拠のない指摘を減らしますが、すべての指摘がデプロイ済み環境で悪用可能であることや、すべての脆弱性を検出したことは保証しません。