Responsible Disclosure

What is Responsible Disclosure?
Why is Responsible Disclosure Important?
The Responsible Disclosure Process
Famous Disclosure Case Studies
Full Disclosure vs. Responsible Disclosure
Bug Bounty Programs
The Vulnerability Broker Market
CVE System — Deep Dive
What NOT to Do (Unethical Disclosure)
Legal Protections for Researchers

1. What is Responsible Disclosure?

Responsible Disclosure (also known as Coordinated Disclosure) is a security practice where a security researcher or ethical hacker reports a discovered vulnerability to the affected organization privately and gives them a reasonable amount of time to fix it before making any details public.

The core idea: Give the defenders a head start before revealing the flaw to the world (including malicious actors).

Why the Term Matters

The term "Responsible Disclosure" was coined by security expert Scott Culp (Microsoft) in 2002 to distinguish ethical disclosure from "Full Disclosure" (immediate public release). However, some prefer "Coordinated Disclosure" because the word "responsible" can imply that any other approach is "irresponsible" — which is a point of debate in the security community.

2. Why is Responsible Disclosure Important?

Without responsible disclosure, the security ecosystem breaks down:

Scenario	Result
Immediate public disclosure	Attackers learn about the flaw before a fix exists → Zero-day exploitation
No disclosure at all	Vulnerability remains unpatched indefinitely → N-day exploitation (after someone else finds it)
Responsible disclosure	Organization has time to fix; users are protected
Selling to criminals	Active exploitation with no public fix; victims have no protection
Selling to governments	Stockpiled for intelligence/offense; no fix for civilians

Real-World Consequences of Poor Disclosure

Vulnerability	Who Found It	Disclosure Decision	Impact
Heartbleed (2014)	Google Security + Codenomicon	Responsible — coordinated with OpenSSL	~17% of SSL servers vulnerable, but patched before mass exploitation
EternalBlue (2017)	NSA	Not disclosed — used as weapon; later leaked by Shadow Brokers	WannaCry ($4B damage), NotPetya ($10B+)
Log4j / Log4Shell (2021)	Chen Zhaojun (Alibaba)	Responsible — reported to Apache on Nov 24, 2021	CVE fixed Dec 6; public disclosure Dec 9. Still massive exploitation within hours
SolarWinds (2020)	FireEye	Detected during an attack (supply chain compromise)	Not a disclosure case — it was an active state-sponsored attack

3. The Responsible Disclosure Process (Detailed)

Step 1: Discovery

A researcher finds a vulnerability through many possible avenues:

Discovery Method	Legitimate?	Authorization?
Authorized pentest (within scope)	✅ Yes	✅ Yes
Bug bounty program	✅ Yes	✅ Yes (by program terms)
Accidental discovery (stumbled upon it)	⚠️ Grey area	❌ No
Personal research (public software)	⚠️ Depends on ToS	❌ Unlikely
Reverse engineering (purchased software)	⚠️ Varies by jurisdiction	❌ May violate EULA
Unauthorized testing	❌ No	❌ No — illegal

Step 2: Verification

Before contacting the organization, the researcher should:

Confirm reproducibility — can it be triggered consistently?
Determine affected versions — which versions of the software are vulnerable?
Create a minimal Proof of Concept (PoC) — the simplest code to demonstrate the issue
Assess impact — what can an attacker actually achieve? (RCE, data exfiltration, DoS)
Check for duplicates — is this already known? (search CVE databases, vendor advisories)
Document everything — detailed steps to reproduce, affected configurations

Step 3: Secure Reporting

The researcher contacts the organization privately.

Where to report (in order of preference):

Contact Method	How to Find	Security Level
Bug bounty platform	HackerOne, Bugcrowd, Synack (if program exists)	🔒 Encrypted
security@company.com	Falls through to security team	⚠️ May not be encrypted
PSIRT email (Product Security Incident Response Team)	psirt@company.com	🔒 Usually monitored
Security contact page	`/.well-known/security.txt` or `/security`	✅ Standard
PGP-encrypted email	Find key on keyserver or company website	🔒 Best

