What I learned From Managing Bug Bounty Program

One of main responsibilities is managing bug bounty. On paper, the workflow looks simple:

I triage the security issue
Respond to the reporter
Log the report into the internal ticketing system, inform engineering team
Prioritize the issue
Track the ticket.

All those activities involve technical knowledge, judgement and stakeholder management.

For every report I have to decide whether the issue is valid or duplicate. If it's valid, I have to judge severity: critical, high, medium, low.

The researcher payout depends on my severity judgment. So, I need to be careful and double-check before deciding since it directly affects our budget.

When checking the report, I have multiple things that I need to manage:

Researcher expectations and communication

They want fast response and fair payout.

Sometimes I need to explain a triage or severity decision in detail. The explanation must be in a way that's respectful, not dismissive.

If I don't maintain well this part, researchers can stop reporting the issue to us.

Engineering Capacity

Engineering teams have roadmaps. I need to consider their roadmap when prioritizing the security issue.

Business Risk

Security issue report is not regular report. It contains actual exploitability, data exposure possibility, and customer impact.

Management Team

I need to keep the bug bounty manager and my direct manager informed. I need to inform what happen and what we need to do. Also thinking what report that they need.

The Cost

Say yes to everything will impact to our budget.

Good Triage Judgement and Trust

In my opinion, it needs three keys to make good triage judgement:

Clear guidelines from the bug bounty manager
Consistency in applying the guidelines
well-reasoned decision

These keys help security team build trust with researchers, engineering, and management alike.