Security Vulnerability Disclosure

Vulnerability Disclosure

A vulnerability without a disclosure process is a vulnerability that gets sold to exploit brokers, dropped as a zero-day, or posted on Twitter -- coordinated disclosure turns discovered vulnerabilities into patches instead of breaches

When to Use

• Setting up a vulnerability disclosure program for your organization or product
• Receiving a vulnerability report from an external researcher and deciding how to respond
• Discovering a vulnerability in a third-party product and deciding how to report it
• Writing a security advisory for a vulnerability in your product
• Requesting a CVE identifier and coordinating public disclosure
• Evaluating whether to establish a bug bounty program

Threat Context

The absence of a clear disclosure process creates perverse incentives that make vulnerabilities more dangerous, not less:

• The 2017 Shadow Brokers leak: NSA-developed exploits (EternalBlue, DoublePulsar) were leaked publicly without coordination with Microsoft. Microsoft had patched EternalBlue (MS17-010) one month before the leak -- likely after being notified by NSA -- but many organizations had not applied the patch. The uncoordinated disclosure of the full exploit toolkit enabled WannaCry and NotPetya, two of the most destructive cyberattacks in history, causing billions of dollars in damage. Coordinated disclosure would have provided more time for patching before exploit availability.
• Google Project Zero's 90-day policy: Google's vulnerability research team notifies vendors and gives them 90 days to release a patch. After 90 days, the vulnerability is disclosed publicly regardless of patch status. This policy has been controversial but effective -- it creates a hard deadline that prevents vendors from ignoring or indefinitely delaying fixes. Since its inception, most major vendors have improved their patch timelines.
• Researchers prosecuted under CFAA: Security researchers have faced legal threats and prosecution under the Computer Fraud and Abuse Act for good-faith vulnerability research. In 2022, the US Department of Justice updated its CFAA policy to state that good-faith security research should not be prosecuted. Organizations that threaten researchers with legal action create a chilling effect that suppresses vulnerability reports, leaving vulnerabilities unfixed and users at risk.
• Zerodium and the exploit market: Zerodium and similar brokers pay up to $2.5 million for iOS zero-days and $1 million for Chrome zero-days. When vendors do not have disclosure programs, or when they respond to reports with indifference or hostility, researchers have a financial incentive to sell to exploit brokers instead of reporting to the vendor. The vulnerability remains unpatched while the broker sells it to government clients.

Instructions

1. Establish a vulnerability disclosure program. Every organization that produces software should have a clear, public process for receiving vulnerability reports:

   • security.txt (RFC 9116): Place a /.well-known/security.txt file on your web domain. At minimum, include: Contact: (security email or web form URL), Expires: (date when the file should be considered stale), Preferred-Languages:, and optionally Encryption: (PGP key for encrypted reports) and Policy: (link to full disclosure policy). This standardized file allows researchers to find your reporting channel quickly.
   • security@ email: Establish security@yourdomain.com as the standard contact point. Monitor it 24/7 or within a defined SLA. Configure PGP/GPG encryption so researchers can submit reports confidentially.
   • Disclosure policy: Publish a clear policy that states: what is in scope (your products, your infrastructure, third-party components), what is out of scope (social engineering of employees, physical attacks, denial of service testing), safe harbor language (you will not pursue legal action against researchers acting in good faith), expected response timeline (acknowledge within 48 hours, initial assessment within 7 days, target fix timeline within 90 days), and recognition (how you credit researchers).
   • Response SLA: Acknowledge receipt within 24-48 hours. Provide an initial severity assessment within 7 business days. Provide a timeline for the fix. Communicate status updates at least every 2 weeks for high-severity issues. Coordinate public disclosure with the researcher.

2. Follow the coordinated disclosure process. When you discover a vulnerability in someone else's product, or when a researcher reports one to you:

   • Researcher reports to vendor: The researcher contacts the vendor through the designated channel with a detailed report including: description of the vulnerability, affected versions, reproduction steps, proof of concept (non-destructive), and suggested severity (CVSS score if possible).
   • Vendor acknowledges and assesses: The vendor confirms receipt, assigns a tracking number, and evaluates severity. The vendor communicates the assessment and expected fix timeline to the researcher.
   • Vendor develops and tests the fix: The vendor develops a patch, tests it across affected versions, and prepares the advisory. The researcher may verify the fix if the vendor provides a pre-release.
   • Coordinated public disclosure: Vendor and researcher agree on a disclosure date. The vendor releases the patch and advisory simultaneously. The researcher publishes their write-up. Users can apply the patch immediately upon learning of the vulnerability.
   • Standard disclosure timeline: 90 days is the de facto industry standard (per Google Project Zero). Some organizations use 45 days for critical vulnerabilities or 120 days for complex issues. The timeline should balance giving the vendor time to fix the issue with protecting users from indefinite exposure.

3. Request and manage CVE identifiers. CVEs (Common Vulnerabilities and Exposures) provide a standardized way to identify vulnerabilities:

   • When to request a CVE: For any vulnerability in a product or library used by others. Internal-only systems do not need CVEs. CVEs help users track vulnerabilities across vendors, tools, and advisories.
   • CVE Numbering Authorities (CNAs): If your organization is a CNA (major software vendors, open-source projects, cloud providers), you can assign CVE IDs directly. Otherwise, request a CVE from MITRE (cveform.mitre.org) or through a CNA that covers your domain.
   • CVE record contents: CVE ID, affected product and versions, vulnerability type (CWE ID), description, severity (CVSS score), references (advisory URL, patch URL, write-up URL), and credit to the reporter.
   • NVD publication: After CVE assignment, the record is published to the National Vulnerability Database (NVD), where it is enriched with CVSS scores and CPE (Common Platform Enumeration) identifiers. This makes the vulnerability searchable and trackable by vulnerability management tools.

