Skip to main content
PR Reviews are Odin 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 Testing > PR Reviews in the sidebar.
PR Reviews work with GitHub and Azure DevOps repositories, and with Bitbucket Cloud when that integration is enabled for your organisation. The reviews table stays on this page. If GitHub is not connected, or no repository has reviews on yet, a Finish setting up card sits above the empty table. Connect GitHub starts the GitHub App install. Enable PR reviews opens the Repositories panel on this page, even if you collapsed it, so you can switch reviews on per repository without leaving it. On a prepaid pay-as-you-go account, admins also see Add credits in the card while the balance is zero, because reviews are skipped until credits are added. You can also connect GitHub from the same card on Home, and request reviews on demand from GitHub comments.

​
How it works

When a pull request is opened (or pushed to, depending on your trigger mode), Odin:
  1. Receives the PR diff and metadata from your repository provider
  2. Reviews the changed code against the rest of your repository
  3. Surfaces any new security issues introduced by the change
  4. Posts comments and a review status back to the provider (a GitHub Check run or Bitbucket build status)
  5. Optionally fails the check if findings meet your blocking severity threshold
The 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. After GitHub is connected, the Repositories panel on the PR Reviews page lists every repository your GitHub App can reach. It opens automatically while no repository has reviews on, and collapses to a count once some do. Azure DevOps repositories appear in the same panel once that integration is connected. Turning a repository on expands its own set of controls:
  • Trigger mode: review on PR open only, or on every push (GitHub). Azure DevOps and Bitbucket repositories always review when a pull request is opened
  • 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

​
Azure DevOps

Azure DevOps reviews run when a pull request is opened, and not again on later pushes to it, so Review on every push is not offered there: Azure DevOps raises a single event for pushes and for edits to a pull request’s title, description or reviewers alike, so reviewing on it would re-run a review on every edit. The GitHub on-demand review controls described below do not apply to Azure DevOps either. Disconnecting Azure DevOps removes its Service Hooks and turns off its repository reviews. After reconnecting, turn reviews on again for each repository you want reviewed. This registers fresh Service Hooks; the other review settings are retained. A service principal connection does not register Service Hooks itself: remove the ones your Azure DevOps admin added under Project settings → Service hooks, and register them again with the new header value after reconnecting.

​
Bitbucket Cloud

Connected Bitbucket repositories appear in the Repositories panel. Enabling reviews registers a webhook, so the connected Bitbucket account needs repository admin access. Bitbucket reviews run when a pull request is opened, and not again on later pushes to it, so Review on every push is not offered there: Bitbucket raises a single event for pushes and for edits to a pull request’s title, description or reviewers alike. A failed review can still be retried from its detail page. The GitHub on-demand review controls described below do not apply to Bitbucket. Disconnecting Bitbucket removes its webhooks and turns off its repository reviews. After reconnecting, turn reviews on again for each repository you want reviewed. This registers fresh webhooks; the other review settings are retained.

​
Expired connections

If a Bitbucket or Azure DevOps connection expires, new pull requests in its repositories are no longer reviewed. The Repositories panel on this page says so for each expired provider, and members and admins get a Reconnect button that opens the integration so it can be reconnected. Reviews resume once it is. When no other source control is connected, the Finish setting up card shows Reconnect Bitbucket or Reconnect Azure DevOps instead of Connect GitHub.

​
The PR Reviews list

The list shows each pull request once, described by its latest review, however many pushes Odin has reviewed. Click a row, or move with j and k and press Enter, to open that review. The tabs sort pull requests by what to do next. Each pull request is in exactly one tab apart from All: Each row shows the PR title and number, the repository and author, how many pushes were reviewed, and how many earlier issues a later push addressed. It then names the most severe open finding with its file and line, and how many more are open. On the right are the open findings by severity, with the same severity marks as the Findings page, and Blocks merge when the check is failing on them. A finding stops counting as open once its suggestion is committed or ignored, its review thread is resolved on GitHub, an admin approves a decision on it, a re-check finds it addressed, or it is tracked as a finding. Observations are never counted. While a pull request is open, members and above can also Retry a review that couldn’t run, or Commit N fixes to commit a GitHub pull request’s open suggested fixes in one commit. Search by title or number, and filter by repository. Merged and closed pull requests come from your provider’s webhooks for GitHub and Bitbucket Cloud. Azure DevOps pull requests stay in the open tabs after they complete.

