Severity levels
Each finding gets a severity based on exploitability and impact. Severity is set by Borg’s analyst team or by Mjolnir, and is anchored to a CVSS base score:| Severity | CVSS range | Description |
|---|---|---|
| Critical | 9.0 – 10.0 | Immediate exploitation risk. Requires urgent remediation. |
| High | 7.0 – 8.9 | Significant risk with a realistic exploitation path. Address promptly. |
| Medium | 4.0 – 6.9 | Real issue but harder to exploit or lower impact. Plan remediation. |
| Low | 0.1 – 3.9 | Minor issue or defence-in-depth improvement. Fix when practical. |
Finding status
Each finding moves through a status lifecycle that captures the back-and-forth between your team and Borg as a fix is applied and verified:| Status | What it means | Set by |
|---|---|---|
| Reported | The finding has been published to your team and is awaiting triage | Borg |
| Acknowledged | You’ve seen the finding and accepted the risk for now; not actively being remediated | Your team |
| Mitigating | Remediation is in progress on your side | Your team |
| Open for Retest | You’ve applied a fix and want Borg to verify it | Your team |
| Needs Revision | Borg retested and the fix is insufficient (or introduces a new issue) | Borg |
| Fixed & Retested | Borg has verified the remediation is effective | Borg |
Changing the status
From the finding detail view, Member, Admin, and Owner roles can move a finding between client-controlled states:- Reported → Mark as Mitigating, or Acknowledge
- Acknowledged → Resume Mitigation
- Mitigating → Mark as Open for Retest, or Acknowledge
- Open for Retest → Reopen as Mitigating, or Acknowledge
- Needs Revision → Resume Mitigation, or Mark as Ready for Retest
Finding identifiers and PR linking
Every finding has a unique, human-readable identifier made from your organisation’s finding prefix and a sequence number — for exampleBORG-12. The identifier is shown in the finding header and on every list view, and it’s how findings get connected to your engineering work.
Linking pull requests to findings
When the GitHub integration is connected, Odin watches incoming pull requests for finding identifiers in three places:- The branch name (highest priority)
- The PR title
- The PR body
{PREFIX}-{N} token matches a finding in your organisation, that PR is automatically linked to the finding. You see linked PRs as chips in the finding header, and the source (branch / title / description) is recorded so you can tell where the link came from.
As the PR moves through GitHub (opened → closed → merged → reopened), Odin tracks the state on the linked entry. Merging a PR does not automatically transition the finding to Fixed & Retested — in develop → staging → production workflows, merging to develop doesn’t mean the fix is live in production. Move the finding to Open for Retest when you’re ready for Borg to verify.
When a PR is linked to a Reported finding, Odin auto-transitions the finding to Mitigating — a clear signal to Borg’s analyst team that work is in progress.
Copy branch name
The finding detail header has a Copy branch name action that copies a ready-to-use git branch name combining the identifier and a slugified title, for example:git checkout -b and the resulting PR will be linked automatically once it’s opened.
You can also use the identifier directly in a PR title or body — for example BORG-12: fix SQL injection in login form or a body that mentions Fixes BORG-12 — and the same auto-linking applies.
What’s inside a finding
Every finding contains:- Title and severity: a one-line summary plus severity label and CVSS score
- Type: when set, links the finding to its CWE class
- Affected assets: the domains, endpoints, or resources where the issue applies
- Description: what the vulnerability is
- Impact: the business consequence if it were exploited
- Details: technical details, including how the issue was identified
- Remediation: step-by-step fix guidance
- Proof of Concept: for Mjolnir findings, the request/response evidence captured during exploitation
- Code Reference: for Mjolnir findings with a code pointer, the exact file and line in your repository
- Status history: every status change, who made it, and any attached comment
Revisions
Findings are immutable. Whenever Borg’s analyst team or Mjolnir updates the content of a finding (after retesting, for example), a new revision is created and the revision number in the header increments. You always see the current revision, but the full history is preserved on Borg’s side for audit.Views
The Findings page has two view modes you can switch between in the toolbar:- List: the default tabular view, with filters, sort, and a detail panel
- Heatmap: a severity-by-status matrix showing how findings are distributed across your portfolio
Filtering and search
Filters at the top of the page narrow your view:- Severity: select one or more of Critical, High, Medium, Low
- Status bar: click any status to filter to it; Fixed & Retested and Acknowledged are hidden by default
- Source: filter by Mjolnir, Manual, Import, or Watchdog
- Pentest: scope findings to a specific pentest engagement
- Asset: scope to findings affecting a specific asset
- Repository: for Mjolnir findings, filter by source repo
- Search: free-text search across titles and descriptions
- Sort: by severity (high → low or low → high) or by date
Bulk operations
Select multiple findings with the row checkboxes, or navigate withj/k and toggle selection with x. With a selection active, a bulk action bar appears at the bottom of the page:
- Mark as Mitigating — move all selected findings to Mitigating
- Mark as Open for Retest — move all selected findings to Open for Retest
- Export selected — download the selected findings as CSV, Markdown, or JSON
Bulk operations require the Member role or higher.
Discussion and activity
Every finding has a right-hand rail with two tabs:- Discussion: a threaded conversation with Borg’s analyst team. Use
@to mention a teammate, attach files, and resolve threads when a question is settled. New replies can trigger email notifications based on your discussion preferences. - Activity: a chronological feed of every status change, revision, and integration sync for the finding
Mentioning teammates, findings and projects
Typing@ in a discussion opens a search grouped into People, Findings, and Projects (pentests). Start typing a name, finding title or identifier, or project name to filter each group.
- People mentions notify the teammate, as they always have.
- Findings and Projects mentions are links only and notify no one. A mentioned finding shows as a chip with its current status and severity, and a mentioned project links through to its findings.
Exporting findings
Click Export in the page header to download your current filtered view. The export respects every active filter, so narrow down by severity, status, source, etc. before exporting.| Format | Description |
|---|---|
| CSV | Spreadsheet-friendly format with columns for identifier, title, severity, CVSS, status, source, description, business impact, details, remediation, and timestamps |
| JSON | Machine-readable format with the same data, useful for scripting or importing into other tools |
| Markdown | Human-readable format with each finding as a section, including metadata tables and full descriptions |
Pushing findings to your issue tracker
If you’ve connected Linear, Jira, GitHub, or GitLab, you can push any finding directly to your issue tracker with one click. The finding title, severity, description, impact, and remediation are all included, plus a deep link back to the finding in Odin. You can also enable auto-ticketing so that issues are created automatically as new findings are reported. Set up your integration at Management > Integrations.Set up integrations
Connect Linear, Jira, GitHub, or GitLab
Step-up verification
Some actions require re-authentication