Responsible Disclosure: How Vulnerability Reporting Actually Works

You found a vulnerability. Maybe you discovered it during a bug bounty, through security research, or just by accident while using a product. What you do next matters enormously - both for the people affected by the vulnerability and for your own legal safety.

Responsible disclosure is the process of reporting security vulnerabilities to the affected organization in a way that gives them time to fix the issue before the public (and attackers) learn about it. The concept sounds simple, but the practice involves navigating complex timelines, unresponsive companies, legal grey areas, and genuine ethical dilemmas.

What Is Responsible Disclosure?

Responsible disclosure (increasingly called "coordinated disclosure") follows a basic framework:

1. You discover a vulnerability
2. You report it privately to the affected vendor or organization
3. You give them a reasonable amount of time to develop and deploy a fix
4. Once the fix is available (or the deadline expires), you may publish details about the vulnerability

The goal is protecting users. Attackers exploit vulnerabilities regardless of whether they have been publicly disclosed - many vulnerabilities are discovered independently by multiple parties. Giving vendors a head start on patching reduces the window during which users are exposed.

This process works well when both parties act in good faith. The researcher reports clearly and gives reasonable time. The vendor acknowledges the report, communicates progress, and ships a fix. In practice, things often get messy.

A Brief History of Disclosure Debate

The security community has argued about disclosure for decades. The debate has three camps:

Full disclosure advocates believe all vulnerability details should be published immediately. Their argument: vendors only patch quickly when public pressure forces them to. Without disclosure, vendors sit on known vulnerabilities for months or years. The Full-Disclosure mailing list (founded 2002) was built on this philosophy.

Responsible/coordinated disclosure advocates believe in giving vendors time to patch before publishing. Their argument: immediate publication puts users at risk because attackers can weaponize vulnerability details faster than vendors can deploy patches. Most of the industry has settled on this position.

No disclosure advocates (primarily some vendors) believe vulnerabilities should never be published, even after patching. Their argument: any public information helps attackers target unpatched systems. This position has largely lost credibility because it removes accountability for slow patching.

The modern consensus - coordinated disclosure with a fixed deadline - emerged from decades of friction between these positions. Google's Project Zero was instrumental in normalizing the 90-day deadline as a standard.

Disclosure Models Compared

sequenceDiagram
    participant R as Researcher
    participant V as Vendor
    participant P as Public
    
    Note over R,P: Model 1 - Coordinated Disclosure (Standard)
    R->>V: Private vulnerability report
    V->>R: Acknowledgment (1-3 days)
    V->>R: Status updates (ongoing)
    V->>P: Patch released (within 90 days)
    R->>P: Advisory published (after patch)
    
    Note over R,P: Model 2 - Full Disclosure
    R->>P: Vulnerability details published immediately
    V->>P: Emergency patch (reactive)
    
    Note over R,P: Model 3 - Bug Bounty
    R->>V: Report via bounty platform
    V->>R: Triage and bounty payment
    V->>P: Patch released
    R->>P: Disclosure (if permitted by program)

Three disclosure models with fundamentally different timelines and risk profiles

Coordinated Disclosure

The researcher reports privately, sets a deadline (typically 90 days), and the vendor works to patch within that window. If the vendor patches on time, the researcher publishes details after users have had time to update. If the vendor misses the deadline, the researcher publishes anyway to pressure the fix and inform users of the risk.

When it works: Vendor is responsive, patch is feasible within the timeline, and users benefit from advance patching.

When it fails: Vendor ignores the report, requests indefinite extensions, or threatens the researcher with legal action.

Bug Bounty Disclosure

Vulnerabilities reported through bug bounty platforms follow the platform's rules. Most programs prohibit public disclosure for a set period (90-180 days) after the report. Some programs allow disclosure after the fix ships; others never allow it. Researchers trade disclosure rights for guaranteed payment and legal protection.

Full Disclosure

Publishing details immediately, without prior vendor notification. This is controversial and generally discouraged, but some researchers resort to it when vendors have a history of ignoring reports or threatening researchers. The ethical debate around full disclosure is genuine - it forces fast patches but exposes users to immediate risk.

The 90-Day Timeline

Google's Project Zero established the 90-day disclosure deadline as an industry norm. Here is how it works in practice:

Day 0: You discover the vulnerability and document it thoroughly.

Day 1-3: Send a clear, detailed report to the vendor's security contact. Use security@company.com, their published security policy page, or a bug bounty platform. Include a statement that you intend to publish details after 90 days.

Day 1-7: The vendor should acknowledge receipt. If you get no response after 7 days, send a follow-up. Try alternative contacts - the CTO's email, their CERT/CC contact, or a DM to their security team on social media.

Day 7-80: The vendor develops and tests a fix. Ideally, they communicate progress. Some vendors provide regular updates; others go silent until the patch is ready. Both are frustrating - push for at least monthly status updates.

Day 80-90: If the vendor needs a short extension (2-4 weeks) for a legitimate reason (complex fix, coordinated multi-vendor release), granting it is reasonable. Indefinite extensions or vague promises of "we are working on it" without evidence are not.

Day 90+: If the vulnerability is patched, publish your advisory. If it is not patched, you have a decision to make - publish to pressure the vendor and inform users, or extend the deadline further. Project Zero publishes at 90 days regardless, which has proven effective at motivating vendors.