What a good disclosure report includes:

Subject: Security Vulnerability: [Product X vY.Z] - [Vulnerability Type]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. SUMMARY
   Product:     ExampleApp v2.1.0
   Type:        SQL Injection (Time-Based Blind)
   CVE Status:  Not yet assigned
   Severity:    Critical (CVSS 9.8)

2. IMPACT
   An unauthenticated attacker can extract the full database
   contents including user credentials, PII, and financial data.

3. STEPS TO REPRODUCE
   1. Navigate to https://app.example.com/login
   2. Intercept POST /api/v2/login
   3. Send: username=admin' OR (SELECT sleep(5) FROM users)='
   4. Observe 5-second delay confirming SQL injection

4. AFFECTED VERSIONS
   ExampleApp v2.1.0 through v2.1.3 confirmed vulnerable.
   v2.0.x and earlier not tested.

5. PROOF OF CONCEPT (see attachment)
   - PoC script: sqli_exploit.py
   - Screenshot: evidence.png (redacted)

6. SUGGESTED FIX
   Use parameterized queries / prepared statements.
   See OWASP SQL Injection Prevention Cheat Sheet.

7. DISCLOSURE TIMELINE (Proposed)
   - Today: Initial report
   - +30 days: Vendor patch expected
   - +45 days: Public disclosure (if no patch, discuss extension)

8. CONTACT
   Researcher: Jane Researcher
   PGP Key ID: 0xDEADBEEF
   Phone: [optional, for critical issues]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 4: Vendor Response & Fix Window

Typical industry-standard timelines:

Severity	Fix Window	Extended (Complex Issues)
Critical (CVSS 9.0+)	7 days	14 days
High (CVSS 7.0-8.9)	30 days	45 days
Medium (CVSS 4.0-6.9)	60-90 days	120 days
Low (CVSS 0.1-3.9)	90-120 days	180 days

Considerations for extended timelines:

OpenSSL / cryptographic libraries — affect millions of products

Kernel vulnerabilities — require reboots, careful testing

Hardware/firmware flaws — may require physical replacement

Third-party dependencies — fix must propagate through supply chain

Regulatory environments — some industries (medical, aviation) require certification of patches

Google Project Zero's 90-Day Policy:

Google Project Zero follows a strict 90-day deadline from the date of first report. Regardless of whether a patch is ready, the vulnerability details are publicly disclosed on day 91. This has been controversial:

Pros	Cons
Forces vendors to prioritize security	Can expose users to attacks if no patch exists
Public accountability	Zero-days become N-days without fix
Industry has improved (Windows, iOS patching cycles are faster)	Increased pressure can lead to rushed/broken patches

Step 5: Patch Release

The organization develops, tests, and deploys a fix:

Internal triage — verify the report, reproduce the vulnerability
Priority assessment — assign severity, schedule fix
Fix development — code changes to eliminate the vulnerability
Quality assurance — test the fix, regression testing
CVE assignment — request CVE from a CNA (CVE Numbering Authority)
Patch release — distribute to users (auto-update, download, package manager)
Security advisory — publish vulnerability details (see Tutorial 7 for advisory format)

What a good security advisory includes:

SECURITY ADVISORY: SA-2026-007
─────────────────────────────────

Product:    ExampleApp v2.1.0 - v2.1.3
CVE ID:     CVE-2026-12345
Severity:   CRITICAL (CVSS 9.8)
Published:  July 20, 2026

Description:
  An SQL injection vulnerability in the login endpoint allows
  unauthenticated attackers to execute arbitrary SQL queries.

Affected Versions:
  ExampleApp v2.1.0 through v2.1.3

Fixed in:
  ExampleApp v2.1.4

Remediation:
  Upgrade to v2.1.4 immediately. If upgrade is not possible,
  block access to /api/v2/login at the WAF level until upgrade
  can be performed.

Credit:
  Jane Researcher (HackerOne: @janeresearcher)

Step 6: Public Disclosure

After the fix is deployed, the researcher may publish:

