Skip to content

CONCEPT Cited by 2 sources

Coordinated disclosure

Definition

Coordinated disclosure (historically responsible disclosure) is the industry norm by which a security vulnerability is not made public until the affected vendor has had a reasonable window to develop, test, and deploy a fix. The canonical form has three parties — reporter, vendor, public — and three phases: private report → private fix development → public disclosure via CVE / vendor advisory / reporter writeup.

The norm trades off two risks:

  • Publish immediately ⇒ defenders and attackers learn at the same instant; defenders lose the head-start needed to deploy fixes; exploitation velocity maximised.
  • Never publish ⇒ users cannot assess their exposure, vendors have no market incentive to fix, supply-chain consumers cannot reason about downstream risk.

Coordinated disclosure sits in the middle: short enough that users eventually know, long enough that the vendor can ship a patch.

Typical parameters

  • Window length — 90 days is the Google Project Zero default; Microsoft's historical 60-day; GitHub's 90-day; individual researchers sometimes accept 30 or reject coordination entirely.
  • Embargo — pre-disclosure technical detail sharing with partners (OS distros, cloud vendors, hardware makers) before the public publish date.
  • CVE publication — the disclosure artefact: a stable identifier (CVE-YYYY-NNNNN) + brief description + severity scoring (CVSS) + affected-version range + fix reference.

Vendor-first-patch variant

When the vendor owns the deployment substrate for most of the affected users — e.g. a managed service like MongoDB Atlas, AWS RDS, Cloudflare's edge, GitHub's saas — the coordinated-disclosure clock can be collapsed inside the vendor boundary: patch the managed fleet first, disclose publicly after. The self-hosted / on-prem tier still receives the patch + CVE synchronously with public disclosure, but the plurality of users are already safe at T=0 of the public announcement.

Canonical wiki instance: MongoDB CVE-2025-14847 — detection 2025-12-12 19:00 ET, majority of Atlas fleet patched 2025-12-17, remainder 2025-12-18, CVE public 2025-12-19 (1 day after Atlas remediation complete), community-forum post for EA + Community Edition users 2025-12-23 (4 days after CVE).

Structural properties:

  • Internal discovery is load-bearing. An externally-reported vulnerability starts the public clock at a time the vendor does not choose; the reporter may have their own disclosure schedule. Internal discovery → internal clock → the vendor-first-patch posture is structurally available. MongoDB's post explicitly foregrounds its "proactive and continuously evolving security program" as the capability that gives this posture its foundation.
  • Asymmetry between managed and self-hosted users is intrinsic and not hidden. Atlas users are protected before attackers know what to look for; EA + Community users learn alongside attackers. Vendors that run both tiers manage the asymmetry with a community-forum channel, CVE-aligned EA patch release, and transparent timeline publication.
  • Courtesy contracts are honoured with pre-notification, not override. Customer-facing maintenance windows still bound routine updates; urgent security patches get pre-notification ("we will patch your instance tomorrow") rather than silent forced override. The contract shape is "routine ⇒ customer decides when; emergency ⇒ vendor decides when, announces in advance".
  • Communication is split: CVE is the technical artefact (class / severity / versions); vendor blog post is the trust-layer artefact (timeline / decisions / who-knew-what- when). MongoDB's 2025-12-30 retrospective is all trust-layer — the CVE record is the technical reference. This separation is deliberate and mirrors defense-in- depth at the communication layer.

Non-vendor-first-patch cases

When the vendor does not operate a managed fleet — OS kernels, CPU microcode, open-source libraries, self-hosted-only databases — disclosure coordinates across distribution partners (distro security teams, hardware makers) via embargo rather than through a managed-fleet patch. The rollout velocity then depends on how quickly downstream consumers patch — a variable-velocity problem with its own literature (Heartbleed, Log4Shell, Shellshock).

Trust-sensitive-substrate variant

Classical coordinated disclosure implicitly assumes the affected system is a data-processing system whose damage is measured in exploitation — the mitigation is a technical fix, the disclosure's trust effect is second-order. This assumption breaks on trust-sensitive substrates where the affected system's value depends on public confidence in addition to technical correctness — cryptocurrencies, federated trust anchors (CAs, root KSKs), public-safety infrastructure, stock-market venues.

On those substrates, the disclosure has a FUD attack surface: an unsubstantiated or poorly-scoped disclosure can itself drain value or trust from the system without any technical exploitation actually occurring. Google Research's 2026-03-31 post on quantum disclosure to blockchain names this explicitly:

Cryptocurrencies are not simply decentralized data processing systems. Their value as digital assets derives both from the digital security of the network and the public confidence in the system. While their digital security can be attacked using CRQCs, public confidence can also be undermined using fear, uncertainty and doubt (FUD) techniques. Consequently, unscientific and unsubstantiated resource estimates for quantum algorithms breaking ECDLP-256 can themselves represent an attack on the system. (Source: sources/2026-03-31-google-safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly)

The variant extends classical coordinated disclosure with two additional obligations:

  1. Substantiation requirement. The disclosure must provide a mechanism by which the public can verify the claim — classical peer review works for published algorithms; for capabilities the discloser wants to keep secret, a zero-knowledge proof substantiates without revealing (patterns/zkp-capability-disclosure is the pattern).
  2. Scope + defensive-progress framing. The disclosure includes explicit scope (what is and is not affected) and defensive-progress citations (what mitigations already exist), blunting the FUD potential of the disclosure itself.

Google's 2026 blockchain disclosure is the canonical wiki instance — three-component composed disclosure (ZKP + scope clarification + PQ-progress highlighting). The post explicitly declines to claim a finalised norm: "we welcome further discussions with the quantum, security, cryptocurrency, and policy communities to align on responsible disclosure norms going forward." The trust-sensitive-substrate variant is acknowledged as new disclosure-policy territory as of 2026.

Seen in

Last updated · 200 distilled / 1,178 read