> ## Documentation Index
> Fetch the complete documentation index at: https://docs.borghq.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Bug Bounty Triage

> Triage HackerOne reports before they reach your queue

Bug bounty programs generate a lot of reports, and most of the work is deciding which ones are real. **HackerOne** in the sidebar is an inbox of your program's reports, each carrying a triage attempt to reproduce the issue against the live system it names.

<Info>
  This page needs a connected HackerOne program. See the [HackerOne integration](/platform/integrations/hackerone) for the connect flow and asset mapping.
</Info>

Triage output is advice for your team. Your program stays the system of record.

## The inbox

Every ingested report is a row, newest first. Press <kbd>g</kbd> <kbd>b</kbd> from anywhere to get here.

| Column    | What it shows                                                        |
| --------- | -------------------------------------------------------------------- |
| Report    | Title, report number, the HackerOne asset, and the reported weakness |
| Severity  | The severity the reporter claimed, or **Unrated**                    |
| State     | The report's current state in HackerOne                              |
| Triage    | Where triage got to, or **Untriaged**                                |
| Submitted | How long ago the hacker submitted it                                 |

Search by title or report number, and filter by state. The external-link icon on a row opens the report on HackerOne; clicking anywhere else opens it in Odin.

## Triaging a report

Open a report and click **Triage now**. The write-up is reproduced against the mapped live target and the result lands on the same page, so you don't need to keep it open.

The button is unavailable in two cases:

* **The asset isn't armed.** The report shows the exact asset string. Turn auto-triage on (or press **Triage now**) only after that asset has a live http(s) URL or a GitHub repo in [live targets](/platform/integrations/hackerone#program-assets-and-auto-triage). Nothing runs against a system you haven't authorised.
* **A run is already going.** One run per report at a time, so a second click while one is queued or running is refused rather than starting a competing run.

Once a run finishes, the button becomes **Triage again**. Re-triage after the reporter adds detail, or after you've deployed a fix and want to check the issue is actually gone. Every attempt is kept in **Run history** on the report, showing whether it was started by hand or by the webhook.

Reports can also triage themselves as they arrive, per asset. See [auto-triage](/platform/integrations/hackerone#auto-triage).

## Reading the verdict

A completed run gives a verdict, a confidence percentage, a severity, and a CWE, followed by an explanation of what the run did and what happened.

| Verdict             | Meaning                                                                   |
| ------------------- | ------------------------------------------------------------------------- |
| Confirmed           | Reproduced as described                                                   |
| Partially confirmed | Part of the claim holds; the rest didn't reproduce                        |
| Dormant             | The weakness is present but not currently exploitable                     |
| Needs prerequisites | Reproduction needs something the run didn't have, such as a valid account |
| Not reproduced      | The described behaviour didn't occur                                      |
| Needs review        | The result isn't clear-cut and wants a human                              |
| Not attempted       | No reproduction was made                                                  |

Depending on the verdict, the run may add:

* **Reactivate if**: the condition that would make a dormant issue exploitable, so you know what to watch for.
* **Dormant because**: why the weakness can't be exploited as things stand.
* **Blocked**: what stopped the reproduction, when something did.
* **Evidence**: the request and response from the run, plus proof-of-concept steps. Long evidence is marked as truncated.

The hacker's own write-up and impact statement sit below, as submitted. Attachments and the comment thread stay on HackerOne.

## Report states

The state column mirrors HackerOne: New, Pending review, Triaged, Needs more info, Resolved, Not applicable, Informative, Duplicate, Spam, and Retesting. Odin updates it when your program marks a report as triaged or closes it as resolved. Changing a state in Odin isn't possible. Do that in HackerOne and the inbox follows.

## Credits

Each triage run consumes credits, billed by what the run costs to execute, and appears as **HackerOne Triage** in your [credit ledger and usage breakdown](/platform/billing). Re-triaging a report is a fresh run and is charged as one, which is worth keeping in mind before you turn auto-triage on for a busy asset.