Technical blog post — detailed analysis, exploit technique, fix analysis
Conference presentation — Black Hat, DEF CON, BSides
CVE entry — minimal technical details on cve.org
Social media — tweet/linkedin post acknowledging the response

Best Practices for Public Disclosure:

Do	Don't
Wait for the patch to be available	Publish before the fix is released
Redact sensitive data from PoC	Include working exploit code targeting unpatched systems
Credit the vendor for their response	Shame the vendor for slow response (unless unreasonable)
Acknowledge any bug bounty received	Publish confidential communications without permission
Provide constructive analysis	Make it easy for script kiddies to weaponize

4. Famous Vulnerability Disclosure Case Studies

Case Study 1: Heartbleed (CVE-2014-0160)

Detail	Info
Type	Buffer over-read in OpenSSL's TLS heartbeat extension
Severity	Critical — leaked memory contents (private keys, passwords, session data)
Impact	~17% of all SSL servers affected
Discovered by	Google Security (Neel Mehta) + Codenomicon independently
Disclosure Process	Reported to OpenSSL Foundation → Coordinated fix developed → Public disclosure April 7, 2014
Result	Patched released simultaneously with public disclosure. No known exploitation before disclosure. Considered a model case of responsible disclosure.

Case Study 2: Log4Shell / Log4j (CVE-2021-44228)

Detail	Info
Type	Remote Code Execution via JNDI lookup in Apache Log4j logging library
Severity	Critical (CVSS 10.0) — unauthenticated RCE
Impact	Billions of devices, virtually every enterprise software vendor affected
Discovered by	Chen Zhaojun (Alibaba Cloud Security Team)
Disclosure Process	Reported to Apache on Nov 24 → Patch released Dec 6 → Public CVE Dec 9
Result	Despite responsible disclosure, attackers began scanning within hours of the CVE being published. Automated worm-like exploitation began within 48 hours. Shows that even responsible disclosure cannot prevent mass exploitation of high-impact vulnerabilities.

Case Study 3: EternalBlue (MS17-010 / CVE-2017-0144)

Detail	Info
Type	SMB protocol Remote Code Execution in Windows
Severity	Critical — wormable (no user interaction required)
Impact	WannaCry ($4B damage), NotPetya ($10B+), and numerous other attacks
Discovered by	NSA (Equation Group) — not disclosed responsibly
What happened	NSA developed and stockpiled the exploit. The Shadow Brokers group leaked it in April 2017. Microsoft had already released a patch in March 2017 (MS17-010) but many systems were unpatched.
Key Lesson	Governments stockpiling vulnerabilities instead of disclosing them responsibly leads to catastrophic civilian damage when those exploits inevitably leak. The EternalBlue leak is the strongest argument against vulnerability stockpiling.

Case Study 4: Apple's Rootpipe (CVE-2015-1130)

Detail	Info
Type	OS X privilege escalation — bypass system integrity protection
Discovered by	Emil Kvarnhammar (Swedish security researcher)
Disclosure Process	Reported to Apple in October 2014. Apple released a fix in April 2015 (6+ months later).
Result	Researcher disclosed at a conference after the patch. Apple credited him. Good example of patience with a complex OS-level fix.

5. Full Disclosure vs. Responsible Disclosure

The debate continues:

Aspect	Responsible Disclosure	Full Disclosure
Disclosure to vendor	Private, immediate	Private, brief delay or none
Public disclosure	After patch is ready (7-120 days)	Immediately or after short deadline
Risk to users	Low (patch available first)	High (attackers exploit before patch)
Risk to vendor	Low-Moderate	High (public pressure/shame)
Argument FOR	Protects users; gives time to fix	Forces vendors to act; no secrets
Argument AGAINST	Vendors may delay; users at risk during "window of vulnerability"	Attackers benefit; users caught in crossfire
Proponents	Most security professionals, vendors, CERT/CC	Security purists, some researchers

Notable Full Disclosure Advocates:

