CVE is Broken, and That Matters More Than You Think

The CVE system has become the structural guarantee of your organisation's blindness, not its enlightenment.

The Common Vulnerabilities and Exposures database was designed in 1999 as a shared language for vulnerability coordination. For two and a half decades, it has functioned as the industry's consensus arbiter of what constitutes a "real" security problem worthy of patch cycles, audit compliance, and budget allocation. Yet the CVE system has become catastrophically misaligned with the actual surface of organisational risk. What began as a coordination mechanism has metastasised into a false-confidence engine — one that systematically favours disclosure delays, vendor economic interests, and detection-response architectures that assume breach is inevitable. The result is an ecosystem where organisations dutifully track 24,000 CVEs annually, apply patches in lock-step compliance rhythms, and remain fundamentally unable to distinguish signal from noise. This is not a coordination problem. It is an architectural failure that demands structural response.

The Published Narrative: CVE as Gold Standard

The industry—NIST, the Cybersecurity and Infrastructure Security Agency (CISA), vendors, and regulators alike—has positioned CVE as the authoritative schema for vulnerability taxonomy. The rationale is appealing: a centralised, globally consistent identifier prevents duplicate reports, enables cross-supplier coordination, and provides a neutral arbiter between vendors and researchers. Every significant governance framework references it. The NIS2 Directive (EU Directive 2022/2555, implemented across member states from October 2024) mandates vulnerability management aligned to NIST SP 800-53 and ISO/IEC 27001, both of which treat CVE assignment as a compliance checkmark. The Financial Conduct Authority's FCA Senior Managers & Certification Regime (SM&CR) and operational resilience framework (DORA, effective January 2025) require firms to demonstrate "timeliness of remediation" against officially disclosed vulnerabilities—measured, implicitly, against CVE release dates.

The system's governance structure reinforces this dependency. The National Vulnerability Database (NVD), maintained by NIST, assigns CVSS scores (now in v4.0 iteration) to CVEs and links them to MITRE ATT&CK technique IDs for tactical mapping. Major incidents have driven policy tightening: the 2020 SolarWinds compromise exposed the risk of unsigned software distribution and supply-chain compromise; CISA issued binding Binding Operational Directives (BODs) requiring federal agencies to patch known vulnerabilities within defined windows—the first BOD (20-01) mandated patching of 24 named CVEs within 30 days. Regulatory bodies have followed suit. APRA CPS 234 (Australia) and the SEC's 4-day rule for breach notification (effective 2023) both assume a world where vulnerability management is organised around publicly known, CVE-assigned flaws.

Yet the seams in this edifice have begun to show visibly. The 2024 Snowflake tenant cascade (affecting JIT, Ticketmaster, LendingClub, and dozens of others) was not preceded by a CVE. The attack chain exploited unshared credentials and misconfigured integrations—control failures, not software vulnerabilities in the classical sense. The 2023 MOVEit zero-day (CVE-2023-34362, remotely exploitable file transfer vulnerability) was exploited for weeks before disclosure; Mandiant's timeline suggested active use in the wild before any CVE assignment or patch availability. The 2024 Synnovis/NHS incident, which disrupted blood testing across London, did not require a zero-day—it used known credential compromise and lateral movement techniques, weaponised through ransomware-as-a-service (LockBit), with no single "vulnerability" that a patch would remediate. In each case, the organisations affected were CVE-compliant, patched to baseline, and vulnerable anyway.

The vulnerability disclosure process itself introduces cascading delays. Under the current coordinated disclosure model (NIST SP 800-39 governs a 90-day grace period for vendors), there is an explicit incentive for vendors to delay CVE assignment in favour of patch-first-disclosure-second sequencing. Zero-day researchers face economic and legal uncertainty about whether to report through official channels (CVE assignment delays equity for early reporters) or retain knowledge. The result: real-world adversaries operate across a 60–120-day window where flaws are known to threat actors but not yet catalogued in CVE/NVD, making compliance frameworks useless.

The Structural Failure: Why CVE Guarantees Blindness

