From a triager's point of view, bug bounty programs are truly a wonderful world. One report is just a 5 min video, showing a cracked Burp and Notepad texting you, "it works - BOOM 💥" - yet this is a good finding that no external pentesters, no threat modelling architects and no SAST/DAST/SCA tools have managed to identify. Another report could come at 7PM on Friday describing a "critical criticality" vulnerability, that is some information disclosure with no real security impact. Managing a quality and fair program requires technical knowledge, patience, communication and coordination skills. Sometimes there are uncertainties that can be frustrating. Over time I've collected a list of tips to make the life slightly easier.

The Wonderful Bug Bounty World

The idea of having thousands anonymous independent security researchers from around the world hacking you and paying them for findings works since 1985. These days, functional bounty platforms make the process smoother, and it works. On HackerOne alone, hackers surpassed $300 million in all-time earnings.

From my personal experience, the RoI of running a bounty program for the organisation is usually very good. In my opinion, even in a busy security professional's agenda, it makes sense to dedicate some time for checking the bug bounty program's reports - it helps to learn new ways of thinking as well as exploitation techniques. Even when not hunting for bounties, I still find myself following bug bounty blogs, writeups and news, such as Intigriti Bug Bytes or Hacktivity.

While myself not being too active in the security research scene due to other priorities, I spent years pentesting and writing reports. I love and appreciate the quality of a well written vulnerability report - it saves time and helps to convey the impact. However, the report quality in bug bounty reports vary, and usually, there's some extra effort required to triage, understand and verify the bug. On top of that, there are other complexities that come into play. This is a list of things that I went through to end up in a state where the triage process is now less troublesome for me. My point of view is of a triager / admin but perhaps useful for the reporters too - all just to make everyone's life a little bit easier.

Giving the Policy Some Love

The policy is important because it defines the scope, award amounts but it should also cover some edge cases to reduce unclarity. What if the submission contains a report of a breach DB leaked in darknet? What if the reported vulnerability is out of scope, but still valid? What about bugs that are already known from other sources and are already in the vulnerability management process? Having answers to questions like these documented helps to make the decisions faster. I try and keep the policy detailed and up to date.

Good PoC || GTFO

Dear reporter, would you please add the HTTP requests and responses in plain text in addition to that 5 min exploit demo? I find it easier to ask to improve the PoC rather than spending time to put pieces of the puzzle. Sometimes some exploitation steps are missing. Sometimes statements like "this results in serious consequences!" need some more backing arguments. Often I find that platform services like paid triage / validation helps to save time for that initial review.

CVSS Doesn't Always Have to be a Friend

CVSS is a standard, but it has flaws, and it is being criticized. Numerous times I found juggling with the CVSS parameters trying to assign to score to a vulnerability while finally saying screw it, and assigning a custom score with explanation. Allowing some flexibility and escaping out of the CVSS scoring system is useful.

Composure and Communication

Bounty beggars, a.k.a. beg hunters, are annoying. Negotiations, demagogues, even silly jokes or something like "other programs just fixed it and rewarded me $int.". Sometimes it's cultural differences, sometimes personalities, but these discussions are always a distraction. Over time I learned that empathic, professional and respectful communication is the key. The main algorithm always remains the same - if valid bug: accept; else: reject.

Zero Trust, 100% Verify

Bug bounty reports are untrusted input to the brain, that needs to be sanitized. It needs to be checked against past duplicates. If there's at least a mildest suspicion or unclarity, always reproduce. I had a good lesson - supposedly critical bug report which was quite convincing, only after rolling my sleeves up and launching Burp I found that it actually can't reproduce it - was a human mistake by the reporter.

Root of the Problem

Hackers come up with ways to "scale" their bounties. For example: find a good bug in $3rdPartyService and then check your bug bounty DB and see which programs are using that vendor / system. Then report and multiply the profit, until vendor ships the fix. Is this fair? In any case, I try to find out about the source of the bug as much as possible. Has it been reported to the vendor yet? Are there any writeups or reports? Occassionally I contact the vendor myself to make sure they are aware of this and just for their advice on the matter.

Lean Towards Bounties

Whenever there's unclarity, e.g. slightly off-scope finding, but the bug is valid, the communication is good and the report is well-written, I tend to lean towards paying the bounty (possibly, an accordingly adjusted amount). That's just the best approach that leaves both the admin and the hacker happy, hopefully incentivizing the latter to find more and better bugs.

Data-Backed Award Amounts

Data is truth. Platforms have the benchmarks publicized at it only makes sense to make use of that data. Having larger-than-usual bounties but asking for more quality is a good strategy for getting some positive attention.

Grabbing the Attention

Platforms seem to come up with various new features such as campaigns - another way to grab more attention to something you need and make the program more lively. Having the security.txt file discoverable also helps in case the program is private.

We're All One Team

When faced with a problem or the neccessity to make a difficult decision, checking with the internal team or the developers / engineers multiple times helped me to bring a fresh perspective to the problem and make that decision. The ultimate the goal is to squash the bugs, and it's fun to do that in a team!