Exception - actively exploited vulnerabilities: If you discover evidence that a vulnerability is being exploited in the wild, the timeline shortens dramatically. Project Zero uses a 7-day deadline for actively exploited bugs. Users need to know immediately so they can take protective action.

CERT/CC and Coordinated Disclosure

The CERT Coordination Center (CERT/CC), based at Carnegie Mellon University, acts as a neutral third party in vulnerability disclosure. When direct communication with a vendor fails or when a vulnerability affects multiple vendors, CERT/CC can coordinate the process.

When to involve CERT/CC:

• The vendor is unresponsive after multiple contact attempts
• The vulnerability affects multiple vendors or products (protocol-level flaws, shared libraries)
• You are concerned about legal retaliation from the vendor
• The vulnerability has national security implications

How it works: You submit a vulnerability report to CERT/CC through their online form. They validate the issue, contact the vendor(s), coordinate patching timelines, and publish a Vulnerability Note (VU#) when the disclosure date arrives. CERT/CC uses a 45-day default timeline, extendable based on circumstances.

CERT/CC's reputation carries weight that individual researchers often lack. A vendor who ignores an email from an unknown researcher may respond quickly to CERT/CC because ignoring them looks bad and can trigger automatic publication.

Other national CERTs (NCSC in the UK, BSI in Germany, ANSSI in France) provide similar coordination services for their respective regions.

Safe Harbor and Legal Protections

The legal landscape for security research is complicated and varies by jurisdiction. Understanding your protections (and risks) is essential before reporting vulnerabilities.

The Computer Fraud and Abuse Act (CFAA) in the United States makes it illegal to access a computer system "without authorization." This law was written in 1986, long before bug bounties existed, and its broad language has been used to threaten security researchers. The 2021 Supreme Court ruling in Van Buren v. United States narrowed the interpretation of "exceeds authorized access," which helps researchers, but the law remains ambiguous.

Bug bounty safe harbor clauses explicitly authorize researchers to test within the program's scope. This provides the strongest legal protection available. If a company has a bug bounty program with safe harbor language, testing within scope is explicitly authorized.

The DOJ's 2022 policy update stated that good-faith security research should not be prosecuted under the CFAA. This is a policy statement, not law, so it provides limited but meaningful protection.

European regulations: The EU's NIS2 Directive encourages coordinated vulnerability disclosure, and several EU member states have enacted or are developing legal frameworks that protect good-faith security research. The Netherlands was an early leader, publishing a responsible disclosure guideline in 2013 that has been widely adopted.

Practical advice:

• Always test within defined scopes (bug bounty programs, published security policies)
• Document everything - your methodology, what you accessed, what you did not access
• Never access, store, or share user data beyond what is necessary to demonstrate the vulnerability
• Use test accounts, not real user accounts
• If in doubt about legality, consult with a lawyer before reporting or use CERT/CC as an intermediary

Handling Unresponsive Vendors

Not every vendor responds professionally. Some ignore reports. Some threaten legal action. Some acknowledge the issue but never fix it. Here is how to handle common scenarios:

No response after initial report: Send a follow-up after 7 days. Try different contact methods - security@, support@, LinkedIn messages to security team members, Twitter/X. If the company has no published security contact, that itself is worth noting in your eventual advisory.

Vendor acknowledges but never fixes: Set a firm deadline and communicate it clearly. "I intend to publish details on [date], 90 days from my initial report." Some vendors will rush a fix when the deadline approaches. Others will not.

Vendor threatens legal action: This happens more often than it should. Do not panic. Document the threat. Consider involving CERT/CC or the EFF (Electronic Frontier Foundation), which has historically supported researchers facing legal threats. Consult a lawyer if the threat seems credible.

Vendor asks for indefinite silence: This is unreasonable. A 90-day initial window with a possible 2-4 week extension is generous. Indefinite suppression of vulnerability information is not responsible disclosure - it is a cover-up that leaves users at risk.

Vendor releases a fix but asks you not to publish: You have no obligation to comply if there was no prior agreement (like a bug bounty NDA). Publishing details of a patched vulnerability helps the community learn and puts pressure on users to update. That said, consider the vendor's relationship and whether the fix is fully deployed before publishing.

Writing a Security Advisory

When the time comes to publish, a well-structured advisory serves both the security community and affected users. Include:

Summary: One or two sentences describing the vulnerability and its impact. This is what people will read first and possibly the only thing non-technical stakeholders read.

Affected products and versions: Be specific. "Widget Pro versions 3.0 through 3.4.2" is useful. "Widget Pro" alone is not.

Technical details: Describe the vulnerability class (e.g., SQL injection, buffer overflow), the affected component, the root cause, and how exploitation works. Include enough detail for security teams to understand the risk and verify the fix, but be thoughtful about including weaponized exploit code for unpatched issues.

CVE identifier: Request a CVE number from a CVE Numbering Authority (CNA) before publication. This creates a permanent, searchable reference for the vulnerability.

Timeline: Document every interaction - when you reported, when the vendor responded, what was communicated, and when the fix was released. This creates accountability and demonstrates that you followed a responsible process.

Remediation: Tell users what to do - update to version X, apply this configuration change, or implement this workaround.

Credit: Include your name (or handle) and affiliation. You did the work; you deserve the credit. This also builds your professional reputation.

Responsible disclosure is a skill that combines technical ability, communication, patience, and ethical judgment. It is not always straightforward, and reasonable people can disagree about specific situations. But the framework exists because it works - vendors patch faster when researchers report responsibly, and users are safer when both parties collaborate in good faith.