> ## 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.

# Automated threat modeling on merge requests

> Automate threat modeling on GitLab merge requests with Oplane, surfacing security feedback in code review before merging.

Oplane integrates with GitLab to automatically run threat modeling on merge requests. Get security feedback directly in your review workflow before you merge.

## Setup

Connect your project through a [repo-connected workspace](/docs/workspaces#connecting-a-repository). See [Connect GitLab](/docs/gitlab-setup) to sign in with GitLab and select your projects. If your team runs its own GitLab server, add it first as a [self-managed GitLab integration](/docs/integrations/gitlab-self-managed).

## How it works

When you open or update an MR, Oplane analyses the diff, creates a threat model scoped to the changes, and posts the requirements in a single **Oplane Security Review** summary comment on the MR.

### Automatic analysis

Oplane reads the diff, identifies architectural and security-relevant changes, and generates security requirements specific to what changed. All findings appear in one summary comment that lists each requirement with its status and severity, and links to the generated threat model. Oplane updates the comment as requirements are resolved, so it always reflects the current review state. See [Comment structure](/docs/statuses-severity#comment-structure) for what the comment contains.

### Review modes

You can configure how Oplane reviews your MRs per workspace:

* **Analyse every MR**: Oplane runs automatically on every new merge request. Best for projects with active development.
* **On request**: Mention `oplane review`, `@oplane review`, `oplane run`, or `@oplane run` in a comment on any MR to trigger a review when you need it.
* **Disabled**: No automatic reviews for this workspace.

## Check failure threshold

By default, the **Oplane Security Review** check reports **Neutral** when unresolved requirements exist. 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 project to have the check report a blocking **Failed** status whenever an unresolved requirement sits at or above a severity you choose. Combined with your project's merge checks, this acts as a merge gate to prevent unresolved requirements from slipping through.

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 project.
2. Go to workspace settings and find the linked project. Make sure 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. Projects 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 merge settings. You control enforcement by making the check required in 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**.

### 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 **Failed** to **Neutral** or **Pass**.

### Shared projects

When multiple workspaces subscribe to the same project, Oplane posts a single **Oplane Security Review** check per commit. The strictest failure threshold across those workspaces wins for that project 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.