A six-figure bounty is a procurement decision, not a gift

The number is what gets quoted. A critical report paid in six figures looks, from the outside, like a patron handing a researcher a prize. Inside a mature program it is a purchase. The company is buying a description of a broken trust boundary, delivered before a criminal sold the same description to someone else, under rules both sides can point to when the argument starts.

Google, Meta, and a long list of enterprises publish those rules. The public tables say, in effect, what kinds of impact the program exists to hear about: an outsider becoming an insider, a service running an attacker’s code, a large set of private data leaving a boundary it should not cross. The tables are not a menu of techniques. They are a price list for outcomes. A scanner finding with no story about who can do what is usually worth nothing, and the programs say so.

What the check is actually buying

A useful report has three parts, and only one of them is the bug.

The first is scope. The asset is one the company asked to hear about. A program that pays for its production identity provider and refuses payment for a marketing microsite it does not control is not being cheap. It is refusing to launder someone else’s risk. Researchers who read the scope before they test waste less of their own time.

The second is evidence of impact, stopping at the point where the impact is clear. A convincing report shows that a boundary failed. It does not need a weaponized follow-through, and good programs tell researchers to stop once the point is made. Safe-harbor language exists so a good-faith researcher who stayed inside the rules is not treated as an intruder. The language is not a hunting license. It does not cover privacy harm, downtime, or a walk through data that was not required to prove the issue.

The third is a fix the team can ship. The highest-paid reports tend to sit on authorization: who is allowed to become whom. Those are the bugs that survive a decade of framework upgrades because they are decisions, not missing patches. Paying well for them is rational. The alternative is learning about them from a disclosure you did not choose.

International practice has names for this. ISO/IEC 29147 describes vulnerability disclosure. ISO/IEC 30111 describes how a vendor handles a report once it arrives. You do not need to certify anything to copy the shape: a door people can find, a clock you actually keep, and a human who can say “out of scope” without insulting the finder.

Triage speed is the product

Researchers talk about payout ranges. They remember response time. A critical report that sits untouched for a month teaches the next researcher to file somewhere else, or nowhere. The check, when it finally arrives, does not buy back the week in which the issue was also sitting in someone else’s inbox.

A small team can copy the part of a famous program that matters. Publish a narrow scope. Answer in a few business days, even if the first answer is “we have it, we have not judged it.” Decide duplicates with the policy you wrote down, not with the mood of the person on intake. Pay the range you printed, or change the range in public. Nothing corrodes a program faster than a silent downgrade.

security.txt, specified in RFC 9116, is the boring half of the front door. A file at /.well-known/security.txt tells a stranger where to write. It is not a bounty. It is a way to avoid the researcher emailing a random personal address they found in a commit. A minimal file looks like this:

Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security

Replace the example names before you publish it. An expired file is worse than none, because it looks official and is not.

The arguments that waste a quarter

Severity fights are usually fights about a sentence the policy never wrote. CVSS is a shared vocabulary. It is a poor payroll system. A theoretical maximum that requires an attacker who is already an administrator is not the same report as a flaw any customer can hit. Programs that publish impact examples — “this is critical, this is a duplicate, this is out of scope” — spend less time relitigating the same paragraph.

Duplicates are the other bruise. Two people can find the same broken check. The fair rule is the one in the policy: first usable report, or first report that the team could have fixed from, not first person to attach a screenshot. Write it down. Apply it when the second report is the more famous researcher.

Legal safe harbor should be on the same page as the scope, in language a non-lawyer can read. “Test only the accounts you own. Do not exfiltrate data you do not need. Stop when you can show the issue. Give us a chance to fix it before you talk about it.” Researchers who want a carnival will go elsewhere. Researchers who want a check and a clean record will stay.

What a team of four can afford

You do not need a brand that researchers already tattoo on a laptop. You need a mailbox that is read, a page that lists the hosts in scope, a cap you can actually pay, and the authority to patch the thing the report describes. A program that pays five hundred dollars and fixes the issue in a week is a better deal for everyone than a program that advertises fifty thousand and argues for a year.

Procurement is the right department to sit next to, not because bounty spend is large, but because the alternative spend is an incident. The check is smaller than the retainer you will sign after a disclosure you did not buy. It is also smaller than the notification letter. That comparison only holds if the report is one you would have missed, and if someone inside can turn it into a change. A bounty program with no engineering time behind it is a suggestion box.

Publish the rules where a stranger can find them. Thank people in the write-up when they want to be named. Close the loop when you will not pay, and say why in one paragraph. The researchers who come back are the ones who learned that your no is real and your yes arrives.

This briefing describes how public vulnerability-reward programs are run. It is not a guide to finding or exploiting bugs.