Responsible disclosure
Updated August 31, 20262 min read
Responsible disclosure, now more commonly called coordinated vulnerability disclosure, means a researcher reports a flaw privately and gives the organisation time to fix it before publishing. The customary window is 90 days. The terms live in a public disclosure policy, and a security.txt file tells finders where to send their report.
Responsible disclosure, now more commonly called coordinated vulnerability disclosure (CVD), is the practice of reporting a vulnerability privately to the organisation that owns the affected system and giving it time to fix the problem before any details are made public.
What it means
The terms are set out in a disclosure policy: a public page stating what may and may not be tested, how to submit a report, how quickly the organisation will respond and when publication follows. The customary window is 90 days, a norm popularised largely by Google Project Zero. That team gives a vendor 90 days to make a patch available and publishes the details 30 days after the patch reaches users. If no patch arrives, the write-up goes out at the 90 day mark anyway. A vendor whose fix is nearly ready can ask for a 14 day grace period.
Two building blocks make such a policy work in practice. The first is a security.txt file served from /.well-known/security.txt and described in RFC 9116. Only two fields are mandatory, a contact address and an expiry date, but a link to the policy, the languages you accept reports in and a pointer to your encryption key save a great deal of back and forth. Without the file, a finder hunts around the website and the report ends up in a general support queue. The second block is safe harbour wording: an explicit promise that the organisation will not file a criminal complaint or pursue civil claims against a researcher who stays inside the published rules. The CERT Guide to Coordinated Vulnerability Disclosure is the standard reference for putting the whole process together.
Why it matters
Responsible disclosure is not the same thing as a bug bounty. A bug bounty is a paid programme with a reward table per finding and usually a platform behind it. Responsible disclosure is the underlying reporting process, where the return is an acknowledgement, a hall of fame listing or at most some swag. Every bug bounty programme rests on a disclosure policy, but most disclosure policies pay nothing at all.
For the receiving organisation, the payoff is time. A finder who knows where to send a report and where they stand legally comes to you first, rather than to a journalist or a buyer on an underground forum. That difference decides whether you patch a vulnerability calmly or read about it in the news.
Sources
Frequently asked questions
What is the difference between responsible disclosure and a bug bounty?
A bug bounty is a paid programme with a reward table per finding. Responsible disclosure is the underlying reporting process and usually pays nothing beyond recognition. Every bug bounty has a disclosure policy under it, but most disclosure policies pay no money.
How long is the standard disclosure deadline?
Ninety days between report and publication is the most widely used default. Google Project Zero gives a vendor 90 days to ship a patch and then publishes the details 30 days after that patch reaches users; if no patch arrives, it publishes at the 90 day mark anyway.
What belongs in a security.txt file?
RFC 9116 makes only two fields mandatory: a contact address and an expiry date. A link to your disclosure policy, the languages you accept reports in and a pointer to your encryption key are optional but useful. Serve the file from /.well-known/security.txt.
Is a researcher legally protected when reporting a vulnerability?
Only to the extent the organisation promises protection through safe harbour wording in its policy, and only inside the published scope. Without such wording, unauthorised access to a system remains a criminal offence regardless of intent.
Related articles
- GlossaryCVECVE stands for Common Vulnerabilities and Exposures: unique identifiers for publicly known security flaws. Learn how CVE IDs work and where to look them up.
- GlossaryPentestA penetration test (pentest) is a controlled attack on your systems by ethical hackers. Learn how a pentest works and what vulnerabilities it uncovers.
- GlossaryZero-dayA zero-day is a vulnerability still unknown to the vendor, meaning no patch exists yet. Learn how zero-day exploits work and how to limit the risk they pose.