Vulnerability Disclosure When Everyone is Lying — A Pragmatic Stance

The Disclosure Covenant Has Collapsed, and Vendors Are Doing the Arithmetic

When a researcher discovers a flaw in widely-deployed software, the ethical and legal framework that governs disclosure has spent three decades assuming something noble: that vendor, researcher, and regulator all want the same outcome—a patch deployed before adversaries weaponise the defect. That assumption is now simply false, and the industry's continued treatment of disclosure as a governance problem (rather than an adversarial one) is why patches arrive months after exploitation begins, why zero-days persist in active use across threat networks, and why the largest recent supply-chain collapses involved disclosures that were technically correct but operationally useless.

The machinery of responsible disclosure—CVSS scoring, embargo periods, coordinated release windows, vendor SLAs, CVE issuance—was designed to deter a rational attacker. Instead, it has become a mechanism for vendors to defer accountability, researchers to generate credential capital, and attackers to coordinate against a predictable disclosure timeline. The pragmatic stance is not to reform this broken covenant, but to architect systems where the disclosure itself, and the lag it creates, becomes architecturally irrelevant.

The Industry Narrative: Disclosure as Governance Theatre

The published ecosystem of cybersecurity journalism has spent the last 18 months documenting a cascade of high-stakes disclosure failures, each one treated as a deviation from the rules rather than evidence that the rules have failed.

MOVEit Transfer (CVE-2023-34362): Attackers exploited this zero-day in Progress Software's MOVEit transfer appliance across financial institutions, law firms, and healthcare providers before the vendor issued a patch. The timeline was textbook: researcher notification, vendor response, embargo negotiation, patch release. Yet by the time the patch arrived in June 2023, Cl0p and affiliated threat actors were already compromising environments across the supply chain. Progress Software complied with every disclosure protocol. The protocol itself was the problem. Hundreds of organisations patched after adversary access was already present.

Snowflake Tenant Cascade (2024): Between October 2023 and early 2024, Snowflake disclosed a series of account compromises affecting named-tier customers (Ticketmaster, LendingClub, US Treasury subset data handling). The vendor's breach disclosure letters cited "credential stuffing" and "a vulnerability in a third-party integration"—statements that were simultaneously true and operationally misleading. Security researchers and law enforcement later confirmed that attackers had obtained valid credentials through separate breaches (LastPass 2022 key-material leakage among them) and leveraged them against Snowflake's API without triggering multi-factor enforcement. The vulnerability was architectural—Snowflake's default posture allowed credential-based authentication without MFA for programmatic access, a design choice that violated zero-knowledge principles. Yet the disclosure framing pushed responsibility to customers ("enable MFA") rather than the substrate architecture. Snowflake's disclosure was legally defensible; it was also perfectly calibrated to obscure the architectural failure driving the incident.

Change Healthcare Ransomware (February 2024): UnitedHealth's subsidiary, Change Healthcare, suffered a BlackCat/ALPHV ransomware attack that disrupted pharmacy claim submission across the US healthcare network. The breach itself was not a vulnerability disclosure; it was a credential theft and lateral movement problem. But the subsequent disclosure by Change Healthcare—and UnitedHealth's regulatory submissions to the SEC and HHS—became a case study in semantic compliance. The company disclosed the incident to regulators, notification to affected parties, but the SEC filing and HHS OCR notices did not clarify the specific technical failure: attackers obtained valid domain credentials and pivoted through an unpatched MOVEit instance running on-premise infrastructure. UnitedHealth's disclosure satisfied HIPAA Breach Notification Rule timelines and SEC 4-day rule requirements; it did not illuminate the systems-engineering decisions that created the attack surface. Regulators accepted the disclosure. The architecture remained unchanged.

