Summary

I keep seeing the claim that running a bug bounty program is how a vendor speeds up remediation. The argument is intuitive: a platform, triagers, a payout, a dashboard, all of it built to move a report from inbox to fix. Against that you have the old path, a researcher emailing [email protected] and hoping someone reads it.

I have used both paths in the same year for the same class of vulnerability. The bounty program was not reliably faster to an actual patch. Sometimes it was slower. What follows is not an argument against bounties, which are clearly good for other reasons. It is a look at where the time actually goes between a report and a shipped fix, and why the money in the pipeline does not buy the part of the timeline that matters most.

What the two paths actually optimize

A responsible disclosure over email and a submission through a bounty platform are optimizing different things, and it took me a while to see that clearly.

The email path optimizes nothing. It is a queue with no service level, no acknowledgement guarantee, and no structure. When it works, it works because a specific competent person on the other side read the message and cared. When it fails, it fails silently, which is its own problem and the reason platforms exist at all.

The bounty path optimizes triage throughput and researcher payout. Those are real and worth having. A good platform gets you a fast acknowledgement, a severity decision, and a duplicate check, usually within a day or two. What it does not optimize, and cannot, is the vendor’s internal engineering schedule. The fix still has to be written, reviewed, regression-tested, and shipped through whatever release process the product already has. No triager controls that queue.

So the honest framing is: the platform compresses the front of the timeline, the part between “I sent it” and “someone confirmed it is real.” It does very little to the back of the timeline, the part between “confirmed real” and “patched in a release customers run.” And on the reports I have handled, the back half is where almost all of the calendar time lives.

A timeline I can actually compare

Two reports, same year, same underlying weakness class (an authorization check missing on a secondary endpoint). I am keeping the vendors anonymous because the point is the shape, not the names.

Milestone Bounty platform Email to security@
Report submitted Day 0 Day 0
Human acknowledgement Day 1 Day 6
Severity agreed Day 3 Day 9
Fix in a released version Day 74 Day 51
Public coordination complete Day 90 Day 65

The platform won the first three rows and lost the two that a defender actually cares about. The email vendor was slower to answer, then faster to a shipped fix, because the team that read the email owned the release and scheduled it directly. On the platform, the report cleared triage quickly and then sat in a backlog that the triagers did not control, waiting on an engineering team that treated the platform as an intake system rather than a priority signal.

This is one comparison and I would not build a law out of it. But it matches what I have seen repeatedly. The bounty acknowledgement is a customer-service metric. The patch date is an engineering-capacity metric. They are not the same number and paying for the first does not move the second.

The severity number is not the accelerator either

A related belief is that a high CVSS base score makes the fix go faster. I score every report I send, and I have watched high scores fail to move anything. CVSS v3.1 base measures how bad the bug is if exploited, not how likely a vendor is to prioritize it against its own roadmap. A 9.8 in a rarely-deployed feature can lose the internal queue to a 6.5 in the login path that support is already getting tickets about. The score is an input to the vendor’s decision, not a lever the researcher gets to pull.

What actually moved timelines, in my experience, was none of the things the bounty economics are built around:

  1. A report a triager could confirm without a meeting. Exact versions, exact request, exact observed versus expected behavior. The structure I use for that has done more for my median time-to-fix than any severity argument.
  2. The bug living in code the vendor was already touching. A report that lands in an actively maintained module ships fast. One that lands in a frozen component waits for a release nobody had planned.
  3. A named human who owned both the triage and the release. This is the single biggest factor, and it is exactly the thing the platform abstracts away. The email vendor was slower to answer precisely because there was no triager in the middle, but the person who eventually answered could also schedule the fix.

Where the exposure window goes, and who is standing in it

Here is the part the economics discussion usually skips. While the report moves through either pipeline, the vulnerability is still live in every deployment running the affected version. The bounty payout does not shorten that window for the vendor’s customers. The customers are exposed from the moment the bug exists to the moment they install the fix, which is strictly later than the moment the vendor ships it.

That gap is not the researcher’s to close and it is not the platform’s either. It belongs to whoever is watching the affected systems in the meantime. Plenty of organizations do not wait for a vendor’s timeline at all, because they cannot afford to; they run continuous detection on the exposure window itself, either with an in-house team or by handing that watch to an outsourced SOC that treats the interval between disclosure and patch as the thing to monitor. That is a different economic decision than the vendor’s, and a more honest one, because it assumes the patch will be late and plans for the window rather than the milestone. The public coordination frameworks, from the FIRST guidelines to the CERT/CC coordinated disclosure guide, are all careful to describe that window as a shared-risk period, not a vendor-only one, and they are right to.

So should a vendor run a bounty program

Yes, but not for the reason usually given. A bounty program is worth running because it opens a channel that would otherwise be a silent security@ inbox, it pays researchers who would otherwise be working for free, and it catches the reports that the email path loses entirely. Those are real benefits and I am not waving them off.

Just do not sell it as a speed-to-patch improvement, because on the metric that protects customers, the shipped fix, it mostly is not. The compression it buys is at the front of the timeline, and the front of the timeline was never the expensive part. If a vendor wants faster fixes, the money is better spent on the engineering capacity to turn a confirmed report into a release, and on making sure the person who triages a report can also get it scheduled. That is unglamorous and it does not come with a dashboard. It is also the only thing I have seen actually move the date that matters.