The Zero-Day Disclosure Dilemma

Imagine a security researcher discovers a critical vulnerability in widely-deployed software — something affecting millions of systems worldwide. What happens next is one of the most consequential decisions in cybersecurity: how, when, and to whom do they disclose it?

The answer isn't simple, and the security community has debated it for decades. Understanding the major disclosure philosophies helps you interpret the news when major vulnerabilities drop — and shapes how the entire industry handles unknown threats.

What Is a Zero-Day?

A zero-day (or 0-day) is a vulnerability that is unknown to the software vendor — meaning they've had zero days to prepare a fix. The term is often misused to mean "any unpatched vulnerability," but strictly speaking, it refers to vulnerabilities the vendor doesn't yet know about.

Zero-days are particularly dangerous because:

  • No patch exists, so all users of the affected software are vulnerable
  • Defenders can't use signature-based detection since the attack pattern is unknown
  • They command premium prices in both criminal markets and government acquisition programs

The Three Main Disclosure Models

1. Responsible Disclosure (Coordinated Vulnerability Disclosure)

The researcher privately notifies the vendor, gives them a reasonable time window to develop and release a patch (typically 90 days, as pioneered by Google Project Zero), then publicly discloses the vulnerability after the patch is available — or after the deadline passes, regardless.

Advantages:

  • Gives vendors time to fix the issue before attackers learn about it
  • Users get a fix available at the same time details become public
  • Builds a collaborative relationship between researchers and vendors

Criticisms:

  • Vendors sometimes sit on reports for months or years with no progress
  • Researchers have little leverage to force timely action
  • If the bug was independently discovered by a threat actor, "responsible" disclosure just keeps users in the dark

2. Full Disclosure

The researcher publishes complete technical details — including proof-of-concept exploit code — publicly and immediately, without prior vendor notification. Popularized by the Full Disclosure mailing list in the late 1990s.

Arguments in favor:

  • Vendors have historically ignored private reports for years — public pressure forces action
  • The security community can build defenses and detection rules immediately
  • Operates on the principle that information should be free

Arguments against:

  • Hands a working exploit to every attacker before any patch exists
  • Most organizations need days to weeks to deploy patches even when they're available
  • Can cause real harm to users of the affected software

3. Bug Bounty Programs

A hybrid model where vendors formally invite researchers to report vulnerabilities in exchange for financial rewards. Major programs are run by platforms like HackerOne and Bugcrowd, as well as directly by companies like Google, Microsoft, and Apple.

Bug bounties have significantly increased the flow of vulnerability reports to vendors, but they come with their own tensions — low payouts relative to the black market value of some vulnerabilities, scope restrictions that exclude interesting targets, and disputes over severity ratings.

The 90-Day Deadline: Does It Work?

Google Project Zero's 90-day disclosure deadline has become an influential industry standard. The reasoning: 90 days is sufficient time for a competent vendor to produce a patch for most bugs. Publishing after the deadline — even if the vendor hasn't patched — creates accountability pressure and ensures researchers aren't suppressed indefinitely.

The policy is controversial. Some argue 90 days is insufficient for complex bugs in widely-deployed infrastructure software where patches require extensive testing and coordinated rollout across supply chains. Others argue deadlines are the only thing preventing indefinite vendor stonewalling.

When Disclosure Goes Wrong

Several high-profile disclosure situations have illustrated the risks on both sides:

  • Too slow: Vendors sitting on critical reports while users remain exposed for over a year — undermining trust in coordinated disclosure.
  • Too fast: Publishing exploit details for actively-exploited bugs before patches reach most users, enabling a wave of follow-on attacks.
  • Nation-state complications: When vulnerabilities are acquired by intelligence agencies rather than disclosed, they become weapons — as seen when stockpiled exploits are leaked or stolen and repurposed by other threat actors.

What Should Researchers Do?

There's no universal answer, but a reasonable framework:

  1. Check if the vendor has a defined security contact or bug bounty program — use it
  2. Set a clear, reasonable deadline in your initial notification (90 days is standard)
  3. Communicate throughout the process; escalate if you receive no acknowledgment within 7 days
  4. Consider involving a coordinating body (CERT/CC, CISA) for complex multi-vendor issues
  5. Publish after the deadline, with patch information, even if the vendor hasn't fully resolved the issue

The Bigger Picture

Zero-day disclosure is ultimately a question of competing harms and obligations. There's no perfect policy — only tradeoffs between the interests of vendors, users, researchers, and attackers. As the industry matures, coordinated disclosure with enforced timelines has emerged as the pragmatic consensus — imperfect, but better than the alternatives.