Bug Bounties in a Small Company

The E-mail arrived quietly in our support mailbox. Pretty good English, but clearly not the writer’s first language, and :

BUG : Password Reset Link Not Expire After Mail Change.

I found a token miss configuration flaw in…

Ok. Not the biggest deal of all time, but something that should be fixed. The submitter provided really great instructions on how to reproduce the bug and why we should care. I replied thanking the submitter and got this back:

Hi There
Is there any way to give me a bounty ?


Baboom. This sounds like the exact situation that Justin Jackson & Jon Buda asked about on this episode of Build your SaaS. We’re a small company. We don’t have a formal bug bounty or vulnerability disclosure program, but I find security fascinating, (at least from the outside), and know bug bounties are a thing. It would be nice to pay a bounty, but how much? What happens next? What if we refuse?

This is what we did, and how it played out.

It’s our first time

My business partner had seen the initial E-mail in the support system so he knew something was up. After a quick discussion about how bug bounties work and asking if he ok with paying something we made the decision to pay small bounties in the neighbourhood of $20 – $50 US per bug, depending on severity, available funds, and how many more reports came in.

I went back to the submitter and said that we could pay but as a very small company with an extremely limited budget he should not expect Apple-style bounties. They were happy with that arrangement, so I fixed the bug.

Then they submitted another but and I fixed that. And another. In all this person submitted 5 “bugs” of varying severity. Some we could barely class as problems but we looked at them all and patched any that needed patching. Some others made us re-think some of the user interface, especially around changing contact or login information, and make plans to change it later.

The reports were both submitted and fixed close together so we lumped everything into one payment. We paid about $100 US for the lot. The submitter asked for payment to go to a random PayPal address that was nothing like the name of the person we were dealing with, then send a screenshot of the completed payment. Pretty sketchy, but they were satisfied.

Writing a Disclosure Policy

I have looked at the bug bounty programs on HackerOne and Bugcrowd, and decided to make a page to point people to when they ask about bug bounties, and to lay down some ground rules, (like don’t DDoS us!). We used Mozilla’s Bug Bounty program and some others from respected companies as inspiration. We included a requirement for detailed reproduction steps, why the bug is actually a problem. This makes it relatively easy to triage any reports we get.

Good thing we wrote a disclosure policy, because as we were finishing up with the researcher another E-mailed us with some bugs, and asking if we have a bug bounty program, and we were was able to respond with a link to the new disclosure page.

Bounty Hunter #2

On Build your SaaS Jon asked if you paid, would you end up on a list of companies that pay, then be flooded with submissions. The answer seems to be at least sort of yes. As we were finishing up with the first submitter another showed up. Submitter #2 had better English than Submitter #1, and was much more thorough. I suspect these two were somehow connected, whether they both post to the same forum or both work for the same person I don’t know, but it felt like we went from a Level 1 pen-tester to Level 2. Submitter #2’s bugs were more creative and more serious than Submitter #1’s. Since #2 showed up just as we were finishing with #1 we were short on cash for bounties, but were honest about it and paid what we could. This seemed well received. I believe we paid about $200 US to Submitter #2.

After once we were mostly wrapped up with Submitter #2 things were quiet for a while, then he submitted one more issue about a week later which we fixed, and since we hadn’t sent the payment yet added to the payment for all of his bugs. Payment was the same sketchy unrelated PayPal + screenshot of the payment method.

Was it worth it?

Short term answer: Yes. At least one of the bugs that Submitter #2 found was serious enough that it warranted immediate attention, so on that level it was worth having someone report it instead of exploit it.

Overall answer: Still yes. For the cost of about $300 US and about a week of my mornings we got outside feedback that made us reconsider some UI decisions from a security standpoint and learned about Content Security Policies and other security headers. Also, the submitted bugs and our knowledge of our systems led us to other related bugs that we fixed as well, so it was a bit like a 2-for-one sale on bug-fixes. And now we have tests written that should prevent these bugs from re-appearing.

Of course I would prefer that we found problems internally before they were deployed, and problems would be discovered at convenient times, but that’s not the real world and I’m happy the problems were found and fixed, and we improved our systems and knowledge as a result.

This all happened back in February and March, and we haven’t had any reports since.

Further Steps

I hear there’s an ISO standard for security disclosure best practices, (apparently ISO 29147 and ISO 30111). I plan on looking them up and do what we can to follow them while balancing that with continuing to improve our product. With a small team it’s always a question of balance, so we’ll keep doing our best!

Has this happened to you?

If I had to bet, I would bet that a lot of small businesses are approached by security researchers this way, but none of us have dealt with them before, we don’t know what to do, and are worried it will be a scam or that we’ll end up on a list and end up spending all our time dealing with bug reports. This feels like something we should talk about.

Whispers about “Bug Bounties in a Small Company

  1. This is interesting; and I say because I am trying to understand how best to approach a bug bounty opportunity with a company who, based on their website, likely also does not have an established program or cash to support one. But don’t judge a company by their website, right??? Some don’t change over the years because it works… Some are start-ups with no money but have fantastic looking sites.

    Anyway… I found what I consider 2 critical vulnerabilities. I am a customer of a service provider who recently sold their business to another competing service provider in the area. The acquiring service provider uses an outside billing company, to which I’ve already been subscribed to as part of their acquisition process. During the process to take ownership of my account, I discovered that billing company accidentally exposes customer details (name, billing address, service address (if different), email, account balance) under certain conditions and is easily reproducible. Further investigation shows that I would be eligible (but didnt) to take ownership of other’s accounts who have not yet opted to do online payments.

    So about the bug bounty….. What if they say no. I’m not going to exploit or extort them, that would be illegal and I’m not in that business. I also don’t want to do their job by helping secure their platform for free… I’m also not in that business. My name and address are already public information, and they don’t yet have my email address in their system. So I could hold out in hopes they come around.

    I would prefer not to offer up any specifics until the company agrees to a bounty. I fear that a company could, in bad faith, use what little info I offer them to evaluate the severity and come up with a cash offer, only for them to use that info to locate and fix the issue on their own… It is a risk in any scenario where there is no established bounty program.


  2. @Anonymous: If the company doesn’t have an established bug bounty program then you probably shouldn’t expect a bounty. Offering some info on the vulnerability, with a “I’ll give you more details for cash” could be seen as extortion depending on who reads it.

    If I was receiving your report ideally I would want all the info, then I would fix it and offer you what I could afford. If you did the “here are some details, more info available on payment” I might offer a bounty, but I probably wouldn’t pay until it was fixed. It looks like many companies pay only once a bug is fixed, (look at closed issues on HackerOne or BugCrowd to see timelines).

    My advice is: be careful not to come across as trying to extort, and be ready to get nothing other than the feeling you did the right thing. If you want a career as a penetration tester or bounty hunter, and the company refuses to pay anything, then there’s no contract between you & them – so no NDA. Maybe you can write up a case study that’ll help you gain visibility or sell your services.

What do you think?

Your name and E-mail address, and of course a comment, are required. I won't do anything evil with your E-mail address.

If you so desire, you may use these tags in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Made by John