Atsushi Nakatsugawa
April 24, 2026
1 min read
AI Code Reviews | CodeRabbit | Try for Freeの意訳です。
つい先日、Webアプリケーションのデプロイに広く利用されているクラウドプラットフォームであるVercelが、数ヶ月前に始まっていた侵害を公表しました。事の発端は間接的なものでした。Context.aiの従業員が、Robloxスクリプトに偽装されたLumma Stealerを知らずにインストールしてしまったのです。
その後、Context.aiを利用していたVercelの従業員が、この罠に巻き込まれました。攻撃者は盗んだOAuthトークンを通じてVercel従業員のGoogle Workspace認証情報を窃取し、横展開（ラテラルムーブメント）によってVercelの内部システムに侵入しました。これにより、APIキー、トークン、データベース認証情報、署名鍵などが流出しました。Vercelはこれを受けて、「sensitive」とマークされていないすべての環境変数をローテーションし、それらの値は漏洩したものとして扱うよう顧客に勧告しました。
今回のハッキングに対する事後分析では、OAuthのガバナンスやサードパーティSaaSのリスクに焦点が当てられるでしょう。そうした視点は妥当ですが、コード自体のセキュリティに責任を持つセキュリティリーダーにとっては本質を見逃しています。これは開発者サプライチェーン攻撃であり、盗まれた資産がそれを証明しています。
お客様は最も価値ある資産であるソースコードをCodeRabbitに託してくださっています。その信頼があるからこそ、セキュリティは後付けではなく、CodeRabbitの設計原則そのものなのです。
正しい問いは、開発者スタックのコンポーネントが侵害されるかどうかではありません。より適切な問いは、「その地点から攻撃者が与えうる最大の被害は何か」です。
CodeRabbitのコードレビュープラットフォームは、まさにこの問いを中心に構築されています。すべてのコードレビューは、隔離されたエフェメラル（一時的な）サンドボックスで実行され、イベントごとにプロビジョニングされ、完了後に破棄されます。各サンドボックスは、レビュー対象のリポジトリのみにスコープされた、短命のトークンを1つだけ保持します。顧客間で共有される状態はありません。長期間有効な認証情報もありません。内部ネットワークへのアクセスもありません。
サンドボックスはツールが必要とする場合にパブリックインターネットにアクセスできますが、CodeRabbitの内部サービスにはアクセスできません。保存されるコードは顧客ごとの鍵で暗号化されており、CodeRabbitの従業員でさえアクセスできません。
その結果、サンドボックスが侵害されたとしても、ピボット先がありません。永続的なトークンも、横展開の経路もないのです。
もし明日、あなたのサンドボックスやワーカーの1つが侵害されたら、最悪のシナリオはどうなりますか？ すべてのエンタープライズが、開発者スタック内のすべてのベンダーに対してこの問いを投げかけるべきです。
多くのVercelの顧客は、自分が知らないうちに流出していた鍵をローテーションしなければなりませんでした。なぜなら、最も被害が大きい認証情報は、チームが存在を忘れているもの、つまり環境変数に埋もれていたり、ソースファイルに直接ハードコーディングされていたりするものだからです。
コードレビューは、シークレットが永続化する前の最後の実用的なチェックポイントです。認証情報がGitリポジトリにコミットされてしまうと、完全に消去することはできません。フォーク、キャッシュ、CIログ、開発者のマシンにコピーが残り続けます。唯一の確実な防御策は、プルリクエストの段階で検出することです。
CodeRabbitは、パターンマッチングとデータフローを理解するAI駆動のコンテキスト分析を組み合わせて、ハードコーディングされた認証情報をフラグ付けします。パターンマッチングは、sk_live_*、AKIA[A-Z0-9]{16}、ghp_[a-zA-Z0-9]{36}のような形式や、*_SECRET、*_KEY、*_PASSWORDという名前の変数を検出します。
また、Semgrep、Checkov、Brakeman、Betterleaksなどのツールとも統合しており、ワンクリックでの修正をプルリクエスト内に直接表示します。セキュリティチームは.coderabbit.yamlで自然言語によるカスタムチェックを定義し、マージ前のゲートとして適用できます。例えば、データベースDSNをハードコーディングしているファイルのブロックや、read:userより広いOAuthスコープのフラグ付けなどが可能です。
Vercelはその後、新しい環境変数がデフォルトでsensitiveになるようプラットフォームを更新しました。これは正しい方向への一歩ですが、環境変数に格納されたシークレットしかカバーしません。ソースファイル、フィーチャーブランチ、コメント、設定ファイルにハードコーディングされた認証情報は検出できないのです。より堅牢なアプローチは、すべての認証情報をデフォルトでsensitiveとして扱い、本番環境に到達する前のコードレビュー層でそれを強制することです。
Vercelの侵害は、本質的にはID（アイデンティティ）の侵害でした。サードパーティアプリに発行されたOAuthトークンが、攻撃者のアクセス経路となったのです。ワークスペースでOAuthアクセスを持つすべてのツール、長期間有効なGitHubトークンで動作するすべてのCIサービス、モノレポへの読み取りアクセスを持つすべてのAIアシスタント——そのそれぞれが潜在的なエントリーポイントです。
コードレビュープラットフォームには、IDプロバイダーに適用するのと同レベルのID管理の厳格さが求められます。
CodeRabbit Enterpriseでは、以下の機能を提供しています：
目標はシンプルです。たとえ上流で侵害が発生したとしても、コードレビューツールが攻撃チェーンの次のエントリーポイントになることは決してあってはなりません。
Vercelの侵害は、コードベースに触れるすべてのツールを再評価するきっかけとなります。ソースコードへのアクセスを持つすべてのベンダーに、CodeRabbitを含めて、以下の質問をしてください：
CodeRabbitの回答は、セキュリティアーキテクチャの詳細およびトラストセンターに記載されています。ご質問がございましたら、チームが喜んでお答えいたします。
サプライチェーン攻撃は、主要なターゲットから始まるのではありません。最も弱いリンクから始まります。開発者ワークフロー内のすべてのベンダー、トークン、OAuth grant、またはコードへの読み取りアクセスを持つすべてのツールが、潜在的なエントリーポイントです。Vercelの侵害はVercelから始まったのではありません。Robloxスクリプトから始まったのです。
回答を求めてください。ソースコードを託しているすべてのベンダーは、自社が次のVercelになった場合に何が起こるかを正確に説明できるべきです。