​
Progress

Above the tabs, Last 30 days sums up the pull requests reviewed in that period:
  • Found: distinct issues Odin raised, followed across pushes, and how many pull requests had any
  • Addressed: issues a later push fixed (found by a later review or a re-check), fixes committed from Odin, and review threads resolved on GitHub, with how many of those were on pull requests that have since merged. A later push counts as fixed only when Odin’s review or re-check says so; it isn’t independently verified.
  • Dismissed or risk accepted: approved false positives and accepted risks, and ignored suggestions
  • Still open: open findings on pull requests that haven’t merged or closed, with how long ago the oldest was first raised, and how many merged unaddressed and haven’t been tracked as findings
An issue a later push simply stopped reporting, without Odin saying it was fixed, counts as neither addressed nor open. A review shows Skipped when it couldn’t start because billing wasn’t ready, for example no credits are available or a payment method is missing. Its detail page explains what to resolve; nothing is charged for a skipped review.

​
Review detail

The detail page leads with whether the pull request is safe to merge, then lists what needs handling.
  • Header: the PR title, author, branch, head SHA and diff stats, with links back to your repository provider and, for GitHub, the check run
  • Verdict: one sentence on what is open and whether it blocks merge, the open findings by severity, and the merge check. When Odin has reviewed more than one push of the pull request, it also lists the pushes in order, for example “Push 1 · 3 found → Push 2 · 1 addressed, 2 still open”. Each earlier push links to its own review. After a re-check, it also says which commit was checked and what it found, for example “Re-checked 3f2a9c1 after a later push: 2 addressed, 1 still present”.
  • Open: every finding that still needs someone, most severe first. Once the pull request has merged, this is Unaddressed at merge.
  • Done: findings that were fixed, resolved on GitHub, ignored, decided or tracked as a finding, one line each. Open a row to see the whole finding. Issues from an earlier push that a later push addressed are listed here too, as “Addressed in push 2” with the commit and Odin’s reason. That is Odin’s reading of the new code, not an independent check. An issue a later push simply stopped reporting says “No longer reported” instead. Issues a re-check found fixed read “Addressed in a later push” or “Addressed before merge”.
Next that needs a look, at the top of the page, opens the next pull request on the PR Reviews list’s Needs a look tab. You can also press j.
  • Tracked findings: findings Odin already tracks that this PR fixes or may make worse (see below)
  • Worth knowing: observations, systemic issues noticed during the review with nothing to fix in this PR. Collapsed until you open it.
  • What changed and Review details: Odin’s summary of the PR, who or what started the review, when it ran and how long it took, the merge check and the review ID
Each open finding shows the same severity marks as the Findings page, its state, the file and lines, whether this PR introduced it, Odin’s confidence and the category. When Odin adjusted a finding’s severity for its context, the card says from what and why. A finding with a suggested fix shows the fix as a diff.

​
Committing or ignoring a suggested fix

For each open suggested fix, members and above can:
  • Commit fix on a GitHub review. Odin commits it directly to the PR’s head branch and the finding moves to Done as Fix committed.
  • Ignore the suggestion if it doesn’t apply (the equivalent of “won’t fix”), optionally with a reason.
Comment on GitHub opens the finding’s comment on the pull request. Viewers see every finding but none of the commit or ignore controls. Bitbucket and Azure DevOps reviews still show suggested fixes and support Ignore, but do not offer Commit fix, Commit all fixes or Commit selected. Apply those fixes directly in your repository. For GitHub, when several fixes are open you can commit them all at once with Commit all fixes, available from both the list and the detail page. To commit just some, select them with the checkboxes; they’re committed together in a single commit. Committing is only available while the pull request is open and the head branch lives in the same repository as the base. Fixes on fork PRs cannot be committed from Odin, because committing would write to your organisation’s copy of the branch rather than the contributor’s PR. Apply the fix on the fork, or merge the PR first. A finding can also reach 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). Fix couldn’t be committed keeps the finding open with the reason, for example because the file changed since Odin 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, Odin creates a suppression rule automatically so it stops being raised on future PRs.

​
Issues left open at merge

