CodeRabbit Security check

| CodeRabbit Security publishes a native check, build result, or pull request status that fails while blocking Security review comments remain. Choose a severity threshold, then configure your provider’s merge requirements separately. The check is off by default for every repository. It appears only after you enable it for a repository with PR Security review access. It is separate from the general CodeRabbit review check and from Deep Scan results.

Provider support and merge enforcement

Publishing a result does not automatically block merging. Use the setup for your provider: Self-managed Git providers must be connected to CodeRabbit Cloud. This guide does not describe support for self-hosted CodeRabbit deployments. Availability of the repository setting and PR Security review access are required for every provider.

Enable the check

You need Security write permission to change this setting. Your repository must have PR Security review access. On GitHub Enterprise Server, the CodeRabbit GitHub App installation also needs Checks: Read and write repository permission. If your App was configured with read-only Checks access, update the App and approve the updated installation permissions first. See GitHub Enterprise Server setup. For GitLab, complete the Cloud setup or Self-Managed setup. Ultimate external checks also need the project-specific setup described below. For Bitbucket Data Center, complete the provider setup, including the service account and webhook configuration. The service account needs repository write access to publish builds and resolve comments, and read access to the source repository for fork pull requests. For Bitbucket Cloud, the integration must be able to publish build statuses on the source commit, including for fork pull requests. For Azure DevOps Services or Server, give the CodeRabbit bot repository access and permission to contribute to pull requests. If you use a PAT, include Code (status) in addition to Code (Read & Write). Confirm that coderabbit/security appears on a test pull request before requiring it. See Azure DevOps setup. The first evaluation includes existing visible Security comments on the pull request. Configure publication in these repository settings; there is no .coderabbit.yaml option for this check.

Severity thresholds

The threshold includes the selected severity and every higher severity. Threshold changes apply to newly published comments. Raising the threshold does not clear existing blockers, and lowering it does not turn comments previously below the threshold into blockers. Existing comments retain the decision made when they were first evaluated.

Require the check in GitHub

Publishing the check does not change your repository’s merge rules. To block merging, a GitHub repository administrator must configure a ruleset for the protected branch, or a branch protection rule, that requires CodeRabbit Security.

1. Let CodeRabbit Security complete a review with Success or Neutral so GitHub can list it as an available required check.
2. In your GitHub repository, open Settings > Rules > Rulesets. Create or edit a branch ruleset and select the branches you want to protect. If you use classic branch protection, edit the rule under Settings > Branches instead.
3. Enable Require status checks to pass before merging and add CodeRabbit Security. Select the CodeRabbit App as the expected source.
4. Save the rule. For a ruleset, set its enforcement status to Active.

See GitHub’s guide to creating a branch ruleset and its required status check rules for setup details. GitHub requires the check to pass on the latest commit; both Success and Neutral satisfy this requirement. A failed or unfinished required check blocks merging, subject to your GitHub bypass rules.

Require the check in GitLab

On GitLab Cloud and Self-Managed, Ultimate supports requiring the named external check. After enabling publication:

1. In CodeRabbit’s repository Security settings, select Copy GitLab Ultimate setup. The copied values contain the check name, project-specific callback URL, and shared secret.
2. In GitLab, open Settings > Merge requests > Status checks and add an external status check. Use the copied CodeRabbit Security name, URL, and HMAC shared secret exactly as supplied. Select the target branches to protect.
3. Enable Status checks must succeed and save the project settings.
4. Create a new merge request to validate the rule. GitLab applies newly registered checks to new merge requests, not retroactively to existing ones.

Keep the shared secret private. Copy the setup separately for each project; do not reuse another project’s URL or secret. See GitLab’s external status check configuration. On Free and Premium, CodeRabbit publishes an MR-specific pipeline status such as CodeRabbit Security / <project-id>!<merge-request-number>. Requiring successful pipelines can reject a failed pipeline, but does not require this particular Security status to exist. A passing ordinary CodeRabbit review or another pipeline does not establish that the Security check ran.

Configure merge checks in Bitbucket Cloud

CodeRabbit publishes a separate build status for the reviewed source commit. To enforce Bitbucket’s built-in build checks, a repository administrator must configure merge checks for the target branches and use Bitbucket Premium to prevent merges with unresolved checks. Use the successful-build requirement that also rejects failed or in-progress builds. Choose the required build count for your repository’s workflow. See Atlassian’s merge check setup.

Require the build in Bitbucket Data Center

Publishing a build does not configure merge blocking. A repository administrator must add a Required builds rule on a licensed Bitbucket Data Center instance. A minimum successful-build count does not require CodeRabbit Security specifically.

1. Enable publication and let a review publish CodeRabbit Security so its build key is available.
2. In the target repository, open Repository settings > Required builds and select Add required builds.
3. Select the Security build with parent key coderabbit-security. This is the shared required-build identifier, not the individual coderabbit-security/... key for one pull request.
4. Choose the protected target branches. Leave exempt source branches at None unless you intend to allow a bypass, then save.
5. Validate the rule on a disposable pull request in your instance: confirm a failed or unfinished Security build prevents merging, then fix the blocker and confirm a successful build satisfies this requirement. Other merge requirements still apply.