The CVE system fails not because individual assignments are wrong, but because its core assumption is architectural nonsense: that vulnerability management can be organised around software flaws disclosed post-hoc, rather than around the adversarial surface of your organisation's actual data and control flows.

Consider the 2023 Latitude Financial breach (Australian consumer data, 9.2 million affected): no CVE was required. The attackers exploited a Pulse Secure VPN appliance after it had been upgraded—but misconfigured, with default-like credentials still active. The vulnerability taxonomy treats this as "weak credential management" or "weak authentication" (mapped loosely to CWE-521, CWE-778), but no CVE assigned because the flaw was not in software logic—it was in operational hygiene. CVE compliance would not have prevented this. Similarly, the 2022 LastPass breach involved credential harvesting from developer machines, exfiltration of vault backups, and cryptographic key extraction—a supply-chain compromise attack that no amount of patching the LastPass software itself would have stopped.

The fundamental problem is category confusion. CVE is designed to track software defects—specific, reproducible code flaws (buffer overflows, injection attacks, race conditions) that vendors can patch. But most organisational breaches do not follow this pattern. Empirical data from SANS ISC logs, Mandiant's M-Trends reports, and CrowdStrike's observations show that breach chains rely on credential compromise, supply-chain poisoning, configuration drift, and lateral movement—threats that exist outside the CVE taxonomy entirely. The 2025 M&S incident (Scattered Spider, manual social engineering and identity compromise) was not a software vulnerability. The 2023 MGM and Caesars breaches relied on leaked credentials and inadequate access controls, not CVEs. The Change Healthcare 2024 incident (UnitedHealth Group subsidiary) was initiated through compromised VPN credentials, again orthogonal to published CVE advisory cycles.

Yet organisations optimise relentlessly against CVE metrics. Budget allocation, team KPIs, audit scoring, and board reporting are all quantified as "percentage of critical CVEs patched within 30 days" or "mean time to patch for CVSS ≥ 7.0". This creates perverse incentives: security teams chase patch velocity against a metric that has decoupled from actual risk. Meanwhile, the architectural problems—identity hygiene, data plane isolation, microsegmentation, zero-knowledge substrate design—languish unfunded because they do not produce CVE-shaped evidence.

The regulatory environment has deepened this misalignment. DORA's "major incident" threshold (Article 18) is now explicitly tied to "significant impact on the continuous availability of critical services"—but the compliance pathway still funnels through NIST CSF, which treats vulnerability management as a detection-response problem. NIS2's Annex transposition across EU member states (Germany's NIS2-Umsetzungsgesetz, France's ANSSI framework, UK PCI-DSS alignment under FCA) all import the CVE-as-baseline assumption. The result is regulatory capture: compliance departments measure security through a lens that no longer correlates with actual threats.

The PULSE Doctrine: Architecture Before Disclosure

From PULSE's perspective, this is not a problem to be solved within the CVE system—through faster assignment, better scoring, more granular taxonomy. It is a problem to be transcended through structural redesign of how organisations hold, transfer, and control sensitive data.

The doctrine rests on a simple inversion: stop assuming breach is inevitable, and design infrastructure where the breach does not matter. This requires three shifts.

First: data plane isolation via zero-knowledge substrate. If your organisation cannot see data in plaintext, neither can an attacker who compromises your infrastructure. This is not encryption-in-transit (that is table stakes). It is architectural: cryptographic primitives embedded at the storage layer, coupled with key derivation that ties decryption authority to immutable identity proofs (FIDO2, verifiable credentials, biometric hardware binding). The adversary may breach your systems, dump your databases, exfiltrate your infrastructure—and retrieve encrypted blobs they cannot read. This is post-breach resistance, not detection-and-response. It does not require a CVE fix to be effective. It does not depend on patch velocity.

