Bug Bounty Triage

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. 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 g b from anywhere to get here. 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. Reports filed before the webhook was connected never arrive on their own. Paste a HackerOne report URL (or the numeric id) into the box at the top of this page and click Triage. Odin pulls the report with your Read only API token and queues a run if that asset is armed.

​

Triaging a report

Open a report and click Triage now, or paste a report URL on the inbox. 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. 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.

​

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. 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. 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. Triage now and auto-triage both need a ready billing account. If the prepaid balance is empty, Odin will not start the run — top up under Billing first. A webhook still stores the report; only the automatic triage is skipped.