There is a particular kind of security decision that looks like buying a control and is actually taking on an operational commitment, and a bug bounty programme is the clearest example. The pitch is seductive: pay only for results, get the whole internet testing your systems, catch what your pentest missed. All of that can be true. It is also true that a bounty programme is an intake pipe, and if you open it without the plumbing behind it, what arrives is not a stream of clean findings. It is noise, arguments, and a queue nobody is staffed to clear.
This is written from the side most articles skip. Not how to hunt bugs, but how to run the programme that receives them, because that is where the money is spent and where the failures happen.
What a bounty is, and what it is not
A bug bounty is a standing offer: report a genuine security flaw in our defined scope, and we will reward you according to a published schedule. It is continuous, it is open to people you have never met, and the quality of what arrives varies enormously, from a beautifully written exploit chain to a screenshot of a scanner output with a demand for payment.
It is worth separating it from two things it gets confused with. A vulnerability disclosure programme, or VDP, is the no-money version: a safe, legal channel for people to tell you about problems, with no reward. Every organisation of any size should have a VDP, because people will find issues whether you invite them or not, and the alternative to a reporting channel is disclosure on social media. A bounty adds money on top, which changes the volume and the incentives significantly.
And a bounty is not a penetration test. A pentest is scoped, time-boxed, methodical, and gives you assurance that someone competent looked systematically at a defined thing and reported what they found and what they did not. A bounty is opportunistic and unsystematic: you learn about the bugs someone happened to find and chose to report, and silence tells you nothing. The two answer different questions, and a bounty that is quiet does not mean you are secure, it means nobody with the skill and inclination looked this week. Using one as a substitute for the other is the most expensive mistake in this area.
The four things that have to exist before you open the door
Safe harbour, or nobody good reports
The single most important clause in a bounty programme is the one that promises you will not pursue legal action against someone who tests you in good faith within the rules. Without it, the researchers you most want, the careful, professional ones with reputations to protect, will read your terms, see the legal exposure, and quietly move on to a programme that has done this properly. The people undeterred by the absence of safe harbour are not the ones you want defining your relationship with the security community.
The wording matters and it is worth having a lawyer who understands the space draft it, because it has to authorise the testing clearly enough to sit against the computer misuse laws that would otherwise make that testing an offence. This is the same authorisation principle that governs any security testing: the act is identical, and what separates permitted from criminal is the written scope and permission. A vague or grudging safe harbour is worse than none, because it looks like protection and is not.
Scope, in writing, in and out
Scope is where programmes turn into arguments. State explicitly which assets are in scope and, just as importantly, which are out. Name the domains, the applications, the APIs. List the things you do not want touched, the methods you will not accept, such as social engineering of your staff or physical intrusion or denial of service, and the data-handling rules for anything a researcher stumbles into. Every gap in the scope document is a future dispute over a payout, conducted in public, with your programme's reputation as the stake.
Triage capacity, which is the actual expense
Here is the number nobody quotes in the business case. The reward budget is not the cost of a bounty programme. The cost is the human hours to look at every submission, reproduce it, decide whether it is real, novel, in scope and worth paying, and do that consistently, at volume, indefinitely. A public programme on a well-known brand can generate a flood, much of it low-quality or duplicate, and every item still has to be looked at, because the one you dismiss unread is the one that was real.
If you do not have a named owner with a response service level and a real path into engineering to get things fixed, do not open a public programme. Start with a VDP, or run a private, invite-only bounty with a handful of researchers and a volume you can actually handle. Scale the openness to the triage capacity, never the reverse.
A reward rubric that does not move
Publish how severity maps to payment, how you handle duplicates, the first valid report generally being the one that pays, and then hold to it. The fastest way to lose the community's trust is to appear to move the goalposts, to downgrade a severity to reduce a payout, or to sit on a report and then call it a duplicate when someone else reports it later. Researchers talk to each other, and a programme that is seen to pay unfairly develops a reputation that is very hard to repair.
When a bounty is the right tool, and when it is not
A bounty earns its place once you have a reasonable security baseline and you want continuous, opportunistic coverage on top of it, from a wider pool of skills than you employ, paying only for what they find. It is genuinely good at surfacing the creative, chained, real-world issues that a time-boxed test can miss, and at giving you a legitimate channel that turns a finder into a collaborator rather than a leaker.
It is the wrong tool if you are using it to find the issues a first pentest or basic hardening would have caught, because you will pay bounty prices for low-hanging fruit and attract low-effort submissions. It is wrong if you cannot fix what it finds, since an unactioned finding is money spent to document a risk you then carry anyway. And it is wrong as a substitute for assurance, because its silence is not evidence of security. Get the baseline and the pentest first. The bounty is the layer on top, not the foundation.
| Question | Bug bounty | Penetration test |
|---|---|---|
| Coverage | Opportunistic, whatever someone finds | Systematic, against a defined scope |
| Assurance from silence | None, silence means nothing | Meaningful, a clean report is a result |
| Cost shape | Per finding, plus heavy triage | Fixed, per engagement |
| Best for | Continuous cover on a mature baseline | Assurance and finding the known classes |
Delivering it: who, what, when
Who. A bounty needs a named programme owner who can triage or route triage, and a real line into the engineering teams who will fix what comes in. Without the second, findings pile up validated and unactioned, which is the worst of both worlds.
What. Start with the VDP and safe harbour, which every organisation should have regardless. Then, if the baseline justifies it, a private invite-only bounty with a bounded researcher pool. Public and open is the last step, taken only when triage capacity is proven, not the first.
When. Sequence by control, not enthusiasm. Baseline hardening and a pentest first, so the bounty is not paying to find what should already be fixed. Then VDP, then private bounty, then public. Each stage should be comfortable before the next opens, because you cannot easily close a programme you have opened without damaging the reputation you were building.
The honest summary
A bug bounty is one of the few security investments that can genuinely turn strangers into an extension of your defence, and it is also one of the few that punishes you immediately for treating it as a purchase rather than a practice. The reward budget is the visible, minor cost. The triage, the scope discipline, the safe harbour and the fix pipeline are the real programme, and they are all work you do before a single valid report arrives.
If you take one thing from this, let it be the sequence. Reporting channel and safe harbour first, capacity before openness, and never a bounty in the place where a pentest and basic hardening belong. Get that order right and the programme is a genuine asset. Get it wrong and you have paid to build a queue that shames you in public.
If you want help standing up a disclosure or bounty programme, or deciding whether you are ready for one, that is the kind of work I do through Cyber Spartans.