Skip to main content
PR Reviews are Mjolnir security reviews that run on your pull requests. They give you fast, targeted feedback during code review — before vulnerabilities are merged — rather than waiting for a full pentest run after deployment. Open the PR Reviews page from Security testing > Full pentests > PR Reviews in the sidebar.
PR Reviews work with both GitHub and Azure DevOps repositories. Connect the relevant integration, then enable PR Reviews for the repositories you want covered from the Mjolnir Configuration page.

How it works

When a pull request is opened (or pushed to, depending on your trigger mode), Mjolnir:
  1. Receives the PR diff and metadata from GitHub
  2. Reviews the changed code against the rest of your repository
  3. Surfaces any new security issues introduced by the change
  4. Posts the results back to GitHub as a Check run
  5. Optionally fails the check if findings meet your blocking severity threshold
Mjolnir’s review is targeted at the diff. It analyses the specific code that’s changing in the context of your codebase, so it can catch issues that only appear when the new code interacts with existing logic.

Configuration

PR review settings are per repository, not global. The Mjolnir Configuration page lists every repository your GitHub App or Azure DevOps connection can reach, each with its own Enable PR review toggle. Turning a repository on expands its own set of controls:
  • Trigger mode: review on PR open only, or on every push
  • Blocking severity threshold: fail the check on Critical only, High and above, Medium and above, or never
  • Auto-suppression: when the same finding pattern is dismissed across multiple PRs on that repository, automatically create a suppression rule so it stops being raised
  • Auto-suppression threshold: how many distinct PRs must dismiss a pattern before auto-suppression kicks in

The PR Reviews list

The list view shows every PR review across your repositories.
  • Filter by repository or status (Queued, Running, Completed, Failed)
  • Sort by date or by number of open suggestions
  • Click any review to open its detail page
Each row shows the PR title and branch, the repository, the open suggestion count, the status and conclusion, and when the review was opened. A summary bar above the table totals reviews, open suggestions, and reviews needing attention. A review that failed can be retried straight from its row.

Review detail

The detail view shows everything Mjolnir found:
  • PR summary: title, author, repository, head SHA, links back to GitHub and the check run
  • Diff stats: files changed, lines added/removed
  • Suggestions: each issue Mjolnir raised, with its file, line range, and severity, plus a suggested code fix when Mjolnir is confident enough to propose one
  • Status filters: counts of open, accepted, and ignored suggestions, plus resolved and failed counts when either applies
  • Mjolnir summary: a high-level write-up of what Mjolnir saw in this PR

Accepting or ignoring a suggestion

For each open suggestion, your team can:
  • Accept the suggested fix. Mjolnir commits it directly to the PR branch and marks the suggestion Accepted.
  • Ignore the suggestion if it doesn’t apply (the equivalent of “won’t fix”), optionally with a reason.
You can also accept every open suggestion in a review at once with Accept all, available from both the list and the detail page. To apply just some, select them with the checkboxes; they’re committed together in a single commit. A suggestion can also land in two further states outside these actions. Resolved on GitHub covers a review thread resolved directly on GitHub rather than acted on in Odin (this stays distinct from Ignore, so it doesn’t feed auto-suppression). Failed covers an accepted fix that couldn’t be committed, for example because the file changed since Mjolnir read it. Ignoring suggestions feeds the auto-suppression system: if the same pattern is ignored across multiple PRs on that repository above your configured threshold, Mjolnir creates a suppression rule automatically so it stops being raised on future PRs.

Correlated findings

Mjolnir cross-references every PR review against the findings already tracked for your organisation. When a change touches a known finding, that result leaves the general Suggestions list and moves into one of two dedicated sections:
  • Addressed Findings: known findings this PR remediates. A quick way to confirm a fix landed where you expected.
  • Regression Risk: known findings this PR may make more exploitable. Worth a closer look before you merge.
A correlated result that carries a suggested fix keeps its full card, with the diff and the Accept and Ignore actions, marked with a coloured edge to show the link. An informational correlation shows a compact card instead: the tracked finding’s identifier, title and severity, plus a one-line verdict (“Addresses this finding” or “Worsens this finding”). Either card opens the finding in your Findings view. Individual suggestions and observations can also carry an inline link to a related finding, labelled Fixes, Worsens, or Related to, when Mjolnir spots a connection that does not warrant its own section.

Triggering a review manually

If you want to ask Mjolnir to review a specific PR that wasn’t auto-reviewed (or to re-review a PR after changes), there are two ways to do it:
  • From GitHub: when the Mjolnir GitHub App is installed, a “Run Mjolnir Review” button is available on the PR
  • Direct link: visit /pentest/mjolnir/pr-reviews/trigger?repo=owner/repo&pr=123 in Odin (this is the URL the GitHub button calls)
The trigger queues the review and redirects you to the detail page once it’s ready.

Trigger modes

Suppression Rules

Manage patterns Mjolnir should not raise in PRs