A pull request that merges with findings still open has taken them into its base branch. Its review page says so (“Merged with one finding unaddressed”) and no longer offers Commit fix, because the pull request takes no more commits. Instead, members and above can:
  • Track as finding to create an ordinary finding in Findings, laid out like other findings: its own identifier, the issue’s title, severity and weakness, the summary Odin posted on the pull request, what was found and how it was verified, the recommendation as remediation, and the file and lines linked to the reviewed commit. Its PR review property links back to the review. The issue then shows as “Tracked as ACME-12” under Done, and stops counting as open on the list. Tracking the same issue again opens the existing finding.
  • Dismiss it, with a false positive, an accepted risk or Ignore, as on an open pull request.
Nothing is tracked automatically. On a pull request that closed without merging, nothing reached the base branch, so there is nothing to track. Before a pull request with open issues merges, Odin re-checks them against its final commit, so an issue fixed before merge shows as addressed rather than unaddressed.

​
Re-checks after later pushes

With Review on PR open only (see Trigger modes), and on Bitbucket, later pushes aren’t reviewed in full. When a pull request still has open issues, Odin re-checks just those issues instead, on each push and once more at merge if nobody checked the final commit:
  • Each issue is compared with what changed since it was found. If nothing that could fix it changed (no code changed, or only documentation, styles or images), it stays open and nothing is charged.
  • Otherwise a short check asks whether the changes remove each issue. An issue counts as addressed only when a changed file fixes it; anything less keeps it open, or marks it undecided when Odin can’t tell. This is Odin’s reading of the new code, not an independent test.
  • An addressed issue moves to Done as “Addressed in a later push” or “Addressed before merge”, with the commit and the reason, and counts as addressed in the list and in Progress.
  • On GitHub, a re-check after a push completes the Mjolnir Security Review check on that commit, failing while issues at or above your blocking severity are still present. On Bitbucket it sets the commit’s build status. Re-checks don’t post or edit comments, and they don’t look for new issues in the new code: request a full review for that.
The review’s verdict says when the latest re-check ran and what it found. A re-check costs a small fraction of a review and is skipped, like a review, when billing isn’t ready. Pull requests with no open issues are never re-checked. Azure DevOps doesn’t tell Odin about later pushes, so its pull requests aren’t re-checked.

​
Tracked findings

Odin cross-references every PR review against the findings already tracked for your organisation. A finding in this PR that relates to a tracked one carries a link to it at the top of its card: the tracked finding’s identifier, title and severity, with “Addresses this finding” or “Worsens this finding”. It stays in Open or Done like any other finding, so a fix that touches a tracked finding can still be committed. An observation that only reports on a tracked finding (for example, that this PR fixes it) is listed under Tracked findings as a compact card instead. Either link opens the finding in your Findings view. Findings and observations can also carry a link labelled Related to when Odin spots a connection to a tracked finding without fixing or worsening it.

​
Triggering a review manually

If you want to ask Odin 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 Odin GitHub App is installed, a Run 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.

​
Re-running a failed review from GitHub

GitHub can re-request the Mjolnir Security Review check directly from the pull request. Odin accepts native reruns for reviews in the Failed state, reuses the existing review and check run, and queues the same head commit again. Reviews that are already queued or running are left alone. Completed reviews cannot currently be rerun from GitHub. This prevents a second analysis of the same commit from replacing findings that have already been bridged into Odin. Use a new commit or the existing Odin retry action when the review itself failed.

​
Ask from a pull-request comment

You can also request an on-demand review directly from a GitHub pull request. Add a comment containing a real @gungnirai mention and the standalone word review, for example:
The command is case-insensitive and accepts punctuation between the mention and the request. It works even when automatic PR reviews are disabled, so you can keep automatic runs off and request reviews only when you need them. For safety, Odin accepts requests from repository owners, members, collaborators, or contributors who authored a commit in the pull request. Bot comments and unauthorised public comments are ignored. Odin also checks your organisation’s entitlement and available credits before queuing the review; if a review cannot run, GitHub receives a neutral check with an explanation instead. Odin reviews each pull-request head commit at most once. Push a new commit before requesting another review after making changes.

​
Trigger modes

Suppression Rules

Manage patterns PR reviews should not raise