Bug Bounty Program Improvements

Bug Bounties have given me a good chance to try out the few things I know and learn the giant’s share along the way. I was able to meet some like-minded people from my country who have given me some great insights. I have been able to learn a couple of things and a good number of technical concepts, but the most important of them all is about communication and professionalism.

bug bounty

Sadly, not all journeys are perfect. Bug bounty most certainly isn’t either. From the report writing needed, I have developed a better way of writing articulate and concise reports. Nailing every needed hammer to showing impact and criticality, but most important of all, be professional and understandable.

It is very clear that misunderstanding and lack of proper communication have been the key to disagreements between researchers and programs/triagers.

As much as programs expect the best of reports and proper behavior from researchers, some may not always return the favor in a couple of ways. From my previous experiences and online complaints, I have come up with a couple of ways programs lack professionalism and let down those holding the fort-like bosses! Let’s dig in:

Poor communication

Probably the most annoying thing some programs do. I however have a fair share of experience on programs lacking this. No feedback about anything. The same level of communication expected when a researcher is asked to clarify on a report is the same when a researcher asks for clarification about progress and whatnot.

poor communication

Receiving a report and going quiet while ignoring tons of messages then only responding while awarding a bounty is not cool. So not cool. Program managers should talk to their security team and emphasize the need for proper communication.

Not understanding a vulnerability

While researchers may try their best to explain an issue, experience on the receiving end is a necessity. If the security team does not understand the vulnerability or impact, it going to be a real hustle. I have witnessed cases where the security team claims an SQL injection is not possible and closes the report just because they can’t verify it. Only to reopen it later on after a mediation request. Security teams do not understand that different vulnerabilities that are solved differently but lead to the same level of compromise are to be handled differently.

A good way of approaching this sort of situation for programs with this sort of thought is reporting a vulnerability once the previous one is resolved. This will make more sense to them.

Fixing an issue before triage(and going silent)

Don’t get me wrong. In cases where a researcher sheds light on a critical vulnerability, it is logical to act fast and fix/remediate. However, when this is done before triage and the program team goes silent, this is a clear sign of unprofessionalism. Leaving the reporter to explain to the triager how “the vulnerability was there a few minutes ago” is just not fair. Program teams should at least communicate that they saw the impact and acknowledge it as they do a quick fix.

If a program has a habit of doing this, you better “kazam” and do a screen recording clearly indicating the timestamp during vulnerability confirmation.

Reduced payouts

When the teams fail to understand a vulnerability impact and payout less for its actual worth. Reducing an RCE impact just because the reporter used the commands “id” or “whoami” on the PoC instead of uploading an interactive web shell. Understanding impact makes for better judgment and more stable and well-deserved payouts.

Developer/team mistakes

A memorable one was when I got hold of a subdomain and got hold of a full project backup. An SQL injection followed shortly after. However, I was slammed with a “The developer was supposed to have taken this subdomain offline but forgot to do so” excuse.

This issues were later on fixed within an hour and the reported severity diminished to a mere low. Just because it was meant to be offline. Personal data retrieved from the SQLi dated a few minutes back, proving to be very recent and active. But hey, the program is always right, right?


Researchers and not always right. But neither are programs. Finding the common ground and adhering to some professional behavior will however make for a good relationship and increase chances of program loyalty and increased/better reports.

Not all issues have been highlighted. But only the most common.

Practice fairness.

Stay safe, whom it may concern.

search previous next tag category expand menu location phone mail time cart zoom edit close