In depth
The right framing of bug bounty is supplementary, not substitutional. A programme reaches a wider and more diverse researcher base than any one penetration-testing vendor can field, and it runs continuously — the moment a developer ships a new feature, the bounty population is exercising it. But bounty researchers are paid only for findings they discover, so they cluster on the easy, high-paying surfaces and ignore the boring-but-important compliance checks; coverage is statistical rather than deterministic. The mature pattern is to run a bounty programme for continuous surface coverage and to commission scoped, deterministic penetration tests for evidence-grade assessments (SOC 2, ISO 27001, PCI DSS).
Programmes have a maturation arc. Most organisations start with a private invite-only programme on a platform, with a tight scope (one or two production applications) and modest reward range. As the surface tightens (the easy findings are reported and fixed), scope expands and reward ranges increase to keep attracting top researchers. Public programmes — open to any researcher — are the public commitment; they also generate noisy reports that the triage team must filter. The triage cost is non-trivial: a public programme on a popular target can receive hundreds of submissions per month, of which a single-digit percentage are typically valid.
Programme policies must clearly state scope (which assets are in, which are out), prohibited activities (no social engineering, no destructive testing, no DDoS), safe-harbour language (researchers acting in good faith will not be sued), disclosure rules, and reward methodology. See Bug bounty vs. pentest and the AxVeil responsible disclosure programme.