Second: control-plane isolation and continuous posture drift. CVE compliance assumes a stable target—you patch to a known-good state, and remain there until the next advisory. Adaptive active defence inverts this: you do not maintain a stable configuration. Instead, you instrument continuous, automated, unpredictable changes to network topology, API gateways, authentication endpoints, and privilege escalation pathways. The adversary may know the flaws in your system (CVEs are public). They cannot construct a reliable attack chain if the infrastructure mutates faster than they can exploit it. This is not "security through obscurity"—it is security through continuous adversarial drift, where the cost of reconnaissance exceeds the value of any individual breach.

Third: domain-specific automation in the substrate, not bolted-on through SIEM/SOAR. Legacy security orchestration (Splunk Enterprise Security, Microsoft Sentinel, Palo Alto XDR) layers detection and response on top of infrastructure designed for throughput, not safety. This creates an arms race where detection tools chase adversaries through logs, and adversaries find new techniques faster than analysts can signature them. PULSE's approach embeds domain-specific logic directly into the data and control planes—not as a monitoring layer, but as a structural constraint. A financial transaction platform does not log suspicious transactions and hope analysts catch them; it enforces cryptographic proof of authorization for every state change, making unauthorised transactions mathematically impossible. A healthcare infrastructure does not detect data exfiltration through DLP rules; it structures access such that PII is only decrypted in the context of specific, auditable use cases.

Practical Principles: From Doctrine to Design

These are not theoretical abstractions. They translate to specific architectural choices.

Zero-knowledge substrate design means your production infrastructure operates on encrypted data. Queries execute against ciphertexts using order-preserving or homomorphic encryption schemes; results are decrypted only in the context of an authenticated user session, where the decryption key is derived from that user's cryptographic identity (a FIDO2 key, a hardware security module binding, a Verifiable Credential). The adversary who breaches your database server obtains ciphertexts. The adversary who compromises a privileged admin account finds that decryption requires cryptographic proof of identity they do not possess. This is not perfect (no architecture is), but it closes the window where credential compromise alone yields data exfiltration.

Control-plane mutation means your API gateways, load balancers, and authentication endpoints are not static. You instrument automated, deterministic-but-unpredictable changes: endpoint URLs rotate hourly; gateway authentication mechanisms shift between OAuth2, SAML, and custom schemes; network paths are rerouted through different infrastructure on each request. The adversary cannot build a reliable exploit chain if the target is mutating. This requires investment in orchestration infrastructure (Kubernetes operators, service mesh, infrastructure-as-code automation), but it moves security from "detecting breach" to "making breach non-exploitable".

Domain-specific automation means embedding regulatory, operational, and risk logic into the substrate. A financial services firm subject to FCA SM&CR does not implement SM&CR compliance through periodic audits and manual policy enforcement—it encodes the rules directly. Every transaction that requires a senior manager sign-off is cryptographically locked until that sign-off is recorded on an immutable ledger (a blockchain, a write-once audit log). A healthcare infrastructure subject to HIPAA or GDPR does not rely on DLP rules to prevent data exfiltration; it structures access such that PII is decrypted only within the context of specific, logged use cases, and the decryption key is revoked immediately after the transaction completes.

Why This Matters Now

The 2024–2025 regulatory environment has made CVE compliance mandatory but not sufficient. DORA, NIS2, and the SEC 4-day rule will drive organisations toward faster patch cycles and better vulnerability tracking—but faster patch cycles against a broken metric do not improve security. They optimise the wrong variable.

Meanwhile, threat actors have moved beyond CVE exploitation. The most consequential breaches in the past three years have relied on credential compromise, configuration exploitation, supply-chain poisoning, and social engineering—attack chains that no CVE patch addresses. Organisations that remain tethered to CVE-driven security investment will find themselves compliant and breached.

The alternative is architectural. It requires rethinking how organisations hold data, distribute authority, and design for post-breach resilience. This is not a vendor problem or a tool problem. It is a systems design problem that demands engagement with operators and architects at the strategic level, not with procurement departments and security operations teams.

For organisations managing critical infrastructure, sensitive data, or currency transfers—those where breach carries existential consequence—the time to move beyond CVE compliance is now.

If you lead infrastructure strategy in a regulated industry and your current security posture is anchored to vulnerability management, request a briefing under mutual NDA to explore post-breach-resistant architecture design.