Skip to main content
Fixing a finding is only half the loop — someone still has to confirm the fix actually worked. Automatic retests close that loop for you: link the pull request that fixes a finding, and when it merges, Odin reviews the merged code change and decides whether the finding is resolved. There’s no separate retest to request by hand. This sits at the end of the finding lifecycle, between Mitigating and Fixed & Retested. See Finding status for the full lifecycle.
Automatic verification reviews the merged code change. A finding with no linked pull request can’t be retested automatically — the merged diff is what the retest reads.

​
Prerequisites

Three things need to be in place for a retest to fire automatically:
1

Connect GitHub

Install the Borg GitHub App so Odin can read your repositories and receive pull request events. See the GitHub integration.
2

Turn on Automatic retests

On the GitHub card in Management > Integrations, enable Automatic retests. When off, merging a fix updates the linked PR’s state but doesn’t trigger a retest.
3

Link the pull request that fixes the finding

The fix has to be connected to the finding. There are three ways to do this, covered next.

​
Linking a pull request to a finding

Every finding has a unique, human-readable identifier made from your organisation’s finding prefix and a sequence number — for example BORG-12. It’s shown in the finding header and on every list row, and it’s how Odin connects a finding to your engineering work. When the GitHub integration is connected, Odin watches incoming pull requests for a {PREFIX}-{N} identifier in three places, in priority order:
  1. The branch name (highest priority)
  2. The pull request title
  3. The pull request body
If a token matches a finding in your organisation, that PR is linked automatically. The link shows as a chip in the finding header, and the source — branch, title, or description — is recorded so you can tell where it came from. There are three practical ways to make a link happen.

​
1. Copy the generated branch name (fastest)

The finding detail header has a Copy branch name action. It gives you a ready-to-use git branch name that combines the identifier and a slugified title:
Paste it into git checkout -b, push your fix, and open the PR — because the identifier is in the branch name (the highest-priority source), the PR links automatically the moment it’s opened. This is the recommended path: nothing to remember, nothing to type.

​
2. Reference the identifier in the PR title or body

If you branched some other way, just mention the identifier when you open the pull request. Any of these link the PR automatically:
  • A title like BORG-12: fix SQL injection in login form
  • A body that mentions the finding, such as Fixes BORG-12
The same detection runs each time the PR is opened or edited, so adding the identifier to an existing PR links it too. Sometimes a PR fixes a finding without mentioning it anywhere Odin looks. Choose Link a pull request from the finding’s action menu to connect it by hand (needs the GitHub integration and permission to update the finding). The dialog lists recent pull requests, scoped to the finding’s repository when Odin knows it, searchable by number, title, author, or branch. Pick one to link it, or paste a GitHub PR URL if it isn’t in the list.
Only manually linked pull requests can be removed. Unlink one from the dialog if you picked the wrong PR — auto-linked PRs are managed by Odin and would be re-created on the next PR event.

​
What linking does to the finding

  • Linked PRs show as chips in the finding header, each labelled with how it was linked (branch name, title, description, or manually). The chip tracks the PR’s state as it moves through GitHub — open, merged, or closed.
  • A PR linked to a Reported finding auto-transitions it to Mitigating, a clear signal to Borg’s analyst team that work is in progress. A finding already further along keeps its status.
  • Merging a PR does not, on its own, move the finding to Fixed & Retested. In develop → staging → production workflows, merging to develop doesn’t mean the fix is live. What the merge does trigger is the retest below.

​
What happens when your PR merges

When a pull request linked to a finding merges, and the finding is still open (Reported, Acknowledged, Mitigating, or Open for Retest), Odin queues an automatic retest — provided Automatic retests is on for the GitHub integration. Odin then:
  1. Checks out your repository at the merge commit
  2. Extracts the code change the PR introduced (the diff between its base and head)
  3. Reviews that change against the original finding — is the root cause actually addressed, is the fix complete, can it be bypassed, and does it introduce any regressions?
The review looks past the symptom to the underlying cause (for example, SQL injection means checking for parameterised queries, not just that one string was escaped), and reads the surrounding files to confirm the fix holds across every code path.
The retest reads a snapshot of your code at the merge commit to run the review, then discards it. It never writes to your repository — no commits, no comments, no pull requests.

​
Retest outcomes

A retest resolves to one of three outcomes:
Fixed & Retested is the one status only Borg can confirm. An inconclusive retest leaves the finding open so you can adjust the fix and merge again, or move it to Open for Retest for Borg’s analyst team to verify by hand.

​
Following a retest

You don’t have to watch for the result — it surfaces across the Findings UI as it happens.
  • In the findings list, a chip appears next to the finding’s title: Retesting while the review runs, then Verified or Retest failed once it completes.
  • On the finding detail, a banner reports the same states — a fix being retested, a verified fix, or an incomplete fix that needs revision. When a finding is waiting on a fix, the banner instead prompts you to link a pull request and merge it.
  • Click View retest for the full picture:
    • The outcome and the reasoning behind it
    • A How this retest ran timeline — the pull request that triggered it, followed by the code review step and its verdict
    • A Spotted while retesting section listing any related issues Odin noticed while reviewing the change, each with the file, line, and a short description
Issues in Spotted while retesting are observations attached to the retest, to give you a heads-up — they aren’t raised as new findings automatically. Flag anything worth tracking to Borg’s analyst team in the finding discussion.

​
When a retest doesn’t run

A retest is skipped, rather than run, when:
  • The finding has no linked pull request — there’s no merged code change to review. Link a PR first.
  • The PR was merged before it was linked — linking a PR that’s already merged doesn’t retest retroactively. Move the finding to Open for Retest yourself when you’re ready for Borg to verify it.
  • Automatic retests is off for the GitHub integration, or the finding is already Fixed & Retested.
  • The finding is in Needs Revision. Resume mitigation first, then merge your next fix, so the retest fires on the new change.
  • Your organisation is out of credits and auto-deposit is off. The retest is skipped and shown as such on the finding; top up or enable auto-deposit under Billing, then merge again or move the finding to Open for Retest.

GitHub integration

Connect GitHub and turn on Automatic retests

Findings

Track findings through the full remediation lifecycle