What Is Coordinated Vulnerability Disclosure? A Complete Guide for Security Teams

Before coordinated disclosure norms existed, the dominant practice was full disclosure: researchers published technical details immediately, arguing that vendor pressure and public awareness were the only reliable remediation drivers. The argument was not entirely wrong. Vendors had a long history of ignoring private reports indefinitely. CERT/CC, founded in 1988 at Carnegie Mellon, pioneered an intermediary model: private notification, a defined remediation window, then coordinated public disclosure. This became the basis for what is now called Coordinated Vulnerability Disclosure. The term responsible disclosure is sometimes used interchangeably, though security researchers increasingly prefer CVD because responsible implies that full disclosure is irresponsible, which is contested.

The tension between full disclosure and CVD is genuine and unresolved. Full disclosure advocates (associated with researchers like Rain Forest Puppy and his 2000 RFPolicy document) argue that vendors will not patch without public accountability, that private reports sit unaddressed for months, and that the public has a right to know about risks to systems they use. CVD advocates argue that publishing before a patch gives attackers a window to exploit the vulnerability while defenders are still unprotected. Both camps have historical evidence for their position. The 90-day deadline was an attempt to enforce vendor accountability while preserving some patch-before-disclosure window.

Step 1: The researcher discovers a vulnerability and verifies it is reproducible. Step 2: The researcher identifies the affected vendor and finds a security contact (security.txt, PSIRT email, CERT/CC). Step 3: The researcher sends a private notification with enough technical detail to reproduce the issue, but not a public exploit. Step 4: The vendor acknowledges receipt and assigns the report internally. Step 5: The vendor develops and tests a patch. Step 6: The researcher and vendor agree on a public disclosure date. Step 7: The vendor publishes a security advisory and patch; the researcher publishes technical details simultaneously or with a short delay. Step 8: A CVE ID is published on the NVD with both the vendor advisory and the researcher writeup linked.

Google Project Zero established the 90-day disclosure deadline in 2014. The rationale was empirical: internal analysis of vendor patch timelines suggested that 90 days was sufficient for most vendors to develop, test, and release a fix. Project Zero's policy included a 14-day grace period if a patch was released within 90 days but had not yet propagated widely. The 90-day standard has become the de facto industry norm adopted by Microsoft's MSRC, most CERT organizations, and now Anthropic's Project Glasswing. Some researchers use shorter windows (45 days for critical vulnerabilities with active exploitation). Some use longer windows for hardware or protocol-level flaws.

When a vendor fails to patch or communicate a credible patch timeline within the disclosure window, the researcher publishes technical details regardless of patch status. This is the enforcement mechanism that gives CVD its credibility as a vendor accountability tool. Without deadline enforcement, vendors would routinely request indefinite extensions. Project Zero has published technical details on schedule even when Microsoft, Apple, and Google products had not shipped a fix, generating significant industry attention and accelerating patch development. Glasswing follows the same principle: unresponsive vendors do not receive extensions, and disclosure proceeds at day 90.

Google Project Zero, founded in 2014, became the most influential standardizer of CVD practice. Its 90-day policy, its commitment to publishing regardless of patch status, and its detailed technical writeups set expectations for the entire industry. Project Zero also introduced the concept of variant analysis: after finding one bug, systematically searching for similar bugs in the same codebase or in other products using the same pattern. This is a technique that AI-driven tools like Claude Mythos now execute at machine scale across thousands of codebases simultaneously.

CERT/CC at Carnegie Mellon remains the primary neutral coordinator for complex CVD cases. Its role is most valuable when: a vendor is unresponsive and an intermediary with institutional authority is needed, a vulnerability affects multiple vendors whose timelines must be synchronized, a researcher and vendor dispute the severity or scope of a finding, or a vulnerability is in an open source project without a dedicated security team. CISA plays a similar coordination role for US critical infrastructure sectors and has established a vulnerability disclosure policy for federal civilian agencies that all FCEB agencies must follow.

Bug bounties and CVD are complementary but distinct. Bug bounty programs pay external researchers to find and report vulnerabilities. CVD is the process by which those reports (or unsolicited findings) are handled before public disclosure. A vendor can run a bug bounty program and still have a poor CVD process. CVD norms apply to all vulnerability reports, whether from paid researchers, academic researchers, or AI discovery programs like Glasswing. The distinction matters for Glasswing: Anthropic does not pay vendors for disclosures, and vendors do not pay Anthropic. The CVD process applies regardless.

Traditional CVD assumed human research scale: a small team finding dozens of vulnerabilities per year. Project Glasswing has produced 1,596 coordinated disclosures, a volume that strains every part of the traditional model. Vendor security teams that receive a single Glasswing notification per year are operating within the traditional model. Vendors with significant codebases may receive dozens. The coordination infrastructure, CERT/CC, CISA, and vendor PSIRTs, was not designed for AI-scale discovery throughput. The security industry is actively developing triage automation, structured disclosure APIs, and machine-readable advisory formats to handle this volume.

Organizations that receive CVD notifications gracefully share three characteristics. First, they have a published and monitored security contact: a security.txt file, a PSIRT email alias, and a contact registered with CERT/CC and the CVE program. Second, they have an internal response process with defined SLAs: acknowledgment, triage, patch development, and public advisory preparation. Third, they have practiced the process before a real notification arrives: tabletop exercises against simulated CVD scenarios produce faster and calmer real responses. Organizations missing any of these three elements routinely miss disclosure deadlines and receive public disclosure of unpatched vulnerabilities.

The step-by-step guide for setting up a CVD response program, including security.txt templates, PSIRT email alias configuration, internal SLA definitions, CERT/CC registration instructions, and the tabletop exercise scenario set used by Glasswing partner organizations, is available in the Mythos Brief.