NHS Synnovis Incident (June 2024): LockBit ransomware operators encrypted Synnovis, a UK National Health Service pathology subsidiary, following credential theft and dwell-time exploitation. The incident highlighted a discrepancy between vendor disclosure obligations and NHS operational resilience. Synnovis disclosed to ICO (Information Commissioner's Office) and NHS England; vendors involved in the supply chain disclosed varying degrees of technical detail. The incident review, conducted under DORA (Digital Operational Resilience Act) harmonisation timelines, revealed that Synnovis had been running unsupported legacy software with known CVEs, some with public exploits available for months. Disclosure had occurred. Patches existed. Operational deployment had not. The regulatory examination that followed focused on "incident communication timeliness" rather than "why is critical infrastructure running unpatched software with decades of public documentation?"

In each case, disclosure protocols were followed. In each case, the defect disclosed was either already exploited, architecturally enabled by design choices the disclosure did not address, or operationally irrelevant to the systems-engineering decisions that enabled the breach. The industry narrative treats these as disclosure-speed problems or vendor-honesty problems. They are architecture problems.

Why Disclosure-as-Governance Cannot Work Against Rational Adversaries

The responsible disclosure framework rests on a foundational assumption: that delay imposed on vendors (embargo periods, patch development, staged rollout) will also delay attackers. This was plausible in 1995. It has not been true since approximately 2015, when threat actors began to operate with the same access to vulnerability research, threat intelligence, and reverse-engineering tools as legitimate security vendors.

Consider the adversary's timeline under the current disclosure regime:

1. Attacker discovers flaw (or purchases it from underground markets—a thriving supply chain independent of vendor patch schedules).
2. Vendor is notified; embargo period begins (typically 30–90 days).
3. Vendor releases patch; coordinated disclosure occurs.
4. Attacker now has 48 hours to 2 weeks of signal from patch-diff analysis (comparing patched vs. unpatched code) to weaponise the vulnerability for environments that have not yet deployed.

The embargo period, intended to protect users, operates in the attacker's favour. A sophisticated threat actor does not need the vendor's patch to understand what was fixed—they need only to compare the binary signatures, git diffs (if the vendor uses open-source), or reverse-engineered patch bytecode against the unpatched version. This technique, patch-diffing, is taught in foundational offensive security courses and is now automated by adversary-side tooling. The disclosure lag, therefore, is not a protection—it is an attack window.

More broadly, disclosure assumes vendors will deploy patches at scale. This assumption has failed consistently. As of mid-2024, Shodan and similar passive reconnaissance services detected millions of instances of software with CVEs that had patches available for 6+ months. The Synnovis incident occurred in an environment running software for which patches had been available for years. Disclosure velocity is not the limiting factor; deployment velocity is. And deployment velocity is driven by operational, procurement, and business continuity constraints that disclosure governance cannot address.

The rational attacker therefore does not wait for disclosure—they simply increase dwell time, minimise IOCs (indicators of compromise), and move laterally within networks that remain operationally unpatchable. The Snowflake incident, the Change Healthcare incident, and the Synnovis incident were not prevented by disclosure; they were enabled by architectural designs that disclosure did not, and could not, address.

The PULSE Doctrine: Disclosure Irrelevance Through Substrate Architecture

The pragmatic response is not to reform disclosure governance—to push vendors faster, to shorten embargoes, to mandate patch deployment. These moves are well-intentioned and operationally futile. Instead, the architecture itself must be reconfigured such that the presence or absence of a disclosed vulnerability becomes operationally irrelevant.

This requires three design principles:

Zero-Knowledge Substrate: Infrastructure should be constructed such that the entity operating the system (or the threat actor compromising it) cannot access, store, or exfiltrate the sensitive data or control primitives the system exists to protect. A zero-knowledge substrate does not rely on the strength of a password, the timeliness of a patch, or the integrity of a software component to protect data in motion or at rest—it relies on architectural separation. Snowflake's architectural vulnerability was that valid credentials granted access to data without a secondary control plane enforcing scope or time-bound access. A zero-knowledge redesign would assume that credentials are compromisable and would use cryptographic commitments (merkle proofs, zero-knowledge proofs) to verify access claims without centralised credential validation. The MOVEit vulnerability would have been irrelevant if the substrate assumed file-transfer appliances were untrusted and enforced cryptographic envelope-sealing client-side.

Adaptive Posture: Rather than assuming a static security baseline (patched vs. unpatched, compliant vs. non-compliant), the substrate should implement continuous adversarial posture adjustment. This means the system's access controls, encryption key derivation, and data-plane routing should shift based on real-time threat intelligence, anomaly signals, and time-domain factors—without requiring human intervention, patch cycles, or disclosure notices. If a vulnerable software component is detected in the environment, the substrate should automatically demote its access privileges, rotate its cryptographic material, or isolate it from sensitive data paths—not through a SIEM alert and a human response, but through continuous substrate-level policy enforcement. This removes the need for disclosure to drive remediation; the system self-remediates.

Domain-Specific Primitives: Generic controls (EDR, SIEM, IDS/IPS, DLP) operate on the assumption that detection and response can occur after a breach attempt. They cannot, and they require human operators to interpret threat feeds and discount false positives—exactly the conditions under which disclosure timing matters most. Instead, the substrate should embed domain-specific primitives that cryptographically enforce the rules of the domain at the data-plane level. A financial messaging system should embed atomic transaction settlement primitives that cannot be overridden by compromised middleware; a healthcare record system should embed immutable audit trails and consent-based decryption that cannot be bypassed by stolen credentials.

From Governance to Architecture: Practical Implications

The implications for vulnerability disclosure under a PULSE architecture are radical.

First, disclosure velocity becomes decoupled from patch deployment velocity. A vendor can disclose a CVE immediately—in fact, it is ethically preferable to do so. The disclosure carries no operational burden on customers because the substrate has not relied on that specific component's integrity to enforce security. MOVEit's CVE-2023-34362 could have been disclosed on day one; customers running on a zero-knowledge substrate would have experienced no increase in risk.

Second, the responsibility for managing discovered vulnerabilities shifts from vendors and operators to substrate architects. A vendor that has designed for zero-knowledge, adaptive posture, and domain-specific primitives is not managing a vulnerability problem; it is managing a known-defect inventory problem. The defect is documented, disclosed, and tracked—but the system's security posture does not depend on the pace at which it is eliminated.

Third, the asymmetry between patch-diffing attackers and patch-deploying defenders is eliminated. An attacker cannot exploit a vulnerability that the substrate has architecturally neutralised. This does not require secrecy; it requires design.

This approach is not a replacement for patching or disclosure—it is a supersession of the assumption that disclosure governance can protect systems that are not architecturally resilient to compromise.

The State of Play: Where Disclosure Remains a Liability

Organisations still operating under legacy architectures—those relying on EDR, SIEM, patching, and human response—remain dependent on disclosure velocity and patch deployment discipline. For these organisations, the current disclosure regime is rational, because they have no alternative. But this dependency is precisely the vulnerability that sophisticated threat actors now exploit.

The largest recent supply-chain incidents (Snowflake, Change Healthcare, Synnovis, and the 2024 M&S data breach attributed to Scattered Spider) involved organisations that were fully compliant with disclosure protocols and patch management standards. Compliance is now orthogonal to actual security posture. Disclosure governance has been optimised for a threat model that no longer exists.

Toward a Post-Disclosure Architecture

The path forward requires distinguishing between disclosure (a transparency and governance function) and security (an architectural function). These need not be coupled. A vendor can fully disclose all known defects and achieve full transparency to regulators, researchers, and customers—and the disclosure can carry no implications for operational security posture, because the architecture does not depend on the defects remaining unknown.

This is not a call for obscurity or security through obscurity (a discredited principle for 50 years). It is a call for security through architecture—designing systems that remain resilient regardless of what is known or disclosed about them. When MOVEit's vulnerability was disclosed, thousands of organisations patched. Thousands more did not, and were later compromised. A substrate designed for zero-knowledge would have made the distinction irrelevant.

The vulnerability disclosure covenant has collapsed because it was asked to do something it cannot do: prevent attackers from exploiting defects in systems not designed to survive compromise. Governance cannot fix architecture. Disclosure cannot substitute for resilience.

Operators and architects working under sovereign, post-breach-resistant frameworks interested in moving beyond disclosure-dependent security postures are invited to request a technical briefing under executed Mutual NDA.