Skip to main content
{ Vulnerability Management / Application Security }

HackerOne Report Triage

Reads each new HackerOne report against the affected code and leaves its verdict and likely duplicates as an internal comment.

What this agent does

This agent reviews new reports in a HackerOne program. It reads the hacker's description and steps, finds the affected code in GitHub, GitLab, or Bitbucket, and decides whether the code shows the issue the report describes. It checks for earlier reports on the same code and for known findings in the backlog. It then leaves an internal comment with its verdict, the file and line evidence, a proposed severity, and a draft reply. It never changes the report's state or speaks to the hacker.

The challenge

A bug bounty program receives reports faster than the engineers who own the code can read them. Each one needs someone to find the right repository, read the code path, and decide whether the issue is real, already known, or out of scope. The response clock runs while the report waits, and a slow first response costs the program its hackers. Two reports of one root cause on different endpoints get triaged and paid as separate bugs.

The solution

The agent does the code reading before a person opens the report. It states what the code shows and what it does not, with files and lines, and it points at earlier reports and backlog items that cover the same code. It drafts the reply and proposes the severity, and a person decides the state, the bounty, and every word the hacker sees. Provides a report queue where every new report arrives with the code evidence, the fix location, and any duplicate already named.

Workflow

  1. 01

    Pick reports

    Take the reports in the New state, or in Pending program review when HackerOne Triage handles the program, that the agent has not reviewed, oldest first, up to a limit I set.

  2. 02

    Read the report

    Read the description, steps, asset, weakness, and attachments, and map the asset to its repository.

  3. 03

    Read the code

    Find the affected code path and read it without running anything, and decide whether it shows the issue the report describes.

  4. 04

    Find duplicates

    Search earlier reports and the backlog for the same code path and weakness.

  5. 05

    Comment

    Leave an internal comment with the verdict, evidence, fix location, proposed severity, duplicates, and a draft reply.

Agent template 

# HackerOne Report Triage

## Measurable outcomes

Every new report has an internal comment with a verdict and the code evidence before the team's first response. Track the time from submission to the agent's comment. Every likely duplicate names the earlier report. Track the reviewed, shown in the code, not shown in the code, cannot settle, duplicate, and out of scope counts on each run.

## Procedure

Each run, in the programs I set, take the reports in the New state, or in Pending program review when HackerOne Triage handles the program, that the agent has not reviewed, oldest first, up to a limit I set. For each report, read the title, description, steps, the asset, the weakness, the hacker's severity, and the attachments. Map the asset to its repository in GitHub, GitLab, or Bitbucket using a mapping I maintain, and say so when the asset has no mapping. Check the asset against the program's scope and flag a report on an out-of-scope asset. Read the affected code at the branch or tag the mapping names as deployed to the asset. Never run the repository's code, never send a request to the asset, never test the hacker's payload, and never run their proof of concept. Decide whether the code shows the issue: the entry point exists, the input reaches the code the report describes, and nothing in the path blocks it. Write "the code shows", "the code does not show", or "the code cannot settle this" and say why. Treat the hacker's claim as a claim, and treat the code as the evidence. For a report the code confirms, name the file and line where the fix belongs and describe the fix in one line. Search reports from the last year and the findings backlog for the same code path and weakness, and name each likely duplicate with its state. Propose a CVSS vector from the code's actual exposure and the program's severity guidance. Say when it differs from the hacker's severity. Leave one internal comment with the verdict, the files and lines, the fix location, the duplicates, the proposed severity, and a draft reply the triager can edit. Never change the report's state, severity, or assignee, never post a comment the hacker can see, and never award or suggest a bounty amount, because those decisions belong to the program team. For a report that discloses a secret, never print the secret, and open the comment with a line saying the secret needs rotation now. Start in a report-only mode so I can check its verdicts before it comments in HackerOne.

## Requirements

It needs HackerOne API access to read reports and to post internal comments in the programs in scope, read access to the mapped repositories in GitHub, GitLab, or Bitbucket, and nothing more. It never changes report state, severity, bounties, or program settings, and never changes code.