VDP vs bug bounty: which program do you actually need?

There are two things people call "a program" in vulnerability work, and they are not the same thing. Mixing them up in a meeting or a procurement conversation is the fastest way to land on a budget you don't need or a process you can't run.

This post is the version of the explanation we wish more security teams had read before their kickoff.

The two things, plainly

A vulnerability disclosure program (VDP) is a public commitment that says: if you find a security issue in our products, here's where to send it, here's what's in scope, here's how we'll respond. There is no money attached. The deal is "we'll take your report seriously, we won't sue you, and we'll fix what matters."

A bug bounty program is a VDP with money. Same intake, same scope discipline, same triage workflow, plus a published or implied payout table and the operational machinery to actually pay people.

Every bug bounty program is a VDP. Not every VDP is a bug bounty program. Choosing between them is choosing whether to add money.

What a VDP gets you

Three real things, even with no money attached:

1. Legal cover for hunters. A clear policy with a safe-harbor clause tells researchers they won't be hauled into court for poking at your product in good faith. Without this, the more cautious researchers, often the better ones, won't engage.
2. A signal that you take security seriously. Auditors, insurance providers, and enterprise customers will increasingly ask whether you have one. The cost of saying yes is roughly zero. The cost of saying no is whatever the customer's risk team decides.
3. A controlled intake for things that would have come anyway. Security researchers find bugs. They will report them somewhere, to you, to your customers, on Twitter, or to a regulator. A VDP says: report them here.

What it does not get you, despite what some vendors imply, is a flood of hunters going to work on your product. Most VDPs without bounties get five to twenty real reports a year. The ones that get more are either huge consumer brands or have been quietly attacked and people are clearing out their backlog.

What a bug bounty adds

Money, mostly, and what money buys. Specifically:

1. Volume. A program that pays will get more reports than one that doesn't. How many more depends on payout level, scope breadth, and visibility. A small private bounty might 5x your inbound. A public one with five-figure criticals will 50x it.
2. Quality, on average. Hunters who go for paid programs spend more time per submission. Repro steps are sharper, evidence is cleaner, severity arguments are better. The trade is that opportunists also show up, the famous "everything is critical" submissions.
3. Relationships you can call on. Top hunters are a small world. If you pay fairly and respond fast, you can call them when something specific needs eyes. You can run private programs, invite-only tests, retainer-style arrangements. None of that exists with a pure VDP.

The cost of all that isn't just the payouts. It's the operational weight: pricing decisions, payment processing, dispute handling, more volume to triage, more hunters to keep happy. A bug bounty without that operational machinery is a worse outcome than a VDP, because you're now paying money and generating ill will when you can't keep up.

Mistake one: skipping VDP and going straight to bounty

We see this a lot. A team gets enthusiastic, has budget, sets up a public bug bounty with five-figure rewards on day one, and within two weeks they're underwater. Reports flood in. Triage capacity isn't there. Response times slip. The first wave of hunters move on. The second wave shows up with junk because the experienced ones have already left.

The fix isn't to crank up the marketing, it's to do the VDP version first. Run it for three to six months. Get the intake right, the scope right, the response cadence right. Then add money once you know you can keep up.

You can compress this if you outsource triage. (That's our pitch and we'll get to it.) But you cannot compress it to zero.

Mistake two: running bounty without staffing for triage

A bounty creates an SLA expectation, even if you don't write one down. Hunters will tell each other how fast you respond. They will leave if you go silent.

Triage capacity needs to scale with reward level. A program offering $500 maximums can afford slower turnaround than one offering $50k, not because the math demands it, but because the kind of hunter you attract at $50k will not wait two weeks to hear back. The program with a one-week median response time and a $50k maximum will get one wave of submissions and then dry up.

If you cannot staff continuous triage at the level your rewards imply, lower the rewards or close the program until you can. We've seen "we'll figure out triage later" kill more programs than any budget cut.

Mistake three: confusing them in marketing

Your security page should be specific. If you have a VDP, say so. Don't imply payment. Don't put "We reward security research" on a page that has no payout table.

Hunters are practical. They will read your policy carefully, check your previous responses on Twitter and on platform-public reports, and decide whether to spend a Saturday on you. Vagueness about payment costs you the careful researchers and attracts the ones who don't read carefully, which is the opposite of the selection you want.

A simple decision framework

You probably want a VDP only if:

• You're a startup or small mid-market company with no dedicated AppSec team yet.
• You don't have a budget you can defend for security payouts.
• You haven't yet figured out your triage workflow.
• Your attack surface is small enough that you don't expect a high volume of reports.

You probably want a bug bounty if:

• You have an established AppSec function and an existing inbound flow you're already handling.
• Your attack surface is large enough that you want more eyes than internal review can provide.
• You can afford payouts at industry-typical levels for your severity tiers (more on that in our post on bug bounty payout amounts).
• You can staff or outsource enough triage to keep up with the inbound a bounty will generate.

You want both, in stages if:

• You're growing fast and you know a bounty is in the future.
• You want to learn the operational pattern before money makes the consequences expensive.

In our experience, the right path for most companies is: start with a VDP, run it as if it were a bounty (same SLA expectations, same triage discipline), add a private bounty after six months for hunters you already trust, then scale to a public one after another six.

What to do first if you're starting from scratch

A short, ordered checklist:

1. Publish a /security page with scope, policy, response commitments, and a safe-harbor clause. Reference well-known templates like disclose.io if you want a starting point.
2. Add a /.well-known/security.txt file with your contact address and policy URL. This is RFC 9116; it takes ten minutes and most security crawlers look for it.
3. Pick the inbox. A security@ address routed to a real ticketing system, not a personal inbox.
4. Decide who triages. A named human, in-house or outsourced, not "the security team" as a group. Triage requires single ownership.
5. Set a response SLA you can actually hit. Three business days for first response is reasonable for a VDP. Twelve to twenty-four hours is closer to bug bounty territory.
6. Run the VDP for at least one quarter before considering money. Track your median response time, the share of valid reports, and the quality of communication. If those numbers aren't where you want them, fix that before adding payout pressure.

After six months, if the program is healthy, the question of whether to add money becomes much easier to answer, because you'll have data on volume, quality, and operational cost.

Where we fit

We do triage and validation for both. A VDP that handles ten reports a month and a bounty that handles two hundred, same workflow, same discipline, same tools. We work with programs running on every major platform (HackerOne, Bugcrowd, YesWeHack, Bug Bounty Switzerland, HackenProof) as well as private programs and self-hosted setups.

If you're at the fork in the decision above and want a second opinion on which side to start with, book an intro call. We'll tell you honestly, including "you're not ready for either yet, do this first."