Every so often, a vendor decides to fix a vulnerability quietly, without issuing a CVE or advisory. The logic behind this approach is that by not explaining what a patch does, the vendor avoids handing attackers a roadmap to the root cause. However, this approach has been proven to be ineffective, as patches are not secrets once they are shipped.
The Ineffectiveness of Silent Patches
A vendor can skip the CVE, skip the advisory, and skip the outreach, but the binary still changes on disk. Anyone with a debugger and a disassembler can diff old and new and figure out what moved. This is not a hypothetical skill, and the barrier to entry into sophisticated exploit development has gotten lower thanks to large language models (LLMs).
Silent patches do not keep vulnerabilities secret; they just keep the details secret from everyone except the people already capable of weaponizing them. This leaves out important groups, such as penetration testers, vulnerability management and detection engineers, journalists, academics, and policymakers.
Who is Left Out?
Most importantly, IT administrators triaging a nearly endless mountain of patches need some signal for severity and exploitability to decide what gets applied tonight and what waits for the next maintenance window. Almost none of these people are reverse engineering the binary to find out if they should care. They have limited time and attention.
Silent patching does not limit knowledge of a vulnerability to a small pool of people. It limits disclosed truth to a small pool of people specifically motivated to reverse-engineer the product, which skews toward attackers with the skill and incentive to do it. Everyone trying to defend the users is left behind, triaging with incomplete data.
Justifiable Delay
A delay is actually defensible in certain cases, such as when the product is hosted, SaaS-delivered, and the user has essentially no patching decision to make. No downtime to schedule, no changelog to consult. A brief embargo while patching the own fleet isn't hiding anything meaningful; it's an operational detail.
The same goes for products with small, tightly controlled user bases where auto-update means nearly everyone is patched within hours, regardless of announcement timing. In both cases, the IT administrator triaging a patch queue hardly matters; they're getting patched for free, so withholding details for a few days to a couple of weeks isn't putting customers at much risk.
The Tanzu Spring Twist
Broadcom, which now owns VMware and the Spring Framework, recently expanded a program worth watching closely. As of its June 2026 announcement, paying customers get access to validated, CVE-only patch releases through a private Spring Enterprise Repository before the rest of the open-source user base.
Broadcom says it will keep issuing CVEs for every supported version of every Spring project, commercial or open source. The practical effect, though, is early access to exploit intelligence for a price. The biggest difference between the casual criminal script kiddie and the nation-state cyber-spy is budget.
Unless Broadcom is planning on running an unusually robust know-your-customer (KYC) program around this subscription, some nefarious types are going to get pre-alerts to otherwise undocumented vulnerabilities.
Short-Term Secrets
The problem with the Broadcom approach is that the open-source audience is much larger than the small minority of paying customers. And while Broadcom is supplying CVEs, advisories, and patches eventually, the lag is effectively creating a window where the most well-resourced attackers can operate with impunity in a sizable ecosystem of targets.
The ideal approach to releasing security patches is to be forthright about the risk to everyone, all at once. Most people are on the vendor's side, even if a few bad guys aren't, so it's hard to justify keeping vulnerabilities secret when the patches themselves tell the whole story to anyone with enough patch-diffing smarts.
Given enough eyeballs, all bugs are shallow. I'd posit today that given enough prompt engineering, all patches are advisories.
In some limited cases, a patch-then-advisory head start can be justified. But it's nearly impossible to justify withholding details for weeks on end or forever.
Tod Beardsley, VP of Security Research at runZero, has over 30 years of hands-on security experience and is a CVE Board member.
Source: SecurityWeek