Google Project Zero — Strict 90-day policy
ZDI (Zero Day Initiative) — Buys vulnerabilities, gives 120 days, then publishes
Bugtraq mailing list (historical) — The original full-disclosure platform
Dan Kaminsky — Famous for finding a fundamental DNS flaw in 2008, but chose responsible disclosure despite being a full-disclosure advocate

6. Bug Bounty Programs

Bug bounty programs are the formal implementation of responsible disclosure — companies pay researchers for valid vulnerability reports.

Major Bug Bounty Platforms

Platform	Researchers	Notable Programs	Model
HackerOne	700,000+	Google, Toyota, US DoD, Twitter, Atlassian	Managed + Community
Bugcrowd	400,000+	Apple, Atlassian, Mastercard, OpenAI	Managed + Community
Synack	1,500+ (invite-only)	US DHS, DoD, major banks	Private (vetted researchers)
Intigriti	25,000+	European-focused; KBC, Proximus	Community
YesWeHack	25,000+	European; Orange, La Poste	Community
Immunefi	45,000+	Crypto/DeFi focused; Ethereum, Polygon, Solana	Smart contract bounties

Typical Payout Ranges

Vulnerability Type	Typical Payout	Max Recorded
Low (XSS, Open Redirect)	$100 - $1,000	$5,000
Medium (IDOR, CSRF, SSRF)	$500 - $5,000	$15,000
High (Auth Bypass, SQLi)	$2,000 - $20,000	$50,000
Critical (RCE, Chain Exploit)	$10,000 - $100,000	$1,000,000+

Notable Bounty Payments

Year	Researcher	Target	Vulnerability	Payout
2022	(Anonymous)	Apple	Kernel RCE	$500,000
2023	(Anonymous)	Meta	Account takeover chain	$200,000+
2024	(Multiple)	Microsoft	Hyper-V RCE	$250,000
2024	(Anonymous)	TikTok	Various	$100,000+

How to Start in Bug Bounties

Learn the basics — Web application security (OWASP Top 10), Burp Suite, HTTP knowledge
Practice — PortSwigger Web Security Academy (free), HackTheBox, TryHackMe
Choose a platform — HackerOne or Bugcrowd for public programs
Start with VDPs — Vulnerability Disclosure Programs (no money, but builds reputation)
Read disclosure reports — Learn from published write-ups
Find your niche — Some researchers specialize in GraphQL, SSRF, or mobile APIs

7. The Vulnerability Broker Market

A controversial aspect of disclosure is the vulnerability broker market:

Broker	Type	What They Do	Controversy
ZDI (Trend Micro)	White market	Buy vulnerabilities, report to vendors, publish after patch	Generally respected
Exploit Group	Grey market	Buy exploits, resell to governments	Secretive, may not fix
Dark Web Markets	Black market	Buy/sell exploits for criminal use	Illegal

The Bigger Controversy — Government Stockpiling:

Country	Known Vulnerability Stockpiling Program	Example
USA	NSA (Equation Group)	EternalBlue — leaked, caused WannaCry/NotPetya
Russia	FSB, GRU	Zero-day exploits used against Ukraine, US
Israel	NSO Group	Pegasus spyware — used zero-days against journalists
China	PLA/Political	Zero-day exploitation in APT attacks

The Vulnerability Equities Process (VEP): In the US, the government has a formal process (VEP) to decide whether to disclose a vulnerability to the vendor or retain it for national security purposes. Critics argue the VEP is broken, citing EternalBlue as proof.

8. CVE System — Deep Dive

CVE (Common Vulnerabilities and Exposures) is the dictionary of publicly known cybersecurity vulnerabilities.

CVE ID Format

CVE-YYYY-NNNNN
│    │      │
│    │      └── Sequential ID (≥4 digits)
│    │
│    └────────── Year assigned
│
└────────────── Fixed prefix "CVE"

Examples:

CVE-2021-44228 — Log4Shell
CVE-2014-0160 — Heartbleed
CVE-2017-0144 — EternalBlue
CVE-2023-44487 — HTTP/2 Rapid Reset DDoS

How to Get a CVE

