A service can run for years with passing tests, patched dependencies, and scans on every pull request while an application-specific vulnerability remains undetected. Read the code function by function and nothing looks dangerous. The vulnerability only shows up when a developer traces the whole workflow and asks what the code assumes along the way.
An attacker can ask that question too, and no longer needs to know the codebase to answer it. AI reads unfamiliar code, traces each path through a workflow, and probes the assumptions its authors made, faster than any team of reviewers could. Code that has run untouched for years is now within reach of anyone who points a model at it.
That is why we built Deep Scan in CodeRabbit Secure. It investigates committed code, independently verifies what it finds, and gives developers evidence they can inspect before deciding what to change.
Attackers got an upgrade #
Application security has always depended partly on how much time and expertise someone could spend investigating a system. Tracing a request across unfamiliar code takes effort. So does identifying a missing safeguard and working out whether the surrounding application makes it exploitable.
AI can now do most of that work. In November 2025, Anthropic published a report on an AI-orchestrated espionage campaign in which AI performed 80% to 90% of the tactical work, with human operators stepping in at only a handful of decision points. The attackers targeted roughly 30 organizations and got into a small number of them.
The same AI that finds the vulnerability for an attacker can find it for your team first. You can revisit a service whose original authors have long since moved on, trace the assumptions the code was built on, and add the missing control before anyone else gets there. In an agentic SDLC, ownership of old code can’t sit with security alone; engineering shares it.
When the flaw is in the application logic #
Existing scanners do useful work.
- Static analysis can follow data across functions and identify unsafe flows
- Dependency tools identify known vulnerable packages
- Secret scanners look for exposed credentials
Keep the tools that cover those jobs. Deep Scan adds an independent reasoning layer for application-specific flaws that may not match a known rule, vulnerable package, or exposed secret.
You can write rules for particular authorization patterns. Mature analysis tools can also model frameworks and trace complex flows. The difficulty sits in expressing every application-specific obligation in advance, especially when a workflow spreads that obligation across several components.
Deep Scan's semantic analysis works out what the application is supposed to enforce, then looks for evidence in the implementation that supports or contradicts the hypothesis.
Deep Scan doesn’t stop at the evidence. It checks whether the control is actually missing and what an attacker could do without it.
Follow one vulnerability across the application #
Consider this simplified, illustrative refund workflow. Assume the route already authenticates the caller, checks their permission to refund the payment, and accepts only positive amounts in integer minor units. Its handler then does this:
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 });
}
A worker takes each job and sends the refund request to the payment provider. The application stores prior refunds elsewhere for reconciliation. The amount check looks reasonable in isolation. A customer paid $100, so a request to refund $60 passes. A second request for $60 also passes. Each request satisfies the condition in the handler, but together, they exceed the captured amount.
Spotting the comparison is easy. Establishing that the workflow can over-refund takes more work.
- Does the worker read the refund history?
- Does it reserve funds before contacting the provider?
- Does the provider itself enforce a cumulative limit?
- Could the second request actually complete?
If the provider refuses any refund exceeding the remaining balance, this example does not establish a successful over-refund. Reporting one anyway would ignore a protection on the execution path. Likewise, an accounting function that atomically reserves the refundable balance could invalidate the hypothesis even if the handler never checks it directly.
Ruling those out means connecting the entry point to the job, the worker, and the operation that moves money. It must account for existing refunds and relevant protections along that path. Only then can you say which sequence of requests violates the application's constraint and under what conditions.
That work matters because a useful report lets the developer inspect the path, understand the missing safeguard, and challenge the conclusion.
Inside a Deep Scan #
Deep Scan reads the committed codebase, not just the lines changed in a pull request. A suspicious operation means little without the code that determines who can reach it and which protections apply.
Establish context before deciding what is vulnerable
Deep Scan examines security-relevant parts of the repository, including entry points, trust boundaries, access controls, sensitive operations, and security configuration. This gives the investigation a map of where input enters and where decisions about access are made.
Linked repositories can supply read-only context for Deep Scan to investigate and verify findings in the repository being scanned. When a finding cites a linked source, its details show the repository, file, commit, and source link.
Investigate a hypothesis against the code
A useful hypothesis has to be specific enough to test. Deep Scan follows the relevant paths and gathers the code behind a candidate finding. Its explanation must point back to that evidence. Function names, comments, and architectural descriptions can orient the investigation, but they cannot prove that a safeguard executes.
Challenge the finding independently
Writing code and attacking it are different kinds of work. A coding agent’s job is to get a requested change working, not to ask how that change could be abused. Security review exists to ask exactly that, and to back its answer with evidence.
CodeRabbit’s security review is independent of the agent that wrote the code. Both roles use AI, but they aren’t working toward the same goal. A separate verifier checks reachability, existing safeguards, and the conditions required for exploitation. It 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.
Independent verification also has limits. A second model is still a model, and it can repeat the same wrong assumption as the first. Evidence therefore has to remain visible to the developer, who can bring deployment knowledge, business constraints, and external-service behavior that the scan may not establish from available sources.
Preserve uncertainty
Digging deeper into the codebase can reveal an overlooked protection, but it can also extend the chain of assumptions. The deeper the dig, the more important it is to show which code supports the claim, how the pieces connect, and where the evidence ends.
Code can show that an operation is reachable without establishing every condition needed to exploit it. An external service, deployment setting, or unavailable component can leave a material question unanswered. When the evidence is incomplete, the finding should say so.
The same principle applies to coverage. The Attack Surface Map marks each point as fully verified, unverified, or stale. Those statuses show developers which security-relevant areas have current evidence and which still need attention. A fully verified point records an assessment, but it does not guarantee that the code is free of vulnerabilities.
The result is a finding developers can inspect, with explicit conditions to evaluate before deciding what to fix.
Keep coverage current
Your first Deep Scan reads the whole repository, which is how it establishes a baseline of verified points. Running that full scan again on every change would repeat work the existing evidence already covers. Delta scans start from the baseline and investigate what has moved since: files that were added or changed, plus the points on the Attack Surface Map that those changes made stale or that were never verified. Verified code nobody touched keeps its status.
Each follow-up scan costs a fraction of a full one because the spend goes only to the code that changed and to stale or unverified points. You can also set a verified-coverage target. When coverage drops below it, CodeRabbit runs a delta scan, as long as your monthly spending cap or available credits cover the full-scan estimate, so the map keeps pace with the code and nobody has to remember to start a scan.
Put the finding under scrutiny #
Verifying a finding yourself means tracing how untrusted input reaches a sensitive operation, checking whether existing safeguards block the attack, and identifying any configuration or external service behavior the attack depends on.
For eligible Deep Scan findings, runtime verification generates a reproducer guide that lists the prerequisites, the steps that exercise the path, and the expected result. You can follow it in your own staging environment, or set up a coding environment for the repository and have CodeRabbit run it there and keep the evidence from the run. In the refund example, that’s where you’d learn whether the second $60 request actually goes through. The result applies to the environment and conditions tested, so read it alongside what you know about production.
The next step is deciding how to fix the problem safely. For supported findings, Fix with AI drafts a remediation pull request for human review and approval. Developers inspect the diff and run relevant tests before accepting it.
Public repositories need a disclosure process appropriate to the project. Maintainers should be able to investigate a finding without a public remediation change exposing it prematurely.
Start with a repository you know well #
The service from the top of this post, the one that has passed every test and scan for years, is the right place to start. Pick a repository your team runs in production and knows well. Deep Scan maps its entry points and trust boundaries, and if it reports a finding, you can follow the evidence and check each assumption against what you know about the system. A repository you know is the fairest test of whether it finds anything your current tools haven’t.
Over the last 30 days, CodeRabbit Secure found 8,000+ high or critical security vulnerabilities across 600 organizations. Broken access control, SQL injection, and authentication failures were the dominant issues, accounting for over 70% of the vulnerabilities.
From now until November 8, CodeRabbit is making $1 million in Deep Scan usage available at no cost. Organizations with two or more members, including current, former, and new customers and open-source teams, can access up to $5,000 on a first-come, first-served basis while the allocation lasts.
AI will find the exploit. CodeRabbit Secure helps you find and fix it first.