See Atlassian’s Required builds setup. For API-managed rules, the required-builds API selects this identifier through buildParentKeys.

Require the status in Azure DevOps

Use the same setup for Azure DevOps Services and registered Azure DevOps Server instances connected to CodeRabbit Cloud. You need permission to edit branch policies.

1. Enable publication and confirm that a review posts coderabbit/security on a test pull request.
2. Open the target branch’s Branch policies, find Status checks, and add coderabbit/security.
3. Set the policy to Required and select the CodeRabbit bot as the Authorized identity.
4. Apply the policy by default when a pull request is created, and enable Reset status whenever there are new changes. Applying it only after the first status is posted can leave pull requests without a Security result outside the requirement.
5. Save and validate a new pull request: missing, pending, and failed results should prevent completion; a successful result satisfies this policy. Other policies and configured bypass permissions still apply.

The Security result belongs to the reviewed PR head and iteration. See Microsoft’s external service branch policy guide.

Understand the result

Each provider shows the outcome in its own state: Known blockers continue to fail the check even when other review evidence is unavailable. Incomplete analysis alone does not cause failure. A successful or neutral result does not guarantee that the code has no security issues. Outside GitHub, a neutral outcome uses the provider’s passing state. Read the result description to distinguish a verified result from a result with unavailable evidence. If CodeRabbit cannot read the source or confirm publication, the latest commit can have no Security result or an unfinished result; a missing result is not a successful evaluation.

What counts as a Security comment?

The check tracks visible inline comments published by CodeRabbit under Security & Privacy. Each comment counts once. When one comment contains multiple Security issues, its highest displayed Security severity applies. Replies, summary-only items, comments in other categories, and unpublished analysis do not count.

Read the report

On GitHub, open CodeRabbit Security in the pull request’s Checks tab to see:

• The commit that was evaluated.
• Comment counts by severity: Found, Verified fixed, Remaining, and Blocking.
• Blocking comments with their file locations and direct links.
• The Block on threshold used for that review and a link to repository settings.

Counts carry across reviews of the same pull request. A dash (—) means the history needed for that count is unavailable; it does not mean zero. The report can list blockers admitted under an earlier threshold even after you change the setting. On Bitbucket Data Center, open the pull request’s builds and find CodeRabbit Security for the reviewed source commit. The build contains a short verdict and a link to the pull request; it does not contain GitHub’s detailed report table. Read the Security comments on the pull request for the findings and their locations. Each pull request has a separate build key, while all Security builds share the required-build parent key coderabbit-security. Inspect CodeRabbit Security in GitLab’s merge request external checks or pipeline statuses, the Security build status for the source commit in Bitbucket Cloud, or coderabbit/security in Azure DevOps’ pull request status or policy results. Use the result description and Security comments to understand the blockers; these provider statuses do not expose GitHub’s detailed Checks report.

Clear a blocking comment

Fix the issue, push a new commit, and let CodeRabbit review it. CodeRabbit uses its code-based comment resolution results to verify that the current code addresses the issue. Unrelated pushes do not clear blockers. If a published comment is deleted, a later review removes it from blocking only after confirming the deletion. Deleted comments are not counted as Verified fixed.

Disable or troubleshoot the check

Before turning off Publish CodeRabbit Security check, remove its specific requirement from GitHub’s merge rules, GitLab Ultimate’s external status checks, Bitbucket Data Center’s Required builds, or Azure DevOps’ branch status policies. Preserve unrelated requirements. Otherwise, your provider can block merging while waiting for a check that will no longer be published. On GitLab Free and Premium, Pipelines must succeed can block merging when no qualifying pipeline runs. If Security is the only qualifying pipeline, configure another pipeline to validate merge requests before disabling Security publication. If your project will no longer use pipelines, an administrator can turn off Pipelines must succeed under Settings > Merge requests > Merge checks. Turning off this setting removes the successful-pipeline requirement for the project, including unrelated pipelines; keep it enabled when other pipelines must still pass. See GitLab’s pipeline merge check guidance. Bitbucket Cloud build-count rules cannot target Security by name. If the remaining successful builds cannot meet the configured count after Security stops publishing, administrators must adjust the required count or replace the missing Security build with another build that validates the commit. Lowering the count can weaken enforcement of unrelated builds, so confirm that the resulting policy still meets your team’s merge requirements. Disabling applies to subsequent reviews. A check already in progress finishes normally, and previously published checks remain visible. Disabling and re-enabling does not erase tracked blockers or history. If the check does not appear, confirm that publication is enabled for the correct repository, PR Security reviews are available, and a review has run since you enabled it. When your plan no longer provides PR Security reviews, new checks stop publishing even if the saved preference remains enabled. Unless you restore that access, follow the provider-specific guidance above: remove the named Security requirement, replace or remove GitLab Free/Premium’s pipeline requirement, or adjust Bitbucket Cloud’s build-count requirement. Otherwise, pull requests can remain blocked waiting for a result that will not be published. For rejected publication, check the integration’s credentials and repository permissions, then request a new review. For forks, check source repository access as well as target repository access. For GitLab Ultimate, also confirm that the external check uses the setup copied for this project and that you are testing a new merge request. A GitLab status-check retry refreshes saved results; request a CodeRabbit review to evaluate code changes.

What’s next