> ## Documentation Index
> Fetch the complete documentation index at: https://www.oplane.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Block merges on unresolved security requirements

> Make the Oplane Security Review check block GitHub pull requests and GitLab merge requests while unresolved requirements sit at or above a severity you choose.

This page covers the **Oplane Security Review** check and how to use it as a merge gate. For how the review that produces the check works, see [How reviews work](/docs/how-it-works/reviews).

## Check failure threshold

By default, the **Oplane Security Review** check reports **Neutral** when unresolved requirements exist. GitHub branch protection and GitLab merge-request approvals treat **Neutral** as passing, so the check surfaces findings without blocking a merge.

Turn on **Block merges on unresolved findings** per repository to have the check block whenever an unresolved requirement sits at or above a severity you choose. Combined with your Git provider's branch or merge rules, this acts as a merge gate to prevent unresolved requirements from slipping through.

<Tabs>
  <Tab title="GitHub">
    The check shows an amber **Action required** conclusion, which branch protection treats as non-passing, so it blocks the merge exactly like a failure. Red **Fail** is reserved for reviews that failed to complete.
  </Tab>

  <Tab title="GitLab">
    GitLab has no equivalent of **Action required**, so the check reports a blocking **Failed** status instead.
  </Tab>
</Tabs>

The check's summary shows how many requirements still need attention, for example `1 of 3 security requirements need attention`, and reads `All 3 security requirements resolved` once everything is addressed. The check's details link opens the generated threat model.

## Configure the failure threshold

1. Open the workspace connected to the repository.
2. Go to workspace settings and find the linked repository. Make sure PR/MR analysis is enabled. The merge-gate setting only appears while analysis is on.
3. Turn on the **Block merges on unresolved findings** switch.
4. Pick a severity on the slider. The slider runs from **Low** to **Critical** and starts at **Low** the first time you enable the switch:

   | Slider position | Check blocks when an unresolved requirement is at least |
   | - | - |
   | Low | Low |
   | Medium | Medium |
   | High | High |
   | Critical | Critical |

   **Info** requirements are advisory and never cause the check to block, even at the **Low** setting.

Turning the switch off returns the check to **Neutral** for unresolved findings. Oplane remembers your last severity, so turning the switch back on restores it. Repositories that previously used the removed **Any severity** option display as **Low**. Both block the same findings because Info never blocks.

## Use as a merge gate

Oplane does not modify your branch protection or merge settings. You control which branches enforce the check by marking it as required in your Git provider.

<Tabs>
  <Tab title="GitHub">
    Open the repository's **Settings → Branches → Branch protection rules** (or **Settings → Rules → Rulesets**), edit the rule for the target branch, and add `Oplane Security Review` under **Require status checks to pass before merging**. Once you have finished editing the rule, set the *Enforcement Status* to **Active**.

    Once the check is required, GitHub blocks the merge whenever Oplane reports **Action required**.
  </Tab>

  <Tab title="GitLab">
    Open the project's **Settings → Merge requests** and require the `Oplane Security Review` status check under **Merge checks**, or add it as a required approval rule.

    Once the check is required, GitLab blocks the merge whenever the status is **Failed**.
  </Tab>
</Tabs>

## Clear a blocking check without a new push

Resolving a requirement in Oplane re-posts the **Oplane Security Review** check on the same commit SHA that Oplane reviewed. You do not need to push a new commit to clear a blocking check. Both of the following trigger a refresh:

* Marking a requirement as resolved, out of scope, or accepted risk in the Oplane dashboard.
* Calling the MCP `update_implementation_state` tool from your coding agent.

If the newly resolved state brings every unresolved requirement below the threshold, the check flips from **Action required** (GitHub) or **Failed** (GitLab) to **Neutral** or **Pass**.

## Shared repositories

When multiple workspaces subscribe to the same repository or project, Oplane posts a single **Oplane Security Review** check per commit. The strictest failure threshold across those workspaces wins for that repository and commit. For example, if one workspace has merge blocking turned off and another set to **High**, unresolved High or Critical requirements cause the check to block.

## Read next

* [Check status](/docs/reference/statuses-and-severity#check-status), for every state the check can report.
* [Respond to requirements](/docs/find/respond-to-requirements), to resolve what's blocking.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.