Leadership wants a paid bug bounty before you have a VDP or a PSIRT — what do you advise?

## Three shapes, often confused **A vulnerability disclosure policy** is a *published document* and the intake behind it. It says which assets are in scope, how to reach you, what you commit to (acknowledge in N days, status updates at a stated cadence), and that good-faith research within scope is authorised and will not be pursued legally. It promises no money. Its cheapest honest implementation is a monitored mailbox drained by whoever is on call, with a rota and an escalation path. For most organisations this is sufficient and it is the thing regulators, customers and security questionnaires increasingly expect to exist. **A bug bounty** is a *paid incentive program* layered on top of a policy. It adds a reward table, severity-to-payment mapping, duplicate handling, out-of-scope lists that exist mainly to suppress noise, and — the part people forget — triage service levels you now owe to strangers who are working for the possibility of money. It does not solve discovery; it *increases* discovery, deliberately and sharply. **A PSIRT** is a *standing function* in an organisation that ships software other people run. It owns intake through fixed release, coordinates fixes across supported release lines, produces customer-facing advisories, tracks vulnerabilities in the components it consumes, and fields the enterprise procurement questionnaires that ask how you handle all of that. A PSIRT is a staffing decision, not a document. You can have a VDP with no PSIRT. You should not run a bounty without the capacity a PSIRT-shaped function provides — someone has to answer. ## Why the sequencing argument wins The constraint is almost never researcher supply. A public bounty on a reasonably sized web estate produces inbound volume quickly, and the majority of it is low-value or duplicate. Every report costs engineering time to reproduce, rate and route, whether or not it is paid. So the real cost of a bounty is not the payouts; it is the triage hours and the fix work that follows the good ones. Buying more findings before you can act on the ones you have produces a visible backlog that researchers talk about publicly — "reported six months ago, still unfixed" is a worse story than having had no program. The evidence to bring to the conversation is operational, not rhetorical: how many reports arrived last quarter, median time to first response, median time to fix by severity, and the age of the oldest unfixed accepted finding. If those numbers are bad or unknown, they are the answer to whether a bounty is next. ## What is leadership actually buying? Ask, because the request usually encodes a goal the bounty is a poor instrument for: - **"A customer's questionnaire asked about our disclosure process."** They are asking for a VDP. Publish one and answer the question. - **"We want assurance before this launch."** A scoped, time-boxed engagement with a defined report date delivers that; a bounty's coverage is unpredictable in both timing and depth. - **"We want to look serious about security."** A public bounty with slow responses achieves the opposite in the community that would have reported to you. - **"We want continuous coverage on a mature product."** This is the case a bounty genuinely serves — and it is a good argument once the fix pipeline is proven. ## A staged path that usually works 1. Publish the policy and a findable contact; name an owner and an acknowledgement commitment you can actually meet. 2. Run it for a quarter or two. Measure intake, response and fix times. Fix the process problems that show up — reports lost in a support queue, no route to a fixing team, nobody able to decide severity. 3. Add non-cash incentives: acknowledgements page, swag, direct contact with engineers who actually answer. These cost little and materially improve report quality. 4. If the numbers hold, start a **private, invitation-only** program on a narrow asset with a capped budget. Volume is controllable and you learn your true triage cost. 5. Open it up when you can defend the response times publicly. ## Where this bites hardest A vendor whose software runs inside customers' environments has a further obligation: reports do not stop at a fix in production, because there is no single production. That is the PSIRT case — supported release lines, backports, an advisory customers can act on, and a way to answer the same security questionnaire fifty times without fifty bespoke replies. An organisation in that position that funds a bounty before funding that function has bought a firehose and no plumbing. The principal-level answer is not "bounties are bad". It is that a bounty is a demand-side tool applied to a supply-side constraint, and the professional move is to say what you will build first, what you will measure, and when the bounty becomes the right next spend.