Find a vulnerability — must be reproducible, security-related, and affect a distinct product
Report it responsibly — contact the vendor
CVE Numbering Authority (CNA) — the vendor (or another CNA) assigns the CVE
CVE is published — typically when the advisory goes public

CNA Types:

Type	Example	Who They Serve
Vendor CNA	Microsoft, Google, Apple, Apache	Their own products
Researcher CNA	Talos, ZDI	Vulnerabilities they discover
National CNA	CERT-Bund (Germany), CERT-FR (France)	Organizations in their country
MITRE (Root CNA)	MITRE Corporation	Everything not covered by other CNAs

9. What NOT to Do (Unethical Disclosure)

Unethical Practice	Why It's Wrong	Legal Consequence
Selling on dark web	Enables criminals to attack innocent users	Felony (conspiracy to commit fraud)
Public shaming without notice	Puts users at risk for zero-day attacks	Possible lawsuit (negligence)
Extortion	Threatening to publish unless paid (beyond bounty)	Blackmail — felony
Full disclosure of unfixed flaws	Gives attackers a free map to unpatched systems	May violate terms of bug bounty / NDA
Doxxing security contacts	Harassing the individuals who fix bugs	Harassment — criminal

10. Legal Protections for Researchers

Safe Harbor

Many organizations offer Safe Harbor — a legal promise not to sue researchers who follow responsible disclosure:

"We will not pursue legal action against researchers who follow our disclosure policy."

What Safe Harbor covers:

Following the responsible disclosure process
Staying within scope
Not exfiltrating or damaging data
Reporting in good faith

What Safe Harbor does NOT cover:

Testing outside scope
Exfiltrating or publishing user data
Attacking systems you don't own (testing a third party's system)
Violating the Computer Fraud and Abuse Act (US law preempts company policy)

Section 230 / Good Faith Research

The US Cybersecurity Information Sharing Act (CISA) and some state laws protect:

"Good faith" security research
Vulnerability disclosure
Following coordinated disclosure policies

International Laws Comparison

Country/Region	Key Law	Protects Researchers?	Notes
United States	CFAA (18 U.S.C. §1030)	⚠️ Partially (after Van Buren v. US, 2021)	CFAA reform narrowed "unauthorized access" definition
European Union	GDPR + NIS Directive	✅ Yes (for authorized testing)	Strong data protection; privacy impact
United Kingdom	Computer Misuse Act 1990	❌ No explicit protection	£5,000 fine + 6 months for unauthorized access (even benign)
Germany	§202a StGB (Hacking paragraph)	✅ Recent reform (2023) protects security research	One of the most progressive EU researcher protections
Canada	Criminal Code §342.1, PIPEDA	⚠️ Mixed	Some specific exemptions for research
Australia	Criminal Code Act 1995, Privacy Act	❌ Limited	High-profile case of researcher prosecuted
Netherlands	Dutch Computer Crime Act	✅ Good (prosecutorial guidelines protect researchers)	Clear published guidelines

11. Disclosure Decision Flowchart

Use this when you find a vulnerability:

You found a vulnerability
        │
        ▼
Are you authorized to test this system?
        │                       │
       YES                      NO
        │                       │
        ▼                       ▼
Report via bug bounty    Do you have permission
or client channel        from the system owner?
        │                       │
        ▼                 YES   │   NO
    (Go to                  │   │
     remediation)           ▼   │
                      Report via    ────► STOP
                      security@     │    (It is illegal.
                      or PSIRT      │    Do not proceed.)
                           │
                           ▼
                    Is there a bug bounty
                    or disclosure policy?
                           │
                     YES   │   NO
                      │         │
                      ▼         ▼
                Follow program  Propose a
                guidelines      timeline to
                                vendor (7-120 days)
                                │
                                ▼
                          Did vendor respond?
                                │
                          YES   │   NO
                            │       │
                            ▼       ▼
                      Coordinate   Escalate via
                      the fix      CERT/CC or
                                   reconsider
                                   timeline

Responsible Disclosure : How to Report Vulnerabilities Ethically

Table of Contents