Bug bounty programs are a way of engaging the worldwide community to help you improve your software, and to reinforce an ethical, open line of communication between that community and your software development team. In a nutshell, you offer a reward – typically a cash payment – when someone confidentially notifies you of a bug in your software. Broadly speaking, this forms a part of a penetration testing plan. Presumably, you have your own team testing for bugs also, but this acknowledges the fact that your team will never find every bug.

So, should you have one? In one word, maybe. You need to have a few things in place, and probably add a few more, before you can have a legitimate program. Here are some things to consider to see if a bug bounty program is practical within your organization:

Have a bug-fixing process in place already

You can’t even consider a program unless your team already has a documented, reliable process for accepting bug reports – perhaps from existing customers – and acknowledging and acting upon them. Generally speaking, acting upon doesn’t mean, “We’ll get to it in the next release,” but – especially in the case of critical security bugs – issuing a correction within 30-60 days. If you don’t have such a process, then it’s time to build what some organizations call a “quick-fix engineering” team that can rapidly respond to critical bugs and issue fixes on a reliable, predictable schedule. That isn’t always cheap – but it’s the minimum expectation.

Appoint a bug bounty advocate

Someone needs to be in charge of the program. They need to get the incoming reports, categorize them, liaise with the bug reporter for confirmation and other details and coordinate the quick-fix effort. Your advocate also needs to make sure the entire organization is aware of the bug bounty program, and be able to elicit support from other team members and departments as needed.

Conduct a bug audit

Before you can start asking the public – or even customers – to participate in a bug bounty, you should have some level of confidence that you’ve already squashed as many as possible. A bug bounty isn’t a way to get cheap or free debugging and troubleshooting; it’s an implied social contract. You are saying to your bug hunters: We as a company, have done everything we can to provide you a quality and bug-free product. Yet we are humble enough to know that we will never catch ‘em all. So we ask for your support in helping us squash what remains.

Bug hunters should feel that they’re contributing, not being taken advantage of. So preface a bounty program with an extensive audit of your code, supporting libraries, and so on.

Check with legal

Be sure you know what’s legal, too. For example, if some of your application consists of licensed libraries, you may need to touch base with the vendor to make sure they’re willing to participate in the program with you. After all, if a bug is traced back to a supporting library, you don’t want to have to shrug your shoulders and say, “It’s someone else’s problem,” unless you’re willing – as part of your bug-fix – to ditch that external library and go with something different. This is a big deal – being able to fix things, not merely identify them, is the goal. Check licensing agreements and touch base with your vendors to understand what’s allowed and what might come of a bug report.

Use your bug bounty program as a learning opportunity 

The biggest return on a bug bounty program is not simply squashing bugs. The big return should be in continually improving your development process. For each bug, ask why that bug got there. Modify standards, code reviews, automated tests and more so that the same kind of bug will have a harder time crawling into your code again. Turn each bug into a learning and improvement opportunity.

Write a bug brief

If you’ve made it this far, then you may be ready to begin a program. Start by writing a brief – bug-hunting community BugCrowd.com has a useful piece on what to include in your bug briefs. 

This is where you can outline what’s on the table, what isn’t, what the rewards are and what everyone’s expectations should be.

Having a bug bounty program is a big deal. It’s pulling aside the curtain, a bit, and inviting people to peek inside and see the not so nice. But it’s also a way of showing that you know you don’t operate in a vacuum, a way of winning respect (if you do it right), an opportunity for your development team to learn and grow and a way of moving your software toward a better place.

Learn more about the technology trends your business should be keeping up with in our report.

Stay innovative with this guide: Finding your way in today's rapidly changing tech environment