Every now and then a vendor decides the smartest move is to quietly patch a vulnerability. No hints, no CVEs, no explanation, just the vaguest hand-waving in the changelog. The logic sounds reasonable at first glance: if you don’t explain what a patch does, you avoid giving attackers a road map to the root cause. Why post your mistakes?
Here’s why: Patches aren’t secret once they’re sent. The vendor can skip the CVE, skip the advice, skip the scope, but the binary is still changed on disk and anyone with a debugger and disassembler can tell the difference between old and new and figure out what moved. This isn’t a hypothetical skill, and lately the barrier to entry for sophisticated exploits 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 who can already arm them. Consider who is excluded. Penetration testers you pay to demonstrate risk and threats. Vulnerability management and detection engineers embed signatures into the products you buy for protection. Journalists, academics and politicians trying to explain the risk to important decision makers. Most importantly, IT admins are stacking an almost endless mountain of patches that need some sort of signal of severity and exploitability to decide what to apply tonight and what to wait for the next maintenance window. Almost none of these people reverse engineer your binary to find out if they should care. They have limited time and attention.
Let’s reverse the original rationale. A silent patch does not limit knowledge of the vulnerability to a small circle of people. It limits revealed truth to a small number of people specifically motivated to reengineer your productwhich effectively targets attackers with the skills and incentive to do so. Anyone trying to protect your users is left sorting through incomplete data. As a bonus, this includes your own future product engineers, who might reintroduce the same bug because everyone kept it a secret the first time.
Where the delay is actually defensible
I’ll make a case for anything less than full, immediate disclosure, but it’s narrower than most providers want it to be. Let’s say your product is hosted, delivered via SaaS, and the user essentially doesn’t have to make a patch decision. No downtime to plan, no change log to reference. A short embargo until you patch your own fleet doesn’t hide anything meaningful, it’s an operational detail. The same is true for products with small, tightly controlled user bases, where automatic updates mean that almost everyone is patched within hours, regardless of the time of announcement. In either case, the IT administrator who queues up the patches hardly matters; they are corrected free of charge, so holding details for a few days to a few weeks does not put customers at great risk.
Tantsu’s spring twist
Broadcom, which now owns VMware and, in turn, Spring Framework (via VMWare’s Tanzu division), recently expanded a program worth keeping a close eye on. Considered by its announcement in June 2026paying 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 continue to issue CVEs for every supported version of every Spring project, commercial or open source. The practical effect, however, is early access to exploit intelligence for a price, and the biggest difference between the random criminal kid and the nation-state cyberspy is budget. So unless Broadcom plans to run an unusually robust Know Your Customer (KYC) program around this subscription, you can bet some malicious types will get red flags about otherwise undocumented vulnerabilities.
Short term secrets
The problem with Broadcom’s approach is that the open source audience is much larger than the small minority of paying customers. And while Broadcom will deliver CVEs, advisories, and patches eventually, I worry that the delay effectively creates a window in which the most resourceful attackers can operate with impunity across a significant ecosystem of targets.
The ideal approach to releasing security patches is to be upfront 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 smart enough to discern the patches. In some limited cases (the SaaS and small audience examples above) I can handle a lead with correction and then advice. But it’s almost impossible to justify withholding details for weeks or forever.
Eric C. Raymond once quipped that if there are enough eyes, all mistakes are shallow. Today, I would say that with fast enough engineering, all fixes are advisable.
Connected: AI-driven vulnerability escalation is breaking the traditional patching model
Connected: Stop using CVSS for risk assessment
