Responsible disclosure and bug bounties: how they work and how to set one up

Coordinated vulnerability disclosure (CVD) is an agreement between a finder and a vendor: the finder reports privately and gives the vendor reasonable time to fix, and the vendor acknowledges the report, keeps the finder informed and fixes the problem. Details become public once a fix is available or an agreed deadline passes. The process is described in international standards (ISO/IEC 29147 for receiving and publishing reports, ISO/IEC 30111 for handling them internally) and in guidance from agencies such as CISA and NIST.

The older phrase "responsible disclosure" means much the same thing. "Coordinated" is preferred because it emphasizes that both sides share responsibility.

A bug bounty program is a disclosure process with rewards. The organization publishes a scope (which domains, apps or products are eligible), rules (what testing is allowed) and a reward table, usually based on severity. Programs can be public, open to anyone, or private, open to invited researchers. Many are run through a bounty platform that handles intake, triage and payment.

Bounties can attract skilled researchers with very different backgrounds and tools. The trade-offs are volume (many low-quality or duplicate reports), uneven coverage (researchers go where rewards are easy to earn) and a triage workload someone has to own.

The short version: a pentest gives you depth and coverage of what you chose to test, at a time you chose. Disclosure and bounties give you many outside perspectives on whatever is publicly reachable. Most mature programs use both, and a pentest before launching a public bounty avoids paying rewards for issues a single engagement would have caught.

Safe harbor is a statement in your policy that you will not pursue legal action against researchers who act in good faith and follow the rules. Without it, careful researchers may not report at all, because accessing someone else's systems without permission can create legal risk.

A good safe harbor clause says research within the policy is considered authorized, that you will not bring claims for good-faith research, and what you expect in return: no data exfiltration beyond what proves the issue, no service disruption, no social engineering of staff, and private reporting. Have counsel review the wording.

security.txt is a small text file, defined in RFC 9116, that tells researchers how to reach you. It lives at /.well-known/security.txt on your domain over HTTPS. Two fields are required: Contact (an email address or URL for reports) and Expires (a date after which the file should be treated as stale). Optional fields point to your policy, encryption key, acknowledgments page and preferred languages.

It takes minutes to publish and removes the most common failure: a researcher with a valid finding and no idea who to tell. Put a calendar reminder on the Expires date.

1. Pick an owner. Someone must read reports, triage them and route fixes. A dedicated inbox nobody checks is worse than none.
2. Write the policy. Cover scope, what is out of scope, allowed and prohibited testing, how to report, what researchers can expect from you and safe harbor. CISA publishes a vulnerability disclosure policy template you can adapt.
3. Publish it. Add a page on your site and a security.txt file pointing to it.
4. Set response expectations. State when you will acknowledge a report and how you will keep the researcher updated, and then meet those commitments.
5. Connect it to remediation. Valid reports should land in the same tracking system as pentest findings, with an owner and a fix date, and be retested before closing.
6. Add rewards later, if ever. Start with a no-reward policy. Consider a bounty once triage runs smoothly and a pentest has cleared the obvious issues.

How you handle the first few reports shapes whether researchers keep reporting to you. A workable flow:

1. Acknowledge receipt quickly, even if you have not assessed it yet, so the researcher knows a person has it.
2. Reproduce the issue. If you cannot, ask for more detail before rejecting it; many "invalid" reports are valid but poorly explained.
3. Assess severity using a consistent method (many teams use CVSS as a starting point and adjust for business impact), and decide on a fix date.
4. Fix and verify. Retest against the original report before marking it resolved, and ideally ask the researcher to confirm.
5. Close the loop. Tell the researcher it is fixed, agree on any publication, and credit them if they want to be credited.
6. Learn from it. If an outsider found it, ask why your own testing did not. The answer often points to a gap in scope or frequency.

Duplicates, out-of-scope reports and automated scanner output with no demonstrated impact will also arrive. Reply politely and point to the policy; a consistent, documented response is what keeps the channel useful.