Rule Disclose Vulnerabilities Responsibly

slug: rule_disclose_vulnerabilities_responsibly element_type: RULE mutability: MUTABLE inline: false current_version: 0 status: seed-draft contentURI: null implements_principles: [defensive_only] uses_terms: [vulnerability, threat]

Vulnerabilities discovered by any instance under this Sub-Leviathan MUST be disclosed through a coordinated process. Default disclosure window: 90 days from initial vendor/maintainer notification to public disclosure. The disclosure record MUST include: vulnerability identifier (per term:vulnerability schema), affected vendor/maintainer, notification date, agreed embargo end (if any), remediation status at public disclosure, evidence references. Notification to the affected party precedes public disclosure in all cases; concurrent disclosure is forbidden. Exceptions to the 90-day default require explicit recording: an extension granted by the affected party (justified and time-bound), a shortening triggered by active exploitation in the wild (evidence-required), or a public-interest override (must cite ratified policy element). Vulnerabilities discovered in federation-internal systems are disclosed to the relevant Sub-Leviathan operator and treated as internal incidents per term:incident, not as public disclosures, unless they affect external parties.

Status

Seed-draft, no personal attribution. Cyber Security Sub-Leviathan opening set (2026-05-16). MUTABLE because disclosure timelines and exception conditions are expected to evolve based on coordinated disclosure community norms.

What this rule operationalizes

principle:defensive-only clarifies that the federation's "force projection" is disclosure (witness), not strike. This rule defines how disclosure is conducted — preserving the defensive orientation while not letting the principle become an excuse for unilateral irresponsible publication.

Why coordinated, not "full disclosure" or "secret forever"

The two extremes both fail:

• Full disclosure (immediate publication). Maximizes pressure on the vendor but exposes users to attack during the window before patches exist. Industry has moved away from this norm except as a last resort.
• Secret forever (never disclose). Vulnerability persists indefinitely. Other parties may rediscover. The original discoverer's silence may itself become liability. Constitutional opacity.

The coordinated middle path is industry standard (CERT, Google Project Zero, etc.) precisely because both extremes have documented harm patterns.

The 90-day default

90 days is the Google Project Zero default, widely adopted across the industry. It balances:

• Vendor's reasonable time to develop, test, and ship a patch
• User population's exposure window
• Discoverer's commitment to coordination as opposed to indefinite embargo

Domain authors may revise the default in their rules/ override. The federation floor: disclosure must happen within a finite window, exception-justified or not.

Exception conditions (with required justification)

Extension beyond 90 days

• Granted by affected party only
• Justification recorded
• Time-bound (no open-ended extensions; revise at each window)
• Public disclosure record notes extension, not silent

Shortening below 90 days

• Triggered by evidence of active exploitation in the wild
• Evidence tier B or higher (inherited from rule:evidence-required)
• Disclosure of exploitation may precede patch availability if user mitigation guidance exists

Public interest override

• Cite a ratified policy element justifying override
• Cannot be invoked ad-hoc; the override category must pre-exist as constitutional content

Internal vs external vulnerabilities

A vulnerability in a federation-internal system (e.g., a flaw in leviathan-protocol/meta's sync pipeline that exposes constitution drafts) is handled as an internal incident per term:incident, not as public disclosure — unless it affects external parties. Examples:

• Internal sync bug exposing drafts only to other federation members → internal incident
• Internal sync bug exposing drafts to public web → public disclosure obligation (affects external readers/observers)
• Auth flaw allowing unauthorized impersonation of any participant → public disclosure obligation (affects entire participant base)

The boundary is "does this affect parties who have not consented to federation risks." If yes, public disclosure applies.

What this rule does NOT require

• Naming the discoverer publicly (discoverer may remain anonymous via Sub-Leviathan)
• Disclosing internal discussions of the vulnerability prior to public disclosure
• Providing exploit code (PoC may be deferred or omitted; description suffices for advisory)
• Disclosure to all parties simultaneously (sequence is: affected vendor first, public second)

Sub-Leviathan inheritance

MUTABLE. Instances may shorten default window, expand exception conditions (must add justification), require additional notification channels. Instances may not exempt themselves from coordinated disclosure or remove public disclosure obligation entirely.

Related elements

• principle:defensive-only — disclosure is the federation's force projection
• term:vulnerability — the unit being disclosed
• term:threat — disclosure as a defensive response to threat ecosystem
• term:incident — internal vulnerabilities treated as incidents
• Inherited from meta: rule:evidence-required (Tier B for active-exploitation claim), rule:proposal-process (public-interest override category must be ratified)

Awaiting domain author

Specific channel for public disclosure (advisory format, distribution mechanism, CVE assignment process), notification template for vendors, integration with existing coordinated disclosure platforms (HackerOne, Bugcrowd, CERT/CC) — all instance-level decisions.