In 2024, a security researcher found a critical authentication bypass in a major cloud provider’s API. They reported it directly to the vendor, gave 90 days for a patch, and the vendor fixed it without a breach. The same vulnerability discovered and sold to a criminal actor could have produced a nine-figure breach. The difference was the disclosure decision the researcher made.
Responsible vulnerability disclosure is the practice by which security researchers who discover software or system vulnerabilities notify the affected organisation before making the vulnerability public, giving them a reasonable window to develop and deploy a fix. It sits between two less desirable extremes: immediate public disclosure that leaves users unprotected, and silent non-disclosure that allows vulnerabilities to persist indefinitely.
The Three Disclosure Models
Coordinated Vulnerability Disclosure (CVD)
CVD is the dominant model endorsed by CISA, ENISA, and most major technology companies. The researcher notifies the vendor privately with a technical description of the vulnerability. The vendor acknowledges receipt within a defined window (typically 7 to 14 days), works to develop a fix, and coordinates with the researcher on a disclosure timeline. After the patch is deployed, the researcher and vendor jointly publish a disclosure. The standard CVD window is 90 days, after which the researcher may disclose publicly regardless of patch status.
The 90-day standard: Adopted by Google Project Zero in 2014 and since followed by most major security research teams. 90 days is sufficient for most patches. Researchers may grant extensions for complex issues. After 90 days, public disclosure proceeds because vendors who have had sufficient time to patch but have not done so are now prioritising their own reputation over user safety.
Full Disclosure
Full disclosure publishes complete technical details of a vulnerability immediately without vendor notification. The argument: users deserve to know about vulnerabilities in software they use so they can make informed decisions, and vendors respond faster to public pressure than private notification. The counterargument: full disclosure gives attackers a complete exploit guide before most users can patch.
Full disclosure is appropriate in specific circumstances: when a vendor has already been privately notified and exceeded the reasonable disclosure window without action, when the vendor is actively hostile to researchers, or when evidence suggests the vulnerability is already known and being exploited in the wild.
Bug Bounty Programmes
Bug bounty programmes are vendor-operated programmes that invite external security researchers to find vulnerabilities in exchange for monetary rewards. HackerOne and Bugcrowd are the major platforms. Bounty amounts range from $100 for low-severity issues to $1 million or more for critical remote code execution vulnerabilities in major platforms.
Who runs them: Apple, Microsoft, Google, Meta, Amazon, and most major technology companies run active bug bounty programmes. The US Department of Defense has its Vulnerability Disclosure Policy (VDP) which is public disclosure without bounty for government systems.
Scope and legal protection: Bounty programme scopes define which systems, versions, and vulnerability types are in-programme. Working within scope provides explicit legal protection. Working outside scope removes that protection regardless of research intent.
The Legal Landscape for Security Researchers
The legal status of security research has improved significantly in the US after the DOJ updated its Computer Fraud and Abuse Act (CFAA) enforcement policy in 2022 to explicitly state that good-faith security research is not the target of CFAA prosecution. This removed a significant legal risk that had chilled legitimate security research for decades.
However, legal protections are jurisdiction-dependent and context-dependent. Working within an explicit bug bounty scope, or having written permission from the asset owner, provides the clearest legal protection. Probing systems you do not own or have authorisation to test, regardless of your intentions, remains legally risky in most jurisdictions.
EU NIS2 and national CVD policies: The EU’s NIS2 Directive (2022) requires member states to implement coordinated vulnerability disclosure policies and establish national CSIRT capacity. Several EU member states have published explicit national CVD policies providing legal safe harbour for good-faith researchers operating within those frameworks.
How to Report a Vulnerability You Found
- Document the vulnerability thoroughly: what you found, how you found it, the technical details of reproducing it, and the potential impact. Screenshots, HTTP traffic captures, or proof-of-concept code make your report more actionable.
- Find the right contact. Most large companies have a security.txt file at their website root (/.well-known/security.txt) listing contact details. If none: security@company.com is the standard convention. CISA maintains a directory for US critical infrastructure. Check for an existing bug bounty programme on HackerOne or Bugcrowd before reaching out directly.
- Send the report privately. Include: what you found, how to reproduce it, the potential impact, and your preferred contact method. Do not include a CVE number (those are assigned after disclosure). Do not publish anything publicly yet.
- Request acknowledgment within 7 to 14 days. If no response, follow up once. If still no response after 14 days, escalate to CISA or a national CSIRT who can facilitate contact.
- Agree a timeline. The standard is 90 days. Reasonable extensions for complex fixes are appropriate. Document all communications.
- After the patch: coordinate on a disclosure post. Most researchers publish a technical writeup. Assign a CVE through MITRE’s CVE programme if it qualifies as a public vulnerability.
CVE: The Global Vulnerability Registry
A CVE (Common Vulnerabilities and Exposures) identifier is a unique reference number assigned to publicly disclosed security vulnerabilities. CVEs are assigned by CVE Numbering Authorities (CNAs), which include major vendors (Microsoft, Apple, Google) and independent CNAs. MITRE maintains the central registry.
To request a CVE for a vulnerability you have discovered: contact the relevant CNA (the software vendor if they are a CNA, or MITRE directly if not), provide the technical details and proof of concept, and the CVE is assigned after verification. CVE assignment typically happens during or after coordinated disclosure rather than at initial report.
What is responsible vulnerability disclosure?
Responsible vulnerability disclosure (also called coordinated vulnerability disclosure or CVD) is the practice of privately notifying a vendor about a security vulnerability and giving them a defined window (typically 90 days) to develop and deploy a fix before publicly disclosing the details. It balances the researcher’s right to publish findings with users’ right to be protected before a public exploit guide exists.
What is the 90-day disclosure timeline and where does it come from?
Google’s Project Zero established the 90-day standard in 2014, giving vendors 90 days from private notification to deploy a fix before the vulnerability is disclosed publicly. After 90 days, researchers publish regardless of patch status, because vendors with sufficient time who have not patched are prioritising reputation over user safety. Extensions are granted for genuinely complex issues.
Is security research legal if I find a vulnerability I was not authorised to test?
Legal status depends on jurisdiction and context. The US DOJ’s 2022 CFAA enforcement policy update explicitly protects good-faith security research. However, working within an explicit bug bounty scope or having written permission provides the clearest protection. Probing systems without authorisation remains legally risky regardless of intent in most jurisdictions.
How do you find a company’s security contact for vulnerability reports?
Check for a security.txt file at the website’s root (/.well-known/security.txt). Try security@company.com as the convention. Check HackerOne or Bugcrowd for an existing bug bounty programme. Most large technology companies have dedicated security disclosure contacts. CISA maintains contacts for US critical infrastructure.
What is a CVE and how do you get one assigned?
A CVE (Common Vulnerabilities and Exposures) identifier is a unique reference number for a publicly disclosed security vulnerability. CVEs are assigned by CVE Numbering Authorities (CNAs). Contact the software vendor’s CNA (if they are one) or MITRE directly to request assignment. CVE assignment typically occurs during or after coordinated disclosure.
What is a bug bounty programme and how much can you earn?
Bug bounty programmes are vendor-operated initiatives paying security researchers for discovered vulnerabilities. Rewards range from $100 for low-severity issues to $1 million or more for critical remote code execution in major platforms. HackerOne and Bugcrowd are the primary platforms. Apple, Google, Microsoft, and Meta all operate large bounty programmes with six-figure maximum awards.
The Ecosystem Works When Everyone Follows the Protocol
The responsible disclosure ecosystem depends on three things working simultaneously: researchers acting in good faith and following coordinated timelines, vendors responding promptly and treating security researchers as partners rather than adversaries, and legal frameworks that protect researchers working within established norms. All three have improved significantly in 2026 compared to a decade ago, but the relationships remain fragile and case-dependent.