PR-scoped security review checks a proposed change before merge, using the diff and relevant codebase context, while a deep scan examines the committed codebase beyond the current change. PR review catches risks while the author can still fix them, and deep scans investigate older code and the vulnerabilities that span changes.
The scopes overlap, but they answer different questions. PR review asks what security risks a change introduces, while a deep scan asks what vulnerabilities already exist in the codebase. Your team needs both to review incoming changes and reassess the code already in your repository.
Deep scan vs. PR-scoped security review at a glance
What each review examines
| Question | PR-scoped security review | Deep scan |
| Where does analysis start? | The proposed diff, with relevant surrounding code. | The committed codebase within the configured scan scope. |
| When is it useful? | Before you accept a change. | When you establish a baseline or reassess existing code. |
| What context does it emphasize? | The change's intent and its effect on existing behavior. | Relationships across the codebase, regardless of when code arrived. |
| What can it leave unchecked? | Older code unrelated to the change and interactions missed across separate PRs. | Excluded paths, areas beyond analysis limits, and changes made after the scan. |
| Can CodeRabbit block a merge? | Yes, when you enable the Security check and require it in GitHub. | Deep Scan findings do not directly block merges through that check. |
Why the timing matters
A PR gives you an author, a stated purpose, and a decision point, while a repository scan gives you a broader view of code that has already merged. Neither timing guarantees complete coverage, so the practical question is whether your workflow gives findings an owner and gets fixes reviewed.
What PR security review catches and misses
Catch risks before the change merges
Per-change review puts feedback where you can act on it. The author still understands the change, and your team can address a finding before accepting the code.
Consider a PR that adds an order lookup endpoint. Authentication proves the caller has logged in, but the review also needs to check whether that caller can access the requested order. If the route accepts an arbitrary order ID without an ownership check, a logged-in user could retrieve someone else's order.
The PR's stated purpose helps the reviewer assess that behavior. A customer order endpoint and an administrator's order endpoint have different permission requirements, even when their database queries look similar.
On GitHub Cloud and GitHub Enterprise Server, the optional CodeRabbit Security check is off by default. Turn on Publish CodeRabbit Security check in the repository’s Security settings and set Block on, which defaults to Critical, to the lowest severity that should fail the check. To block merging, also require the check through branch protection or a ruleset. Publishing it alone does not change merge rules. The check evaluates PR Security comments, separately from Deep Scan findings.
Account for older code and cross-change risks
PR review does not systematically reassess everything that merged before you adopted it. It can find an existing vulnerability connected to a change, but unrelated older code may never come into view.
Risk also builds across PRs. For example, one change introduces a helper that assumes its caller checks permissions, and a later change reuses it from a route that assumes the helper checks them. If both reviews miss that mismatch, nothing checks permissions.
CodeRabbit’s Security Blast Radius maps connections beyond changed lines, and Security Architecture Review examines security implications across changed components and trust boundaries. Both help reviewers investigate a PR, while repository scans provide a separate opportunity to reassess committed code.
What a deep scan catches and misses
Investigate vulnerabilities across committed code
A deep scan examines existing code no matter how old it is, so you can investigate inherited repositories and attack paths that span changes.
As Rohit Khanna writes in Introducing CodeRabbit Security, “The risk only becomes clear when you see how it interacts with the rest of the application.” For the order endpoint example, that means tracing the route through authorization logic and the database lookup, then checking whether any layer enforces ownership.
Attackers can investigate those connections too. Khanna’s article cites Anthropic’s November 2025 report of a single cyberespionage campaign in which AI performed 80% to 90% of the work. When attackers can hand that much of an attack to AI, teams need to revisit existing code as well as review new changes.
CodeRabbit’s Deep Scan combines rule-based signals with AI reasoning, investigating suspected paths and checking candidates against repository evidence. On supported platforms, selected linked repositories supply context, such as a shared authentication library, but they need separate scans for their own findings and coverage.
Check coverage and keep dependency monitoring
Read the coverage and evidence alongside the results. A completed scan can still have partial coverage because of configured exclusions or analysis limits. A scan also reflects a snapshot, so later changes need fresh analysis.
A new attack technique can make a previously theoretical path practical, and a newly disclosed dependency vulnerability can affect unchanged code. Deep Scan does not perform software composition analysis, so keep dependency monitoring in your workflow.
Modern static analysis tools also trace data flows, within the languages, frameworks, and models they support. Application-specific permissions and business rules can require more context. The guide to SAST vs. SCA explains how static analysis and dependency scanning fit together
When to use PR review, full scans, and delta scans
Review every PR and establish a baseline
Review each PR before merge, while the author still has context. Run a deep scan when you adopt the process so older code is covered too, and scan acquired, vendored, or migrated code when it enters your environment.
Prioritize findings by the evidence, the data affected, and the access an attacker needs. Assign an owner and route remediation into a PR. Reviewing the fix lets your team check that it closes the attack path and preserves expected behavior.
Match rescanning to repository changes
Rescan as your repository changes. CodeRabbit supports recurring full-scan schedules on GitHub. Delta scans refresh changed files and stale or unverified mapped points between full scans.
For CodeRabbit delta scans, the published requirements call for a full Deep Scan of the whole repository within the last 30 days, and partial or selected-directory scans do not qualify. If the repository has an attack surface map, its verified coverage must be at least 15%. Run a full Deep Scan at least every 30 days to keep delta scans available, and review the delta scan requirements, including billing, before setting up automation.
On GitHub, delta automation checks a configured commit, day, or coverage trigger after merges to the default branch. A day trigger does not start a scan when no merges occur. Enabling delta automation replaces an existing full-scan schedule, so plan how you will refresh the full baseline.
How CodeRabbit connects findings to fixes
Review changes and remediate supported findings
CodeRabbit Secure supports continuous PR security review and Deep Scan. For supported findings, Fix with AI creates a PR or merge request that your team reviews before merging.
To guide later scans, supply architecture context, path instructions, and Security Learnings, which are separate from PR review Learnings. The scan guidance page explains the available controls.
Evaluate detection and follow-through separately
CodeRabbit’s benchmark methodology describes how detection is evaluated against known vulnerabilities in open-source repositories, but detection results alone do not establish fix quality.
Follow-through also includes documentation and other work that remains after merge. Post-Merge Actions run configured follow-up tasks, such as changelog updates and tickets, using PR context after a PR merges, and they serve a different purpose from scan scheduling.
Start a free trial to review incoming changes, then run a Deep Scan on the code you already have. Deep Scan is metered separately and requires usage billing when no free allowance applies.
Frequently asked questions
Does PR security review cover existing vulnerabilities?
PR security review can identify existing vulnerabilities connected to a proposed change, but it does not systematically reassess code that merged earlier. Use repository-wide scans to investigate older code and interactions missed across changes, and keep dependency monitoring in place for newly disclosed vulnerabilities.
How does CodeRabbit verify suspected vulnerabilities?
CodeRabbit checks repository evidence for reachability, safeguards, and exploitation conditions before reporting findings. Verification reduces unsupported findings, but it does not guarantee that every reported issue is exploitable in your deployed environment or that the scan found every vulnerability.
