How to build bug bounty report triage

What matters here

• Check for duplicates first. A large share of reports describe something already reported or already fixed.
• Find the owner from the affected asset, not from whoever is on the security rota.
• Size on what an attacker could really do here, not on the severity the researcher picked.
• Track the program's promised response times and warn before they slip, not after.
• Close the loop with the researcher. The ones who hear back send the next good report to you, not to a blog.

Who this is for

You run product security or a bug bounty program. Reports arrive faster than the team can read them, and the hard part is getting engineering to own the valid ones.

How it works in practice

From a researcher submitting a report to the fix shipping and the researcher being paid.

1. 1

   A new report arrives

   With the affected asset, the steps to reproduce and the researcher's suggested severity.

2. 2

   It is checked against past and open reports

   Same asset and same kind of issue, or the same steps, flagged as a likely duplicate for a person to confirm.

3. 3

   The owning team is found

   From the asset: the repository, the service and the team that deploys it.

4. 4

   The report is sized on real impact

   What data or actions it reaches, whether it needs a signed-in user, and whether it is exposed to the internet.

5. 5

   A ticket goes to the owning team

   In their tracker, with the steps, the sizing and the date the fix is due.

6. 6

   The researcher hears back on time

   First response, confirmation, fix and payout, each against the time the program promises.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then map assets to owners

   A confirmed report with no owner never gets fixed.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are HackerOne, GitHub or
   GitLab, Jira, ServiceNow for the service catalogue, Slack and
   Snowflake, or whatever we run in those seats. Before you plan anything,
   tell me which of them are already authenticated in the workspace,
   because I do not want a connector stubbed that I have not
   authenticated.
   
   Build the map from each domain, endpoint and app in the program's
   scope to the service, the repository and the team that deploys it.
   List anything in scope that maps to nobody. That list is the first
   thing to fix.

2. 2

   Catch duplicates before anyone reads in full

   Duplicates eat the team's reading time.

   Headless skills build-workflow

   Copy

   Use build-workflow. For each new report, compare it with open and
   closed reports on: the affected asset, the kind of issue, and the steps
   to reproduce. Also check open Jira tickets for the same asset and issue,
   since the team may already be fixing it.
   
   Flag a likely duplicate with the matching report linked, for a person
   to confirm. Do not close reports as duplicates on your own: a near
   match is sometimes a second, different issue on the same page.

3. 3

   Size on real impact

   The researcher's severity is a starting point, not the answer.

   Copy

   Size each confirmed report on:
   
     What data or actions it reaches
     Whether it needs a signed-in user, and what kind
     Whether the asset is exposed to the internet
     Whether the issue is being used against us now, from our own logs
   
   Record both the researcher's severity and ours, with the reason for
   any difference. The researcher will ask, and a reason keeps the
   conversation short.

4. 4

   Route to the owning team, with a due date

   Security can confirm a report but can't ship the fix.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then open a ticket in the owning team's Jira project
   with: the steps to reproduce, our sizing, the affected service and
   repository, and a due date from the program's fix target for that
   size.
   
   Post the ticket to the team's Slack channel. If a fix needs a change
   in GitHub, link the repository. If the asset maps to nobody, escalate
   to the security lead as an ownership problem instead of filing the
   ticket into a void.

5. 5

   Keep the researcher updated on time

   Researchers who hear back send the next report to you.

   Copy

   Track each report against the program's promised times: first
   response, confirmation, fix and payout.
   
   Warn the security lead in Slack before any of them slips, with the
   report and the owner. Post updates to the researcher in HackerOne as
   the ticket moves: confirmed, fix in progress, fixed, ready to retest.
   
   Report monthly: reports received, share duplicates, time to first
   response, time to fix by size, and promised times missed.

6. 6

   Validate it, then hand the rules to product security

   Because sizing and due dates are policy, owned by people.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run it alongside the team for two weeks, flagging
   duplicates and suggesting sizes and owners, with every decision made by
   a person, and compare.
   
   Then open the same workflow in Tray Build so product security can
   change the asset map, the sizing rules and the due dates in the visual
   canvas.

What it connects to

Reports come from researchers, and fixes ship from engineering.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides