Eating Our Dogfood - Running a Bug Bounty Program on a Bug Bounty Platform

The speakers explain why HackerOne reports its vulnerabilities through its own product: the team that triages reports feels the same friction that customers feel. They say the gap between finding a bug and fixing it keeps growing, and that the biggest delays come at handoffs, especially between triage and engineering. By keeping triagers and engineers in one shared Slack thread for each report, they say the share of reports validated within a 24-hour target rose from about 62 percent to about 97 percent, using the same team.

The middle of the talk covers automation they tested on their own program. A routing agent assigns reports to owning teams only when its confidence clears a threshold of about 90 percent, and it posts every other report to a shared channel so low-confidence cases stay visible. Another agent replays reproduction steps and reruns them after a patch. Two case studies follow. In the first, an unvalidated sort parameter let a researcher inject Painless scripts into a shared Elasticsearch cluster; it was fixed in about seven days, and no customer data was accessed. In the second, an asynchronous PDF export ran with background-worker permissions and could email internal triage notes to a requester who lacked access. The fix made exports run under the requester's own permissions.

The closing lessons are to automate intake rather than judgment, to ask where else an unvalidated input reaches the same component, to check permissions in background jobs, and to share disclosed reports while respecting researchers' choices about disclosure.