CodeRabbit launches Deep Scan to hunt logic flaws in committed code

Why CodeRabbit says attackers have an edge

CodeRabbit describes a familiar problem: a service can run for years with passing tests, patched dependencies and scans on every pull request while a flaw tied to the application's own logic goes unnoticed. Read function by function, the code looks safe. The weakness appears only when someone traces a whole workflow and asks what the code assumes along the way.

According to CodeRabbit, AI now lets an attacker do that work without knowing the codebase. The company points to a report Anthropic published in November 2025 about an AI-orchestrated espionage campaign. In that campaign, AI performed 80% to 90% of the tactical work, and human operators stepped in at only a handful of decision points. The attackers targeted roughly 30 organizations and got into a small number of them.

CodeRabbit's conclusion is that the same capability can help a team find the problem first, including in services whose original authors have moved on. It adds that in an agentic software development lifecycle, ownership of old code cannot sit with security alone, and engineering shares it.

Where Deep Scan fits next to existing scanners

CodeRabbit does not present Deep Scan as a replacement for current tools. Static analysis can follow data across functions and identify unsafe flows, dependency tools flag known vulnerable packages, and secret scanners look for exposed credentials. The company says to keep those.

Deep Scan is meant as an additional reasoning layer for flaws that may not match a known rule, vulnerable package or exposed secret. CodeRabbit notes that rules can be written for particular authorization patterns, but the difficulty lies in expressing every application-specific obligation in advance, especially when a workflow spreads it across several components. Deep Scan's semantic analysis instead works out what the application is supposed to enforce, then looks for evidence in the implementation that supports or contradicts that hypothesis. It also checks whether a control is actually missing and what an attacker could do without it.

To illustrate, CodeRabbit walks through a simplified refund workflow. A handler checks that each refund request does not exceed the captured payment amount. A customer who paid $100 can request a $60 refund twice, and each request passes the check, yet together they exceed the payment. Whether this is a real over-refund depends on questions such as whether the worker reads refund history, whether funds are reserved before the payment provider is contacted, and whether the provider enforces a cumulative limit. If the provider rejects refunds above the remaining balance, CodeRabbit says, the example would not establish a successful over-refund, and reporting one would ignore a protection on the execution path.

How a Deep Scan works

Deep Scan reads the committed codebase rather than only the lines changed in a pull request. CodeRabbit says a suspicious operation means little without the code that determines who can reach it and which protections apply.

• Context first: the scan examines security-relevant parts of the repository, including entry points, trust boundaries, access controls, sensitive operations and security configuration. Linked repositories can supply read-only context, and a finding that cites a linked source shows the repository, file, commit and source link.
• Hypothesis against code: the scan follows relevant paths and gathers the code behind a candidate finding. Function names, comments and architectural descriptions can orient the investigation, but they cannot prove that a safeguard executes.
• Independent challenge: CodeRabbit says its security review is independent of the agent that wrote the code. A separate verifier checks reachability, existing safeguards and the conditions required for exploitation, and rejects candidates that overlook protections or rely on unsupported assumptions.

Each published finding carries a reachability and exploitability grade, so the list is ranked by what an attacker could actually reach rather than by what a pattern matched.

What it means for development teams

CodeRabbit is open about the limits of the approach. A second model is still a model, it says, and it can repeat the same wrong assumption as the first. For that reason the evidence stays visible to the developer, who can bring deployment knowledge, business constraints and external-service behavior that the scan may not have.

For teams, the pitch is that findings come as inspectable paths from entry point to sensitive operation, so developers can understand the missing safeguard and challenge the conclusion before deciding what to change. The source does not give pricing or availability details.