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

# Automated threat modeling on pull and merge requests

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

Oplane integrates with both GitHub and GitLab to automatically run threat modeling on pull requests and merge requests. Get security feedback directly in your review workflow before code is merged.

## Setup

Connect your repository through a [Managed Workspace](/docs/workspaces#managed-workspace):

* [Connect GitHub](/docs/connect-github) — install the Oplane GitHub App and link your repositories
* [Connect GitLab](/docs/gitlab-setup) — sign in with GitLab and select your projects

## How it works

When a PR or MR is opened or updated, the Oplane worker analyses the diff, creates a threat model scoped to the changes, and posts requirements as review comments directly on the relevant lines.

### Automatic analysis

Oplane reads the diff, identifies architectural and security-relevant changes, and generates security requirements specific to what changed. Each finding is posted as an inline comment on the affected lines — so you get feedback exactly where it matters.

### Review modes

You can configure how Oplane reviews your PRs/MRs per workspace:

* **Analyse every PR/MR** — Oplane runs automatically on every new pull request or merge request. Best for projects with active development.
* **On request** — Mention `@oplane` in a comment on any PR or 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. GitHub branch protection and GitLab merge-request approvals treat **Neutral** as passing, so the check surfaces findings without blocking a merge.

Set a **check failure threshold** per repository to have the check report **Fail** whenever an unresolved requirement sits at or above a severity you choose. Combined with your CI pipeline's branch protection rules, this acts as a merge gate to prevent unresolved requirements from slipping through.

### Configure the failure threshold

1. Open the workspace for the repository (Managed Workspace).
2. Go to workspace settings and find the linked repository.
3. Under **Check failure threshold**, pick a severity level:
   | Threshold                                                                                       | Check reports Fail when an unresolved requirement is at least |
   | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
   | Off                                                                                             | Never fails — the check stays Neutral                         |
   | Critical                                                                                        | Critical                                                      |
   | High                                                                                            | High                                                          |
   | Medium                                                                                          | Medium                                                        |
   | Low                                                                                             | Low                                                           |
   | Any severity                                                                                    | Low                                                           |
   | **Info** requirements are advisory and never cause the check to fail, even at **Any severity**. |                                                               |

### Use as a merge gate

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

* **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**.
* **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, GitHub or GitLab blocks the merge whenever Oplane reports **Fail**.

### Clear a failing check without a new push

Resolving a requirement in Oplane re-posts the **Oplane Security Review** check on the same commit SHA that was reviewed. You do not need to push a new commit to clear a failing 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 **Fail** to **Neutral** or **Pass**.

### Shared repositories

When multiple workspaces subscribe to the same repository, 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 is set to **Off** and another to **High**, unresolved High or Critical requirements cause the check to fail.