CodeRabbit logoCodeRabbit logo
エージェントエンタープライズカスタマー料金表ブログ
  • ドキュメント
  • トラストセンター
  • お問い合わせ
  • FAQ
  • レポート&ガイド
ログイン無料トライアルを開始

プロダクト

エージェントDiscordプルリクエストレビューIDE レビューCLI レビュープランオープンソース

ナビゲーション

私たちについて特徴FAQシステムステータス採用データ保護附属書スタートアッププログラム脆弱性開示

リソース

ブログドキュメント変更履歴利用事例トラストセンターブランドガイドラインレポート&ガイド

問い合わせ

サポートセールス料金表パートナーシップ

By signing up you agree to our Terms of Use and authorize CodeRabbit to provide occasional updates about products and solutions. You understand that you can opt out at any time and that your data will be handled in accordance with CodeRabbit Privacy Policy

footer-logo shape
利用規約プライバシーポリシー

CodeRabbit Inc © 2026

Our security posture: How we safeguard your repositories

by
Harjot Gill
Rohit Khanna
David Loker

Harjot Gill

Rohit Khanna

David Loker

September 14, 2025

6 min read

September 14, 2025

6 min read

  • Overview
    • Our architecture at a glance
    • Our layered approach
    • 1\. Sandbox
    • 2\. Token Service Separation
    • 3\. Customer Data Isolation & Encryption
  • Our broader security posture
  • Looking ahead
Back to blog
Cover image

共有

Share on XShare on LinkedinShare on Reddit

他の記事を読む

Opus 5をコードレビューで検証:アクション可能なコメントはクリーンに、全体はノイジー

Opus 5をコードレビューで検証:アクション可能なコメントはクリーンに、全体はノイジー

Opus 5は、クリーンなアクション可能コメントのストリームを生成しました。一方で、既知の問題の検出は少なく、nitpickはベースラインの約4倍に増えました。このモデルが適する可能性のある場面と、適さない場面を解説します。

コードはもうボトルネックではない。今は理解だ。

コードはもうボトルネックではない。今は理解だ。

コーディングエージェントは、人が理解できる以上の速さで変更量を増やせます。人がシステムの方向を決め続けるには、意図から挙動、コードまでを共有できるレビュー経路が必要です。

マージのたびにループを閉じる:レビューしたエージェントが次の作業まで引き継ぐ

マージのたびにループを閉じる:レビューしたエージェントが次の作業まで引き継ぐ

Post-Merge Actionsは、プルリクエストのコンテキストを利用して、マージ後の変更履歴、ドキュメント、チケット作成などを進めます。

Our customers trust us with their most valuable asset: their source code. That trust is why security is central to our mission of helping developers ship better code faster.

When there’s a chance to strengthen our security posture, we act quickly and decisively. And when we design new systems, we design them with “security by default” in mind.

We share below the architecture that makes CodeRabbit more resilient, limits the potential impact of any one component, and ensures that the data entrusted to us remains safe under all circumstances.

Overview

Customers install CodeRabbit on their git platforms via the app marketplace. We integrate via webhooks with all popular Git providers such as GitHub, GitLab, Bitbucket & and Azure DevOps. The integration allows us to register webhooks on events such as PR opened, user comment, etc.

Each event is processed in complete isolation. We maintain a secure internal queue that verifies subscriptions, applies rate limits, and ensures that only authorized events are allowed through. Events are handled one at a time, with zero shared state and no assumptions about what came before or after.

This model gives us something incredibly valuable: containment by default. If an attacker were to compromise one event, they would find nothing else to pivot to – no shared memory, no long-lived tokens, no context beyond that single, short-lived process. Every review starts from scratch, runs alone, and ends clean.

Our architecture at a glance

Here’s a high-level look at how our system is structured in our git-based, IDE, and CLI reviews:

Our security posture: How we safeguard your repositories

This design is focused on limiting an attacker’s potential “blast radius” – or how much damage an attacker can do if they succeed at breaching one component. By isolating secrets, tightly scoping tokens, and strengthening our encryption, we’ve drastically reduced that radius.

Our layered approach

We use these layered strategies:

1. Sandbox

We create a secure sandbox environment for each code review event to clone the codebase in order to read files, pull context from various sources in our knowledge base about your code and to run tools, linters, web search queries & verification checks. Our sandboxed environment only has the short-lived token for that particular repository, but it contains absolutely no other secrets, API keys, or credentials. Even if an attacker were to achieve remote code execution within our sandbox environment or get out of the sandbox and break the sandbox kernel-based isolation mechanism, they would find nothing of value - no environment variables with tokens, no configuration files with secrets.

Internal network access is also blocked from the sandbox. Tools may connect to the internet when required, but they cannot reach CodeRabbit’s internal services.

2. Token Service Separation

To reinforce the isolation of workloads, we have fully embraced a model based on short-lived session tokens rather than long-lived secrets. Instead of passing environment variables or static credentials, every process is scoped with query or event-specific tokens. These git provider tokens are valid only for the duration of the event or process. These are customer-specific, short-lived tokens. These tokens also have strict rate limiting and audit logging.

This means that workloads never carry unnecessary privileges. They can only access the resources required to process a specific pull request – and nothing more.

By removing persistent credentials from execution environments, we eliminate one of the most common attack surfaces. Even if a third-party tool were exploited, the attacker would see nothing beyond the minimal context of the current event.

3. Customer Data Isolation & Encryption

Each customer's code review is completely isolated. We provision separate containers per code review and use customer-scoped tokens that can only access their specific repositories. There is no shared state between customers.

We also ensure that our code index and all cached code is encrypted with a unique key per customer. Even CodeRabbit employees can't see any code-related data we store. You can also opt out of these features if you don’t want a cached copy of your code.

This layered approach ensures that even if an attacker were able to gain access, they would be unable to access anything critical.

Our broader security posture

A security best practice is to layer multiple controls so that if one fails, others remain in place. We’ve implemented several layers of defense to protect customer code and data:

Automated sandbox enforcement: Every external tool must run in an isolated sandbox environment. This rule is enforced automatically.

  • Hardened deployment gates: We’ve added pre-deployment checks that verify no service can bypass sandbox isolation or attempt to run with escalated privileges.

  • Encryption by customer key: Code indexes and cached code are encrypted with a per-customer key. This ensures that even if cache data were exposed, it would remain unreadable without the correct key.

  • Auditing and monitoring: We’ve expanded our monitoring of sandboxed environments and added automated alerts for unexpected behavior or network activity.

  • Expanded training: Every CodeRabbit engineer receives additional security training focused on secure-by-design practices and safe handling of secrets.

  • Least privilege access: Users, processes, and systems are granted only the minimum level of permissions and access rights necessary to perform their specific tasks and nothing more.

  • Vulnerability disclosure program (VDP): We maintain a formal program that invites independent security researchers to report potential issues responsibly. This ensures that if a weakness is discovered, it can be addressed quickly, transparently, and in partnership with the security community.

  • Penetration testing and architectural reviews: We work with multiple third parties to conduct routine penetration testing and architectural reviews to routinely audit and improve our security posture.

Looking ahead

We’re committed to building on this foundation by continuing to work with independent auditors, engaging with security researchers through responsible disclosure, and refining our internal practices.

Our goal is to deliver world-class AI code reviews with the highest levels of security and reliability.