Every so often a vendor decides the smart move is to fix a vulnerability quietly. No advisory, no CVE, no explanation, just the vaguest handwave in a changelog. The logic sounds reasonable on its face: if you don’t explain what a patch does, you avoid handing attackers a roadmap to the root cause. Why publicize your bugs?
Here’s why: patches aren’t secrets once they ship. A vendor can skip the CVE, skip the advisory, skip the outreach, but the binary still changes on disk, and anyone with a debugger and a disassembler can diff old and new and figure out what moved. That’s not a hypothetical skill, and lately, the barrier to entry into sophisticated exploit dev just got a lot lower thanks to our LLM friends.
Silent patches do not keep vulnerabilities secret. They just keep the details secret from everyone except the people already capable of weaponizing them. Consider who that leaves out. Penetration testers, who you’re paying to demonstrate risk and threats. Vulnerability management and detection engineers building signatures into products you buy for protection. Journalists, academics, and policymakers trying to explain risk to important decision makers. Most importantly, the IT administrators triaging a nearly endless mountain of patches who 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 your binary to find out if they should care. They have limited time and attention.
Let’s flip the original justification around. 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 your product, which, in practice, skews toward the attackers with the skill and incentive to do it. Everyone trying to defend your users is left behind, triaging with incomplete data. As a bonus, that includes your own future product engineers, who might reintroduce the same bug because everyone kept it secret the first time around.
Where a delay is actually defensible
I’ll concede a case for something short of full, instant disclosure, but it’s narrower than most vendors want it to be. Say your 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 you patch your own fleet isn’t hiding anything meaningful, it’s an operational detail. The same goes for products with small, tightly controlled userbases 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 weeks isn’t putting customers at much risk.
The Tanzu Spring twist
Broadcom, which now owns VMware and, by extension, the Spring Framework (through VMWare’s Tanzu division), 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 userbase. 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, and the biggest difference between the casual criminal script kiddie and the nation-state cyber-spy is budget. So, unless Broadcom is planning on running an unusually robust know your customer (KYC) program around this subscription, you can bet that 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, I’m worried 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. After all, most people are on your 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. In some limited cases (the SaaS and small audience examples above), I can get behind a patch-then-advisory head start. But, it’s nearly impossible to justify withholding details for weeks on end, or forever.
Eric S. Raymond once quipped that given enough eyeballs, all bugs are shallow. I’d posit today that given enough prompt engineering, all patches are advisories.
Related: AI-Driven Vulnerability Surge Breaks the Traditional Patching Model
Related: Stop Using CVSS to Score Risk