A new opinion piece from SecurityWeek’s Tod Beardsley takes aim at a common vendor practice: patching vulnerabilities silently, with no CVE, no advisory, and only a vague changelog note. The rationale vendors give is that withholding details prevents attackers from getting a roadmap to the root cause. Beardsley argues this logic is backwards.
Once a patch ships, the binary itself is the disclosure. Anyone with a debugger and disassembler, or increasingly, an LLM to accelerate the process, can diff the old and new versions and reconstruct what changed. Beardsley notes that the barrier to sophisticated exploit development has dropped sharply thanks to AI-assisted tooling, making silent patches even less effective at keeping real attackers out.
Who actually gets left behind
The people silent patching fails, according to the piece, are penetration testers, detection engineers, journalists, academics, policymakers, and above all the IT administrators trying to triage patch queues without clear severity or exploitability signals. Few of these groups have the time or skill to reverse-engineer a binary just to figure out if a fix matters. The result: disclosed truth ends up concentrated among the small pool of people motivated enough to reverse-engineer the product, a group that skews toward attackers.
Where a delay might be defensible
Beardsley concedes a narrow case for short delays: fully hosted, SaaS-delivered products where users have no patching decision to make, or products with small, tightly controlled userbases that auto-update within hours. In those scenarios, a brief embargo while the vendor patches its own fleet is more operational detail than meaningful secrecy.
The Tanzu Spring example
The article singles out Broadcom’s expanded program for the Spring Framework (owned via VMware’s Tanzu division), announced for June 2026. Under it, paying customers get validated, CVE-only patch releases through a private Spring Enterprise Repository ahead of the broader open source userbase, even though Broadcom says it will still issue CVEs for every supported version eventually.
Beardsley’s concern is that the open source Spring audience is far larger than the paying customer base, and the lag between private and public disclosure creates a window where well-resourced attackers, who have the budget to access early intelligence, can operate against a large pool of unpatched targets before the wider community gets the same information.
The piece’s broader conclusion: patches should come with forthright disclosure to everyone at once, since most vulnerability information ends up recoverable through patch diffing regardless of vendor intent.