テストは通り、依存関係はパッチ済みで、すべてのプルリクエストでスキャンが走っている。それでも、アプリケーション固有の脆弱性が検出されないまま、サービスが何年も稼働し続けることがあります。コードを関数ごとに読んでいっても、危険に見える箇所はどこにもありません。その脆弱性が姿を現すのは、開発者がワークフロー全体をたどり、その途中でコードが何を前提にしているのかを問うたときだけです。
攻撃者も同じ問いを立てられます。しかも、答えを出すためにコードベースを知っている必要はもうありません。AI は見知らぬコードを読み、ワークフローの各経路をたどり、作者が置いた前提を、どんなレビュアーのチームよりも速く突いていきます。何年も手つかずで動いてきたコードは、いまやモデルを向けさえすれば誰の手にも届く範囲にあります。
だからこそ私たちは、CodeRabbit Secure に Deep Scan を作りました。Deep Scan はコミット済みのコードを調査し、検出した内容を独立して検証し、何を変更するかを判断する前に開発者が確認できる証拠を提示します。
攻撃者は強化された
アプリケーションセキュリティは昔から、システムの調査にどれだけの時間と専門知識を注げるかに部分的に依存してきました。見知らぬコードをまたいでリクエストを追跡するには労力がかかります。欠けている防御策を特定し、周囲のアプリケーションによってそれが悪用可能になるかどうかを見極めるのも同様です。
いまでは、その作業の大半を AI がこなせます。Anthropic は 2025 年 11 月、AI が主導したスパイ活動に関するレポートを公開しました。この作戦では戦術的な作業の 80% から 90% を AI が実行し、人間のオペレーターが介入したのはごく少数の判断ポイントだけでした。攻撃者は約 30 の組織を標的にし、そのうち少数への侵入に成功しました。
攻撃者のために脆弱性を見つける AI は、あなたのチームのために先にそれを見つけることもできます。元の作者がとうに去ったサービスを見直し、コードが築かれた前提をたどり、他の誰かがたどり着く前に欠けている制御を追加できるのです。エージェント型 SDLC では、古いコードの所有権をセキュリティチームだけに負わせることはできません。エンジニアリングもそれを分かち合います。
欠陥がアプリケーションロジックにあるとき
既存のスキャナーは有用な仕事をしています。
- 静的解析は関数をまたいでデータを追跡し、安全でないフローを特定できます
- 依存関係ツールは既知の脆弱なパッケージを特定します
- シークレットスキャナーは露出した認証情報を探します
これらの役割を担うツールは、そのまま使い続けてください。Deep Scan は、既知のルール、脆弱なパッケージ、露出したシークレットのいずれにも一致しない可能性のあるアプリケーション固有の欠陥に対して、独立した推論レイヤーを追加します。
特定の認可パターンに対してルールを書くことはできます。成熟した解析ツールはフレームワークをモデル化し、複雑なフローを追跡することもできます。難しいのは、アプリケーション固有の義務をすべて事前に表現しきることです。ワークフローがその義務を複数のコンポーネントに分散させている場合はなおさらです。
Deep Scan のセマンティック解析は、アプリケーションが本来何を強制すべきかを割り出し、その仮説を裏付ける、あるいは否定する証拠を実装の中に探します。
Deep Scan は証拠を集めるだけでは終わりません。その制御が本当に欠けているのか、そしてそれがなければ攻撃者に何ができるのかを確認します。
1 つの脆弱性をアプリケーション全体で追う
次のような、単純化した説明用の返金ワークフローを考えてみましょう。ルートはすでに呼び出し元を認証し、その支払いを返金する権限を確認し、整数の最小通貨単位による正の金額だけを受け付けるものとします。ハンドラーは次の処理を行います。
async function requestRefund(paymentId, amount) {
const payment = await payments.get(paymentId);
if (amount > payment.capturedAmount) {
throw new Error("Refund exceeds payment");
}
return refundJobs.enqueue({ paymentId, amount });
}
ワーカーが各ジョブを取り出し、決済プロバイダーに返金リクエストを送ります。アプリケーションは過去の返金を照合のために別の場所に保存しています。金額のチェックは、単体で見れば妥当に見えます。顧客が 100 ドルを支払ったので、60 ドルの返金リクエストは通ります。2 回目の 60 ドルのリクエストも通ります。それぞれのリクエストはハンドラーの条件を満たしていますが、合わせると決済済みの金額を超えてしまいます。
比較式を見つけるのは簡単です。このワークフローが過剰返金を起こしうると立証するには、もっと手間がかかります。
- ワーカーは返金履歴を読んでいるか
- プロバイダーに連絡する前に資金を確保しているか
- プロバイダー自身が累積上限を強制しているか
- 2 回目のリクエストは実際に完了しうるか
残高を超える返金をプロバイダーが拒否するなら、この例は過剰返金の成功を立証しません。それでも報告してしまえば、実行経路上の防御を無視することになります。同様に、返金可能な残高をアトミックに確保する会計関数があれば、ハンドラーが直接チェックしていなくても仮説は無効になりえます。
これらを排除するには、エントリーポイントをジョブ、ワーカー、そして実際に資金を動かす操作へとつなげる必要があります。その経路上にある既存の返金と関連する防御を考慮に入れなければなりません。そうして初めて、どのリクエストの連なりがアプリケーションの制約に違反するのか、そしてどのような条件下でそうなるのかを言えるようになります。
この作業が重要なのは、有用なレポートであれば、開発者が経路を確認し、欠けている防御策を理解し、結論に異議を唱えられるからです。
Deep Scan の内側
Deep Scan は、プルリクエストで変更された行だけでなく、コミット済みのコードベース全体を読みます。疑わしい操作も、誰がそこに到達できるのか、どの防御が適用されるのかを決めるコードがなければ、ほとんど意味を持ちません。
何が脆弱かを判断する前にコンテキストを確立する
Deep Scan は、エントリーポイント、信頼境界、アクセス制御、機微な操作、セキュリティ設定など、リポジトリのセキュリティに関わる部分を調べます。これにより、入力がどこから入り、アクセスに関する判断がどこで行われるのかを示す地図が調査に与えられます。
リンクされたリポジトリは、Deep Scan がスキャン対象リポジトリの検出結果を調査し検証するための読み取り専用のコンテキストを提供できます。検出結果がリンク先のソースを引用している場合、その詳細にはリポジトリ、ファイル、コミット、ソースへのリンクが表示されます。
コードに対して仮説を調査する
有用な仮説は、検証できるだけの具体性を備えていなければなりません。Deep Scan は関連する経路をたどり、候補となる検出結果の背後にあるコードを集めます。その説明は、必ずその証拠を指し示す必要があります。関数名、コメント、アーキテクチャの説明は調査の方向付けにはなりますが、防御策が実際に実行されることの証明にはなりません。
検出結果に独立して異議を唱える
コードを書くことと、それを攻撃することは、別の種類の仕事です。コーディングエージェントの仕事は依頼された変更を動くようにすることであり、その変更がどう悪用されうるかを問うことではありません。セキュリティレビューはまさにそれを問い、その答えを証拠で裏付けるために存在します。
CodeRabbit のセキュリティレビューは、コードを書いたエージェントから独立しています。どちらの役割も AI を使いますが、同じゴールに向かって動いているわけではありません。独立した検証器が、到達可能性、既存の防御策、悪用に必要な条件を確認します。防御を見落としていたり、裏付けのない前提に頼っていたりする候補は却下されます。公開される各検出結果には到達可能性と悪用可能性のグレードが付くため、一覧はパターンに一致したものではなく、攻撃者が実際に到達できるものの順に並びます。
独立した検証にも限界はあります。2 つ目のモデルもやはりモデルであり、1 つ目と同じ誤った前提を繰り返すことがあります。だからこそ証拠は開発者に見える形で残されなければなりません。開発者は、デプロイに関する知識、ビジネス上の制約、外部サービスの挙動など、スキャンが利用可能なソースからは確立できない情報を持ち込めるからです。
不確実性を保つ
コードベースを深く掘り下げれば見落とされていた防御が見つかることもありますが、前提の連鎖が長くなることもあります。深く掘るほど、どのコードが主張を裏付けるのか、各部分がどうつながるのか、そして証拠がどこで途切れるのかを示すことが重要になります。
コードは、ある操作が到達可能であることを示しても、それを悪用するために必要な条件をすべて確立できるとは限りません。外部サービス、デプロイ設定、入手できないコンポーネントが、重要な問いを未解決のまま残すことがあります。証拠が不完全なときは、検出結果はそう明示すべきです。
同じ原則はカバレッジにも当てはまります。Attack Surface Map は、各ポイントを完全に検証済み、未検証、または陳腐化のいずれかとして表示します。これらのステータスは、セキュリティに関わる領域のうち、どこに最新の証拠があり、どこにまだ注意が必要なのかを開発者に示します。完全に検証済みのポイントには評価が記録されますが、そのコードに脆弱性がないことを保証するものではありません。
その結果として得られるのは、開発者が確認できる検出結果と、何を修正するかを判断する前に評価すべき明示的な条件です。
カバレッジを最新に保つ
最初の Deep Scan はリポジトリ全体を読み、検証済みポイントの基準を確立します。変更のたびにこの完全なスキャンを繰り返せば、既存の証拠がすでにカバーしている作業を繰り返すことになります。Delta scan はこの基準から出発し、それ以降に動いた部分を調査します。具体的には、追加または変更されたファイルに加えて、その変更によって陳腐化した、または一度も検証されていない Attack Surface Map 上のポイントです。誰も触っていない検証済みのコードは、そのステータスを保ちます。
後続の各スキャンのコストが完全なスキャンのごく一部で済むのは、支出が変更されたコードと、陳腐化または未検証のポイントにだけ向かうからです。検証済みカバレッジの目標値を設定することもできます。カバレッジがその値を下回ると、月間の支出上限または利用可能なクレジットがフルスキャンの見積もりをまかなえる限り、CodeRabbit は Delta scan を実行します。これにより地図はコードに歩調を合わせ、誰かがスキャンの開始を覚えておく必要はありません。
検出結果を精査にかける
検出結果を自分で検証するということは、信頼できない入力がどのように機微な操作へ到達するかを追跡し、既存の防御策が攻撃を阻止するかどうかを確認し、攻撃が依存する設定や外部サービスの挙動を特定することです。
対象となる Deep Scan の検出結果については、ランタイム検証が再現手順ガイドを生成します。ガイドには、前提条件、経路を実際に通す手順、そして期待される結果が記されています。自分のステージング環境でそれに従うこともできますし、リポジトリ用のコーディング環境を用意して CodeRabbit にそこで実行させ、実行時の証拠を保持させることもできます。返金の例で言えば、2 回目の 60 ドルのリクエストが本当に通るかどうかがわかるのはここです。結果はテストした環境と条件に対して成り立つものなので、本番環境について知っていることと照らし合わせて読んでください。
次のステップは、問題を安全に修正する方法を決めることです。対応している検出結果については、Fix with AI が人間のレビューと承認を前提とした修正プルリクエストの草案を作成します。開発者は差分を確認し、関連するテストを実行してから受け入れます。
公開リポジトリには、プロジェクトに適した開示プロセスが必要です。メンテナーは、公開された修正の変更によって問題が早期に露出することなく、検出結果を調査できなければなりません。
よく知っているリポジトリから始める
この記事の冒頭に登場した、何年もすべてのテストとスキャンを通過してきたあのサービスこそ、始めるのにふさわしい場所です。チームが本番で運用していて、よく知っているリポジトリを選んでください。Deep Scan はそのエントリーポイントと信頼境界をマッピングし、検出結果が報告されたら、証拠をたどって各前提をシステムについて知っていることと照らし合わせられます。よく知っているリポジトリこそ、既存のツールが見つけていないものを Deep Scan が見つけられるかどうかを試す、最も公平なテストになります。
直近 30 日間で、CodeRabbit Secure は 600 の組織にわたり 8,000 件以上の高または重大なセキュリティ脆弱性を発見しました。アクセス制御の不備、SQL インジェクション、認証の不備が主な問題で、脆弱性全体の 70% 以上を占めました。
現在から 11 月 8 日まで、CodeRabbit は 100 万ドル分の Deep Scan 利用枠を無償で提供しています。現在、過去、新規のお客様やオープンソースチームを含む、2 人以上のメンバーがいる組織は、提供枠がなくなるまで先着順で最大 5,000 ドル分を利用できます。
AI は脆弱性を見つけ出します。CodeRabbit Secure は、それを先に見つけて修正する手助けをします。
