Disclosure-Gated Vulnerability Management Runs on Other People’s Clocks

Scan-first vulnerability management has run out of road, and the obvious replacement still depends on somebody else deciding to tell you.

A scan-first program starts when the scanner says so: CVE, scanner check, finding, ticket, SLA clock, patch. Take away the CVE and none of the later steps happen. That design made sense for twenty years. The CVE gave auditors something to sample, gave the ticketing system a key, and gave the SLA a start date, and it was the one unit that covered all three. Scanner vendors competed on how many CVEs they detected, so buyers came to treat the CVE list as the full inventory of what could hurt them.

Why isn't the vendor advisory enough?

Because the advisory is still a disclosure gate. The fix Anton Chuvakin laid out in an October post makes the vendor advisory a first-class input next to the scan. Vendors publish machine-readable advisories, scanner vendors ingest them and create findings without a CVE, and programs track currency against the vendor's latest security release. That is better than what most programs have. You've moved from "the scanner vendor decided this matters" to "the software vendor decided to tell you." Both are decisions made by somebody who is not you, about an environment that is not yours.

In an enterprise, a silent fix lands like this. The release notes say "security fixes," maybe with a count, usually without. The vendor knows which function got patched; you get a version string. Your scanner, if it has a check at all, files it as "outdated version" at informational severity, and no SLA tracks informational. Now scale that across every vendor running a frontier model against its own codebase this quarter. Anthropic said in May that it and its Project Glasswing partners had used Mythos Preview to find more than ten thousand high- or critical-severity vulnerabilities. The company also said the constraint is now how fast anyone can verify, disclose, and patch them. The fixes that never get a CVE are invisible to your scanner, and most of them will ship the way I just described.

TrueConf Server shows the timing. TrueConf shipped fixed builds for a remote, unauthenticated bug on June 18, Kaspersky says attackers were exploiting it by July, and the CVE, CVE-2026-72529, did not surface until August. A scan-first program had nothing to ticket from the June fix to the August CVE, which put the July attacks inside that gap.

I'd call both models disclosure-gated vulnerability management. Disclosure-gated vulnerability management is any program that can act on a vulnerability only after someone else discloses it, as a CVE, a scanner check, or a vendor advisory. Scan-first and advisory-first differ only in who holds the key.

What does your program know about software nobody has disclosed anything about?

For a disclosure-gated program, the honest answer is "its version number," which makes your exposure picture a function of other people's publishing schedules. Attackers do not run on those schedules. Patch diffing with frontier models is cheap: in its June N-day study, Anthropic's red team had Mythos Preview build 8 full exploit chains from 21 Windows kernel patches, with no source code. Patch diffing used to be slow, specialist work that bought defenders time to roll out updates. Anthropic's red team says "this bottleneck has largely fallen away."

The operational consequence is a dashboard that reads green while your hosts still run the build with the silently fixed bug. The organizational consequence is worse. The people who patch, in IT and engineering, already can't see a correlation between CVE volume and breach risk, which is why they rightly deprioritize the backlog. Ask them to also patch against a currency metric with no evidence of exploitability behind it and you have spent more political capital for the same skepticism.

A currency metric measures how far behind you are. Which of those releases require action this week is a separate question, and in our deployments 50 to 80% of critical CVEs turn out not to require action. And the top of the ladder is legitimacy. When the board asks "were we exposed to that?" and the true answer is "we don't track anything without an ID," the security function has told the business what its exposure data is worth.

How do you find vulnerabilities that have no CVE or advisory?

You collect runtime evidence: the software's behavior while it runs. What Spektion reports as undisclosed vulnerabilities are exploitable behavior from runtime observability, with the network and identity context attached, mapped to CWEs. For example, a process that loads from a user-writable path, a service that exposes a named pipe with no access control, a listener accepting unauthenticated input on an interface it has no business being on. Those are exploitable whether or not anyone ever publishes a word about them, and they are common. Spektion Research found that 71% of applications with exploitable flaws had no CVE assigned. A disclosure gate cannot see that, by construction. When the vendor ships the quiet patch, you watch the exploitable behavior change, or not, on the patched hosts. That is a currency metric measured in behavior instead of version strings.

Disclosure feeds are the weather report. You want the forecast, and you should demand a better one from your vendors, CSAF and all. But you don't wait for the forecast to find out it is raining on you. You look out the window. Runtime evidence is the window. It also tells you what to change on the host today. If a process loads from a user-writable path, take away write access to that directory and the attack closes, with no vendor patch in the loop.

How do you measure your own disclosure gap?

Anton's post also includes a 30-minute self-test worth running: count what your top vendor fixed in its last three releases against what your scanner flagged. Add a third column: for each of those fixes, what do you know about how that software behaves on your hosts beyond its version string? The gap between column one and column two is your disclosure blind spot. An empty column three is your exploitability blind spot, and it was there before any of this started.

Keep tracking currency and patch the release when it ships. A program built for what Glasswing's ten thousand findings imply also acts on what the software is doing on your hosts. It does not wait for a CVE or an advisory to start. That's the point of the platform.