Yesterday Randy Westergren wrote this blog post: United Airlines Bug Bounty: An experience in reporting a serious vulnerability. I do not know Randy and do not think he did anything wrong but his post is a perfect example of why companies I talk to are afraid of implementing bug bounty programs.
He hit the trinity of why companies fear bug bounty programs in one post:
- Their development cycle wasn’t fast enough for the researcher.
Is six months a “more than reasonable time frame”? On the surface sure but unless you go to their planning games, know their regulatory commitments, roadmap and backlog you can not say that for sure.Most companies have enough internal and contractual pressure on their development cycles to have a researcher who is “helping” add another source.
- The researcher involved the press:
Companies do not want to be in the press for having poor security. So sure when he contacted the press they fixed the issue but it didn’t win him or security researchers any friends at United.Companies do not want to manage a bug bounty program as a fire fighting exercise. They want to intake the bugs into their regular development cycle and work them in their normal process.
- The researcher went “rogue”:
He wasn’t going to get compensated for his work since it was a duplicate so the only kind of compensation he could still get was to go public. Companies cant pay for every duplicate bug found and it only takes one researchers to go rogue to sour a bug bounty program for a company.
While I do not fault Randy for his blog post or thought process a company gives up a lot of legal cover by running a bug bounty program. If they do not perform to a researchers expectation and they get called out in this manner is a reason for them to think twice about their program and if it is worth it.
