Table of Contents
What is Responsible Disclosure?
Responsible disclosure — also called coordinated vulnerability disclosure (CVD) — is the practice of privately reporting a security vulnerability to the organisation responsible for the affected software before making it public. The goal is to give the vendor time to develop, test, and release a patch, so that users can be protected before attackers learn the details.
It sits at the intersection of two competing values:
- Public safety — Users deserve to know about vulnerabilities so they can protect themselves.
- Operational security — Publishing vulnerability details before a patch exists hands attackers a roadmap to exploit unpatched systems.
Responsible disclosure balances both: the public eventually gets the information, but only after a fix is available.
Disclosure Models
Three main approaches to vulnerability disclosure have emerged in the security community.
| Model | Process | Pros | Cons |
|---|---|---|---|
| Responsible (Coordinated) Disclosure | Report privately → wait for patch → publish | Users protected at disclosure; builds vendor trust | Vendor may delay or ignore; researcher gets no credit during embargo |
| Full Disclosure | Publish all details immediately with no vendor notice | Pressures vendors to patch; no vendor suppression | Attackers get the details before a patch exists; users at risk |
| Bug Bounty (Structured) | Report via bounty platform → vendor has defined SLA → researcher paid → details published after patch | Financial incentive; defined timelines; legal clarity | Limited scope; some researchers prefer non-bounty channels |
The security industry has largely converged on coordinated disclosure as the responsible standard, with bug bounty programmes providing the infrastructure to make it financially viable for researchers.
The Coordinated Disclosure Process Step by Step
The researcher identifies a security flaw through code review, fuzzing, dynamic analysis, or reverse engineering. They write a proof of concept to confirm the vulnerability is real and exploitable.
The researcher submits a detailed private report to the vendor via their official security channel ([email protected], a bug bounty platform, or a PSIRT portal). The report includes: vulnerability description, affected versions, reproduction steps, and PoC code.
The vendor acknowledges the report, confirms it can reproduce the issue, and provides an estimated timeline for a fix. If the vendor does not respond within 7–14 days, the researcher typically sends a follow-up.
The vendor develops the patch, tests it for regressions, and coordinates internal release processes. For complex vulnerabilities affecting many products, this can take the full 90 days. The researcher may provide additional technical assistance.
The vendor publishes the patch, a security advisory, and a CVE ID (assigned earlier in the process). The researcher publishes their technical write-up, often simultaneously.
The NVD processes the CVE entry, adds CVSS scores, CWE classification, and CPE affected software lists. Security scanners update their plugin databases. Organisations begin patching.
Disclosure Timelines
The most important decision in responsible disclosure is how long to give a vendor before going public, even if no patch exists.
| Organisation | Default Deadline | Extension | Notes |
|---|---|---|---|
| Google Project Zero | 90 days | +14 days if patch is imminent | Strict; publishes on deadline even without a patch |
| CERT/CC | 45 days | Varies | Longer for complex multi-vendor issues |
| HackerOne | Per-programme SLA | Per programme | Usually 90 days; can be extended by mutual agreement |
| Bugcrowd | Per-programme SLA | Per programme | Same as HackerOne |
| Zero Day Initiative (ZDI) | 120 days | Varies | Trend Micro-owned; buys and coordinates vulns |
| MSRC (Microsoft) | 90 days (following Project Zero) | +30 days | Microsoft adopted 90-day standard following pressure |
Google Project Zero and the 90-Day Standard
Google Project Zero, launched in 2014, is a team of elite security researchers whose mission is to find and responsibly disclose vulnerabilities in widely used software — not just Google's own products.
Project Zero introduced a strict 90-day disclosure deadline: after 90 days (with a possible 14-day extension if a patch is imminent), Project Zero publishes full vulnerability details regardless of whether the vendor has released a patch. This firm stance was controversial when introduced — vendors complained that 90 days was too short for complex vulnerabilities — but it dramatically accelerated the industry's average patch times.
Project Zero's database of disclosed vulnerabilities is public at googleprojectzero.blogspot.com. Their writeups are detailed technical analyses, often including PoC code, and are required reading for serious security researchers.
Bug Bounty Programmes
Bug bounty programmes are structured responsible disclosure programmes that pay researchers for finding valid vulnerabilities. They provide:
- A defined scope (which products and vulnerability types are in-scope)
- Clear rules of engagement (what testing is permitted)
- Legal safe harbour (protection from prosecution for in-scope testing)
- Financial rewards based on severity and impact
- Defined response SLAs
Payout Ranges (2026)
| Severity | Typical Range | Max payouts (top programmes) |
|---|---|---|
| Critical (RCE, auth bypass) | $10,000–$100,000 | $1,000,000+ (Google, Apple) |
| High (privilege escalation, data exfil) | $5,000–$30,000 | $150,000+ |
| Medium (stored XSS, SSRF) | $500–$5,000 | $25,000+ |
| Low (reflected XSS, information disclosure) | $100–$500 | $2,000+ |
Major Bug Bounty Platforms
- HackerOne — Largest platform; hosts programmes for GitHub, Shopify, Twitter/X, and US government agencies.
- Bugcrowd — Strong enterprise focus; runs programmes for Mastercard, Atlassian, and Tesla.
- Synack — Invitation-only, vetted researcher pool; popular with government and finance.
- Intigriti — European-focused; popular with EU-based organisations.
Many major technology companies run their own in-house programmes directly: Google, Microsoft, Apple, Meta, and Amazon all accept vulnerability reports through their own PSIRT portals.
Legal Considerations
Security research occupies legally complex territory. In many jurisdictions, testing systems without permission violates computer crime laws (the US Computer Fraud and Abuse Act, UK Computer Misuse Act, EU Directive on attacks against information systems).
Bug bounty programmes address this by providing legal safe harbour — a written commitment from the vendor not to pursue legal action against researchers who follow the programme rules. This is a critical protection that researchers should always verify before testing.
Key legal principles for researchers:
- Only test in-scope systems. Bug bounty scope definitions are legally significant. Testing out-of-scope systems is not protected by safe harbour.
- Do not access or exfiltrate real user data. Even if you find a data exposure vulnerability, accessing actual user data to demonstrate it may be illegal.
- Do not disrupt service. DoS testing is almost universally out-of-scope and may constitute criminal interference.
- Keep records. Document your testing process, communications with vendors, and disclosure timeline in case of legal challenge.
- Seek legal advice before testing in grey areas or unfamiliar jurisdictions.