CodeRabbit Secure now scans across repository boundaries, following vulnerabilities through dependency graphs and verifying exploitability in throwaway sandboxes. The hard problem is maintaining scan state when a single vulnerability in a shared library affects 50 downstream repos without triggering exponential rescans or drowning teams in duplicate alerts.
Most security tools stop at the repository perimeter. They scan what you own, flag issues, and leave cross-repo correlation to humans. CodeRabbit’s new Deep Scan feature treats the dependency graph as the real attack surface and coordinates agents to traverse it.
Multi-Repo Scan Architecture
Deep Scan operates in three phases: baseline establishment, cross-repository traversal, and delta reconciliation.
Baseline establishment runs a full semantic analysis on committed code in the target repository. The agent builds an internal graph of data flows, API boundaries, and external dependencies. This is not a diff scan. It examines the entire codebase to find vulnerabilities that shipped months or years ago.
Cross-repository traversal activates when the agent detects a dependency link. If a vulnerability trace crosses into a linked repository (a shared library, a monorepo sibling, or a vendored module), the agent spawns a new scan context in that repository. Each context maintains its own state but shares a correlation ID with the parent scan.
Delta reconciliation runs after merges. Instead of rescanning the entire codebase, the agent revisits only the changed files and any areas where earlier verification results have become stale. This keeps security coverage current without repeating expensive full scans.
State Management Across Repository Boundaries
The agent maintains three types of state:
- Scan state: current position in the dependency graph, visited nodes, pending branches
- Correlation state: mapping between findings in different repos that trace back to the same root cause
- Verification state: runtime sandbox results, exploit confirmation status, fix validation
When the agent crosses into a linked repository, it serializes the current scan context and passes a bounded subset to the new scan. The subset includes the vulnerability signature, the call chain that led to the boundary crossing, and a recursion depth counter.
The recursion depth counter prevents infinite loops. If the agent detects a circular dependency (repo A depends on B, B depends on C, C depends on A), it stops traversal at a configurable depth limit. The default is three hops.
Runtime Verification in Sandboxes
Static analysis produces false positives. A code path that looks exploitable may be unreachable at runtime, or input validation elsewhere in the stack may neutralize the threat. CodeRabbit’s runtime verification spins up a throwaway sandbox, replays the exploit attempt, and confirms whether the vulnerability is real.
The sandbox is a containerized copy of the application with instrumentation hooks. The agent constructs an exploit payload based on the static analysis findings, injects it through the identified entry point, and monitors for successful exploitation (arbitrary code execution, data exfiltration, privilege escalation).
If the exploit succeeds, the finding is marked as confirmed. If it fails, the agent logs the failure reason (input sanitized, code path unreachable, insufficient permissions) and downgrades the severity.
Sandbox execution is expensive. CodeRabbit runs verification selectively:
- Always verify critical findings (RCE, SQL injection, authentication bypass)
- Verify medium findings if they appear in a PR diff
- Skip verification for low-severity findings unless explicitly requested
Correlation Without Duplicate Alerts
A vulnerability in a shared library can propagate to dozens of downstream repositories. Naive scanning produces one alert per affected repo, flooding the backlog with duplicates.
CodeRabbit’s correlation engine groups findings by root cause. When the agent detects the same vulnerability signature in multiple repos, it checks whether they share a common dependency. If they do, it creates a single parent finding and links the downstream occurrences as children.
The parent finding includes:
- The vulnerable dependency (name, version, file path)
- The list of affected repositories
- The exploit path from each repo to the vulnerable code
- A single remediation recommendation (upgrade the dependency, apply a patch, add input validation)
Developers see one actionable item instead of 50 duplicates.
Orchestration Model
CodeRabbit uses a coordinator-worker pattern. The coordinator receives scan requests, builds the initial dependency graph, and dispatches worker agents to scan individual repositories.
Each worker agent:
- Clones the target repository
- Runs static analysis to identify vulnerabilities
- Checks for dependency links
- If a link is found, sends a traversal request back to the coordinator
- Waits for correlation results before finalizing findings
The coordinator maintains a global view of all active scans. When a worker requests a cross-repo traversal, the coordinator checks whether that repository is already being scanned. If it is, the coordinator merges the scan contexts instead of spawning a duplicate worker.
Workers communicate through a message queue (likely Redis or RabbitMQ based on typical agent architectures). The coordinator tracks scan progress in a distributed state store (etcd or DynamoDB) to handle worker failures and retries.
Tool Boundary Breakdown
| Layer | Tool | Responsibility |
|---|---|---|
| Static analysis | Semgrep, custom AST parsers | Identify code patterns, data flows, API calls |
| Dependency resolution | Language-specific resolvers (npm, pip, Maven) | Build dependency graph, resolve versions |
| Cross-repo traversal | Custom orchestration agent | Manage scan state, dispatch workers, correlate findings |
| Runtime verification | Sandboxed container (Docker or Firecracker) | Execute exploit attempts, confirm exploitability |
| LLM reasoning | GPT-4 or Claude | Generate exploit payloads, suggest fixes, explain attack paths |
The LLM does not run static analysis. It receives findings from Semgrep and other tools, then reasons about exploitability and remediation. This keeps the LLM in the loop for high-value tasks (understanding context, generating fixes) while avoiding the latency and cost of using it for pattern matching.
Recursion Limits and Explosion Prevention
Dependency graphs are not trees. They are directed acyclic graphs (DAGs) with shared nodes. A single library can appear in dozens of places. Naive traversal explodes exponentially.
CodeRabbit applies three limits:
- Depth limit: stop after three hops from the root repository
- Breadth limit: scan at most 100 linked repositories per root scan
- Deduplication: if a repository has already been scanned in the current session, reuse the cached results instead of rescanning
The depth limit is configurable. Teams with deep dependency chains can increase it, but the cost scales quickly. Each additional hop multiplies the number of repositories scanned.
The breadth limit prevents runaway scans. If a monorepo has 500 internal packages, the agent scans the 100 most critical (based on usage frequency, security history, and developer-defined priority) and skips the rest.
Delta Scans and Incremental Coverage
After the initial Deep Scan, CodeRabbit switches to delta mode. Instead of rescanning the entire codebase on every commit, it scans only the changed files and any areas where earlier verification results have become stale.
Staleness is determined by:
- Time since last scan (default: 30 days)
- Dependency updates (if a library version changes, rescan all call sites)
- New vulnerability disclosures (if a CVE is published for a dependency, rescan affected code)
Delta scans run automatically on merge. The agent compares the current commit to the last scanned commit, identifies the diff, and rescans the affected code paths. If the diff touches a file that calls into a linked repository, the agent triggers a cross-repo traversal for that specific call chain.
This keeps security coverage current without the cost of full rescans.
Security Check and Merge Blocking
CodeRabbit can block pull requests from merging if a critical security finding is open. The Security Check runs as a GitHub status check or GitLab pipeline stage. If the agent finds a critical vulnerability (RCE, SQL injection, authentication bypass), the check fails and the PR cannot merge until the issue is resolved.
Developers can override the block with a manual approval, but the override is logged and visible in the security dashboard.
Integration Points
CodeRabbit routes findings into Jira and Linear through webhooks. Each finding becomes a ticket with:
- Vulnerability description
- Affected repositories
- Exploit path
- Suggested fix
- Link to the Deep Scan report
The API exposes findings as JSON for custom integrations. Teams can pull findings into their own dashboards, SIEM systems, or compliance reporting tools.
Failure Modes
Sandbox timeout: if the runtime verification sandbox does not complete within the timeout (default: 5 minutes), the finding is marked as unverified and the severity is downgraded.
Dependency resolution failure: if the agent cannot resolve a dependency (private registry, network issue, missing credentials), it skips that branch of the graph and logs a warning.
Correlation collision: if two unrelated vulnerabilities produce the same signature, the agent may incorrectly group them. This is rare but possible. The mitigation is manual review of grouped findings.
Worker crash: if a worker agent crashes mid-scan, the coordinator retries the scan up to three times. If all retries fail, the scan is marked as incomplete and the team is notified.
Technical Verdict
Use CodeRabbit Secure cross-repo scanning if:
- You have a microservices architecture with shared libraries
- You maintain a monorepo with internal dependencies
- You need to trace vulnerabilities across organizational boundaries
- You want runtime verification to reduce false positives
Avoid it if:
- You have a single standalone repository with no external dependencies
- Your dependency graph is shallow (one or two levels)
- You already have a mature security pipeline with custom correlation logic
- You cannot tolerate the latency of sandbox execution (5+ minutes per critical finding)
The cross-repo traversal and runtime verification are the differentiators. If you do not need those features, a simpler single-repo scanner will be faster and cheaper.