Skip to content
Opinion / Commentary

Apple's CVE Transparency Problem Is Also the Industry's CVE Transparency Problem

Apple routinely patches vulnerabilities without disclosing CVE IDs, adding them retroactively weeks later. This is criticised as a transparency failure. But Apple is not uniquely bad at this — it is doing what the industry's incentive structure rewards.

CipherWatch Editorial · Security Intelligence Platform
4 min read
Commentary

Apple’s retroactive CVE disclosure practice generates criticism in security circles every time it surfaces. This week, Apple added CVE details to multiple prior releases — including a root escalation in CoreServices and a Siri Private Browsing bypass — weeks after the patches were distributed. The criticism is familiar: Apple is opaque about what it fixes, CVE disclosure is incomplete, enterprise patch management suffers.

The criticism is correct. What is less often examined is whether the incentive structure would produce different behaviour if Apple chose to be more transparent.

What Transparent Disclosure Costs

When Apple patches a vulnerability and simultaneously publishes a detailed CVE with technical description, two things happen: defenders can verify they are protected, and attackers have a roadmap for engineering a working exploit against unpatched systems.

Apple’s install base update rate is higher than Windows, but not uniform. At any given moment following a security release, a significant fraction of Apple devices have not yet applied the patch — often legitimately (managed enterprise fleets, devices awaiting compliance testing, devices that are offline or deliberately deferred). For those devices, a detailed CVE published on patch day provides a head start to attackers developing exploit code.

Apple’s position — and they have articulated versions of this explicitly — is that delaying or omitting CVE details reduces the exploit development window for unpatched systems. This is not a fabricated justification. It is a real trade-off that Apple has resolved in favour of deployment safety over transparency.

The argument is more coherent for consumer iOS than for enterprise macOS. iOS update adoption rates are genuinely high, and the window during which a detailed CVE creates attacker advantage is relatively short. For enterprise macOS environments where patch cycles are slower and more deliberate, the opaque disclosure practice creates sustained operational problems that Apple’s model does not weight heavily enough.

The Industry Norm

Apple is not uniquely opaque. Microsoft occasionally patches vulnerabilities with minimal detail, adding analysis later. Cisco has historically described vulnerabilities in terms designed to obscure exploitability. Palo Alto has issued advisories that omit CVSS scores until after the 90-day disclosure window. Oracle’s quarterly CPU advisories are infamous for providing vulnerability information at a level of detail that makes independent severity assessment nearly impossible.

The difference is that Apple’s consumer-facing brand profile makes its transparency failures more visible. When Apple adds retroactive CVE details, it gets covered. When Oracle’s patch notes make security engineers’ jobs harder, it generates frustration in security forums but not mainstream coverage.

The underlying problem is that no regulatory or contractual mechanism forces comprehensive, timely CVE disclosure from software vendors. NVD publication timelines are controlled by the vendor. CERT/CC coordination is voluntary. Project Zero’s 90-day deadline applies to Google’s researchers; it does not create obligations for Apple when Apple is the vendor. CISA’s Secure by Design guidance encourages transparency but cannot compel it.

What Would Actually Change This

Two levers could meaningfully change vendor disclosure norms:

Regulatory requirements: The EU’s Cyber Resilience Act (CRA), which took effect for connected devices in 2026, imposes security reporting obligations on manufacturers. If enforcement includes CVE publication timelines and disclosure completeness requirements, Apple — which sells extensively into EU markets — would face a regulatory incentive to improve. The details will matter.

Procurement requirements: Large enterprise customers and government buyers can require security advisories to include CVE IDs at release, with technical descriptions, as a condition of vendor contracts. This is feasible for major platform vendors and would create market pressure.

Until those levers exist, Apple’s behaviour reflects a rational response to the current incentive structure. The criticism is warranted. So is the acknowledgement that the industry built the structure that produces this outcome.

Share this article