Acknowledging Reality in Vulnerability Disclosure

Full Disclosure Still Exists and That’s Exactly the Point

Disclaimer: This post is grounded in personal experience and roughly 25 years of interaction with vulnerability management, across vendors, researchers, operators, CERTs, and open communities. It does not claim neutrality or theoretical purity. It reflects what repeatedly emerges when disclosure leaves policy documents and meets reality. In other words, this is my bloody personal blog, not an official statement.

Every few years, vulnerability disclosure is declared settled. We are told that the ecosystem has matured, that coordinated disclosure is the answer, and that whatever remains outside this model is either irresponsible, obsolete, or simply irrelevant.

And yet, full disclosure is still here.

Not as a historical artifact, not as a provocation but as an active, lived practice that continues to coexist with other disclosure models.

This blog post explains why this coexistence matters, why the evolution of vulnerability disclosure is not linear, and why initiatives like GCVE deliberately choose to support all disclosure models instead of promoting a single “correct” one.

The Myth of Linear Progress in Disclosure

A common narrative goes like this:

We started with full disclosure → we learned better → we now do responsible or coordinated disclosure.

This framing is comforting. It suggests progress, maturity, and consensus. It is also misleading.

In reality, vulnerability disclosure did not evolve along a single axis.

What we have instead is a non-linear space of practices, shaped by:

The disclosure landscape includes, and continues to include:

These models exist in parallel, not as steps in a staircase.
They are chosen, combined, or abandoned depending on context.

Economics: The Hidden Driver of Disclosure Models

Vulnerability disclosure is not only a technical or ethical process.
It is also an economic one.

Disclosure mechanisms range from:

Each of these comes with:

A researcher working for free does not operate under the same constraints as:

Economic incentives shape:

Ignoring this economic dimension leads to unrealistic disclosure policies that assume goodwill, time, and resources are evenly distributed. They are not.

Actors Are Not Rational and Not Aligned

Another recurring simplification is the idea that vulnerability disclosure is a cooperative game between rational actors working toward the same goal.

It is not.

These actors do not share the same incentives, and they are not playing the same game.

So when someone says:

What they are really doing is reducing the problem space to the subset they are comfortable managing.

The remaining cases do not vanish. They simply become unaccounted for.

Why GCVE Exists

GCVE was not created to replace existing identifiers, processes, or disclosure norms.

It was created to support all disclosure models, including:

GCVE explicitly does not take sides in these tensions.

Instead, it assumes something pragmatic:

Vulnerability information exists regardless of how or whether it was disclosed “properly”.

The purpose of GCVE is not to normalize behavior, but to ensure that once vulnerability information exists, it can be referenced, processed, and consumed.

Ignoring inconvenient disclosures does not improve security. It only weakens collective awareness.

Freedom, Accessibility, and Security Intelligence

One of the more controversial aspects of GCVE is the level of freedom it gives to GNAs (GCVE Numbering Authorities).

This freedom is deliberate.

Cybersecurity intelligence does not improve by keeping information unknown.
It improves through accessibility, correlation, and contextualization.

For users, defenders, and analysts, the central question is not:

“Was this vulnerability disclosed in the ideal way?”

It is:

“Can this vulnerability affect me, my systems, or my dependencies?”

Without accessible information:

GCVE is built on the idea that users must be able to access vulnerability information, even when the disclosure path is imperfect, contested, or economically asymmetric.

Freedom here does not mean absence of accountability.
It means not blocking information at the source, while allowing consumers to decide how to interpret and trust it.

Why GCVE Uses BCPs Instead of Enforcement

A frequent question is:

Why don’t you require GNAs to follow strict rules?

Because strict enforcement inevitably creates:

GCVE instead defines Best Current Practices (BCPs):

This approach does not prevent:

What it avoids is using access control as governance.

Freedom is uncomfortable (and many of us know that fact). It allows outcomes that some actors will strongly disagree with.

But it also allows vulnerability information to exist before consensus, outside institutional comfort zones, and without requiring permission.

“Federation Is Dangerous”, We’ve Heard This Before

Some criticism around GCVE focuses on the perceived danger of federation: fragmentation, balkanisation, loss of control.

These arguments are not new.

They closely mirror the concerns raised when Git was introduced:

History suggests otherwise. Federation does not remove coordination it relocates it.

And to be clear: GCVE does not mandate federation.
Centralized models remain fully supported.

As a side note: if GCVE reaches even 1% of Git’s success, we would already consider that a major achievement. (Yes, that is both a joke and a realistic benchmark.)

GCVE and a Non-Reductionist View of Disclosure

Saying “this disclosure model no longer exists” does not make it true.
It only narrows the analytical lens.

GCVE takes a non-reductionist approach by focusing on what vulnerability information needs in practice:

GCVE is designed as an open standard enabling:

This applies equally to:

The objective is not to enforce a single disclosure workflow, but to ensure that all vulnerability information (regardless of origin, model, or economic context) can participate in the same analytical space.

Complexity Is the Reality. Not the Problem.

Vulnerability disclosure is messy. It is legal, economic, technical, political, and human.

Any framework that assumes otherwise will fail at the margins — precisely where many real-world vulnerabilities exist.

GCVE does not attempt to simplify this reality away.
It attempts to acknowledge it, structure it, and make it usable.

Not by declaring one model correct,
but by accepting that security depends on visibility, not denial.

That is not a weakness.

It is the point.