Skip to content

PATTERN Cited by 1 source

Pre-disclosure patch rollout

What it is

Sequence the security-remediation timeline so the patch is already deployed to the managed-service fleet before the CVE is publicly disclosed.

Detection → develop fix → fleet-patch all managed instances → public CVE → patched-version distribution to self-hosted tiers. Self-hosted users learn via CVE + community channels on the same day; managed-tier users are protected silently in advance.

The variant of coordinated disclosure that applies when the vendor operates a managed fleet covering most active users.

When to use

  • Internal-discovery vulnerability — the vendor sets the clock.
  • Vulnerability can be patched server-side without customer action.
  • Managed-service fleet-patching capability exists and has sufficient velocity (see fleet patching).
  • No known in-the-wild exploit — the public doesn't already need to defend against the vulnerability.
  • Managed tier covers enough of the user population that patching it materially reduces aggregate exposure.

Don't use when the vulnerability is externally reported with a reporter-set disclosure timeline, when an exploit is already public, when self-hosted users dominate, or when the patch requires customer-side action (credentials, config, client libraries).

Structure

The timeline has three invariants and two knobs:

Invariants:

  1. Patch completes on the full managed fleet before public CVE publication.
  2. Self-hosted tier receives the patched build + CVE notification on or immediately after the CVE publication date — asymmetry with the managed tier is honest, not hidden.
  3. Trust-layer communication — timeline + decisions — is published retrospectively to let customers audit the decisions post-hoc. (MongoDB's 2025-12-30 retrospective, 11 days after CVE, 18 days after detection.)

Knobs:

  • How fast the fleet-patch runs — sets the minimum disclosure window.
  • How maintenance-window customers are handled — silent override, pre-notification override, or opt-in (see maintenance window).

Canonical timing (MongoDB precedent)

From CVE-2025-14847:

  • T=0 Detection (2025-12-12 19:00 ET).
  • T+2 days Fix developed + tested.
  • T+5 days Majority of Atlas fleet patched (2025-12-17 12:10).
  • T+5.1 days Maintenance-window pre-notification sent (21:00).
  • T+6 days Full Atlas fleet patched (2025-12-18).
  • T+7 days Public CVE published (2025-12-19).
  • T+11 days Community forum post for EA + Community Edition (2025-12-23).
  • T+18 days Operational retrospective blog post (2025-12-30).

7-day vendor-side clock; CVE disclosure 1 day after fleet safety; EA + Community informed alongside (4 days later on the community forum, but fully in the public track from T+7 onward).

Properties it gives you

  • Reduced exposure window for managed-tier users. They are protected at T=0 of the public clock, not T+some-fraction-of-90- days.
  • Preserved industry norms. CVE still gets published, severity scoring still applies, self-hosted users still get a patched build — the pattern accelerates coordinated disclosure inside the managed fleet, it doesn't abandon the norm.
  • Aligned with internal-discovery posture. Vendors who invest in internal security research get a second return on that investment through timeline control.

Properties it does NOT give you

  • Protection against externally-reported vulnerabilities. The reporter owns the disclosure clock; the vendor cannot set it. External reports coordinate via reporter-vendor-embargo rather than vendor-first-patch.
  • Self-hosted-tier speedup. EA + Community users remain on the slower track; the pattern optimises the managed tier alone.
  • Free pass on staging discipline. Speed without staging is how fleet-wide patches cause their own outages; see Cloudflare 2025-12-05 / 2025-11-18 for the failure mode.
  • Community trust automatically. The asymmetry between managed and self-hosted users is real; communicating it honestly (not hiding it) is what preserves trust.

Structural choices

Silent pre-disclosure

Vendor patches the fleet, publishes the CVE, does not advertise the fact that the fleet was patched in advance. This is the default for most routine security patches in managed services. Minimal attention drawn to the asymmetry.

Announced pre-disclosure

Vendor explicitly publishes a timeline retrospective — "we detected, we patched, we disclosed" — foregrounding the managed-fleet-first remediation as a selling point. MongoDB's 2025-12-30 blog is this shape: the timeline is the communication artefact, not an incidental footnote. This variant builds trust with managed-tier customers at the cost of making the self-hosted-tier asymmetry more visible.

Partner embargo + pre-disclosure

For vulnerabilities that also affect non-managed software (OS libraries, shared components), combine pre-disclosure to managed fleet with embargo to distribution partners, so self-hosted and partner-downstream users are patched via distro channels synchronously with CVE publication.

Operational requirements

See patterns/rapid-fleet-patching-via-managed-service for the fleet-rollout infrastructure. Additional pattern-specific requirements:

  • CVE publication pipeline — CVE numbering authority (CNA) status or coordination with an upstream CNA; authoring discipline.
  • EA + Community distribution channel — patched-version publication, community-forum notification, release notes.
  • Trust-layer publication template — a known blog-post shape for operational retrospectives. MongoDB's 2025-12-30 post is the canonical template: timeline, takeaways, no technical vuln details (those live in the CVE).
  • Internal-discovery capability — security research investment sufficient to find vulnerabilities before external reporters do.

Seen in

Last updated · 200 distilled / 1,178 read