4. Write effective security advisories. The advisory is the primary communication to users about the vulnerability and its fix:

   • Title: Short, specific. "Remote Code Execution in Widget Parser" not "Security Update."
   • CVE ID: Include the assigned CVE identifier.
   • Severity: CVSS v3.1 base score and vector string. Provide a qualitative rating (Critical, High, Medium, Low) alongside the numeric score.
   • Affected versions: Explicit version ranges. "Versions 2.0.0 through 2.4.3 are affected. Version 2.4.4 contains the fix."
   • Description: What the vulnerability is (buffer overflow, SQL injection, insecure deserialization), what an attacker can achieve (RCE, data disclosure, DoS), and what conditions are required for exploitation (authentication required, network-accessible, default configuration).
   • Remediation: Specific upgrade instructions. If a patch is not available, provide a workaround (configuration change, WAF rule, feature disable) with a timeline for the permanent fix.
   • Credit: Name the researcher who reported the vulnerability (with their consent). This incentivizes future reports and demonstrates good-faith participation in the security community.
   • Timeline: Optionally include the disclosure timeline (reported date, fix date, advisory date) for transparency.

5. Consider a bug bounty program for mature organizations. Bug bounties incentivize external security research with financial rewards:

   • Prerequisites: Before launching a bug bounty, ensure you have: a functioning vulnerability disclosure program, the ability to receive, triage, and fix reports within the SLA, and engineering capacity to handle the volume of reports.
   • Scope: Define what is in scope (production systems, staging environments, specific applications) and what is out of scope (denial of service, social engineering, third- party services you do not control).
   • Reward structure: Base rewards on severity (CVSS score) and impact. Critical RCE: $5,000-$50,000+. High: $1,000-$10,000. Medium: $500-$2,000. Low: $100-$500. These ranges vary dramatically by organization and industry.
   • Platforms: HackerOne, Bugcrowd, and Intigriti provide managed bug bounty platforms with triage support, researcher vetting, and legal frameworks. These reduce operational overhead compared to running a program independently.

Details

• The economics of disclosure: A researcher who discovers a zero-day has several options: report to the vendor (free or bug bounty reward), sell to an exploit broker ($10,000 to $2,500,000 depending on the target), use it for penetration testing engagements, or publish it for reputation. The vendor's response determines which option is most attractive. A vendor with no disclosure program, no acknowledgment, and no bounty makes the broker option more attractive. A vendor with a responsive program, fair bounties, and public credit makes responsible disclosure the rational choice.

• PSIRT (Product Security Incident Response Team) operations: Large organizations establish a PSIRT to manage the vulnerability lifecycle: receive reports, triage, coordinate with engineering for fixes, manage CVE assignment, write advisories, coordinate disclosure timing, and track metrics (time to acknowledgment, time to fix, time to advisory). The PSIRT is the organization's interface with the external security research community. ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling Processes) provide frameworks for PSIRT operations.

• Legal landscape for security research: The Computer Fraud and Abuse Act (CFAA) in the US, the Computer Misuse Act in the UK, and similar laws in other jurisdictions can criminalize unauthorized access, even when performed with good intentions. Safe harbor language in disclosure policies provides a commitment not to pursue legal action. The DOJ's 2022 CFAA policy update states that good-faith security research should not be charged, but this is prosecutorial guidance, not law. The EU's proposed Cyber Resilience Act includes provisions for coordinated vulnerability disclosure. Organizations should consult legal counsel when drafting disclosure policies and safe harbor language.

• Disclosure timeline negotiation: The 90-day standard is not rigid. If the vendor demonstrates active progress (regular status updates, a confirmed fix date within a reasonable window), researchers typically grant extensions. If the vendor is unresponsive or denies the vulnerability, researchers may shorten the timeline. If the vulnerability is being actively exploited in the wild (a zero-day), immediate disclosure may be warranted because users need to know to apply mitigations even before a patch exists. The goal is always to minimize the total exposure of users.

Anti-Patterns

1. No disclosure policy. Researchers find a vulnerability but have no way to report it. There is no security.txt, no security@ email, and no contact information in the product's documentation. The researcher has three options: give up, disclose publicly (creating a zero-day), or sell to a broker. None of these options result in a coordinated patch. Publish a security.txt and a disclosure policy.

2. Threatening legal action against researchers. A researcher reports a vulnerability and the organization's legal department sends a cease-and-desist or threatens prosecution. This chills future reports -- other researchers see the threat and decide not to report. The vulnerability remains unfixed, but now the organization has also damaged its reputation in the security community. Include safe harbor language in the disclosure policy and honor it.

3. Disclosing without a patch available. Publishing a vulnerability advisory before a fix exists, giving attackers a roadmap without giving users a defense. Coordinate disclosure timing so that the patch and the advisory are released simultaneously. If a workaround exists, publish the workaround immediately and the full details after the patch.

4. Ignoring vulnerability reports. A researcher reports a critical vulnerability and receives no response for weeks or months. The researcher follows up, still no response. Eventually the researcher discloses publicly out of obligation to affected users. The organization is caught unprepared with no patch. Acknowledge reports within 48 hours even if the full assessment takes longer.

5. No CVE assignment. Fixing a vulnerability silently without assigning a CVE or publishing an advisory. Users who track vulnerabilities through CVEs and vulnerability databases do not know the fix exists and do not prioritize the update. Silent fixes leave users exposed because they do not know they need to update. Assign CVEs for all vulnerabilities in products used by others and publish advisories.