How Borg pushes findings to Linear, Jira, and GitHub automatically

Here's what usually happens after a pentest: someone sends a PDF. That PDF gets forwarded around, maybe uploaded to a shared drive. A few findings get turned into tickets manually. The rest sit unread until the next audit asks about them.

We built the findings workflow to kill that.

Findings belong where work happens

Mjolnir tests the application and returns verified findings with reproduction steps. Odin is where those findings live: severity, affected asset, proof of exploitation, suggested fix. But a finding sitting in a security dashboard is still a finding nobody is working on.

So Odin pushes them into the tracker your engineers already have open. Linear, Jira, and GitHub Issues. The issue arrives carrying the finding title, a severity label, the description, reproduction steps and the suggested fix.

No copy-pasting from reports. No context lost in translation.

How to enable issue sync

Every tracker connects from the same place: Management > Integrations in the Odin sidebar. Each one has its own connect flow.

GitHub

1. Click Connect next to GitHub and authorise the Borg Security GitHub App.
2. Select the GitHub organisation or account that owns your repositories.
3. Select the repository where issues should be created.
4. Turn on Issue tracking on the GitHub card.

Step four matters. Repository access and ticketing are separate switches: without Issue tracking enabled, GitHub is connected for code context only, for example Mjolnir whitebox testing. You can change which repositories the app can reach at any time from your GitHub organisation settings.

Linear

1. Click Connect next to Linear and authorise the Odin app through Linear's OAuth flow.
2. Choose the Linear team that should receive issues.

Under Issue customization you can then place every synced issue into a specific Linear project, and set the workflow state new issues open in. Leave that unset to use your team's default.

Jira

1. Click Connect next to Jira. You are redirected to Atlassian to authorise the Odin app.
2. Choose the Jira Cloud site where issues should be created.
3. Select the Jira project that should receive security findings.

Issue type and component are set afterwards under Issue customization, so findings can land as a custom type such as Vulnerability rather than the project default. Jira Cloud only. Jira Server and Jira Data Center are not currently supported.

What to set after connecting

Three settings decide how much lands without anyone touching it:

• Auto-create tickets. On, and an issue opens as soon as a finding is reported. Off, and you push findings by hand from the finding view.
• Minimum severity. Only findings at or above this level trigger automatic creation. It defaults to Medium. Raise it to High or Critical if you want the board to stay short.
• Default assignee, labels and team mapping. Map your Borg users to tracker users and the assignee follows the finding across. Linear and Jira also expose a priority mapping table, so Critical, High, Medium and Low become the priorities your team already sorts by.

Already sitting on findings from before you connected? Use the Sync now banner on the integration card to backfill them. Individual findings also have a Push to button, and the Findings page has a bulk action toolbar for pushing several at once.

Trackers are not exclusive. Connect Jira alongside Linear and Odin keeps findings and status changes aligned across both.

Status stays in sync both ways

Move a linked issue to In Progress in your tracker and the finding moves to Mitigating in Odin. Change the finding in Odin and the issue moves with it. Matching runs on the state name first, falling back to the state's underlying type where your workflow is customised.

One deliberate exception: Fixed & Retested is the one status a tracker can never set. Dragging an issue to Done signals that your fix is ready for Borg to verify, and the finding moves to Open for Retest rather than closing. Closing the loop is a retest, not a checkbox in your sprint board.

Close the loop

When a fix is ready, Mjolnir retests it and confirms whether the issue is actually gone. On GitHub, merging the linked pull request starts that on its own: the retest inspects the merged change and reports whether the fix held.

That is the difference between a ticket somebody dragged to Done and remediation you can evidence.

Security findings that live in PDFs don't get fixed. Findings that show up in your sprint board, with a retest behind them, do.