To view older blog posts, please visit the archives section.

This is part 2 of a series about various issues surrounding the CVE program. If you haven't read part 1, it's available: Maybe it's time for a change? - Part 1

From Alexandria to CISA

The year is 48 BCE. The great city of Alexandria is in the crossfire of a civil war between the forces of Gaius Julius Caesar and Gnaeus Pompeius Magnus. Through the heat of a battle, Caesar sets fire to ships docked close to the great library of Alexandria. The fire spreads and an important part of the world's knowledge is destroyed. Whatever is left is likely destroyed in 272 CE when Roman emperor Lucius Domitius Aurelianus tries to recapture the city. A wealth of unique and handwritten scrolls are lost forever. Centuries later, Johannes Gutenberg, around 1450, invented a solution to this kind of problem: the printing press. It allowed the democratization of knowledge and literacy by reducing the cost of information replication. Then came radio communications and eventually, humanity’s greatest leap in information resilience: the Internet. 

The Internet may be resilient and support free-ish data replication, but the way we structure and consume it, as services, still reflects our deep-rooted preference for centralization. Humans like familiarity. Having all the data neatly organized in one place brings joy to nerds like me. 

And there lies the problem.

The Alexandria Paradox

We humans tend to centralize important things. However, the more something is centralized, the more its loss would be significant. This is what I call the Alexandria Paradox (a term I coined for this post). Centralization can be physical or logical. Above all, it can also be organizational. Such is the case with the CVE Project where management of critical cybersecurity knowledge is centralized through one channel of distribution. A loss of funding or access to the CVE Project would be the modern day cybersecurity equivalent of the destruction of the great Library of Alexandria. It might not be possible to prevent the destruction of such a structure. But there certainly are ways to mitigate the effects of its loss. Let’s explore some of these.

How do we escape the Alexandria Paradox?

First, we need to recognize its presence. The past few weeks certainly did an amazing job doing precisely this on a rarely seen before scale. Then, we need to set requirements that could help in preventing the loss or corruption of a set of knowledge along with full transparency. For an initiative like the CVE Project, a few requirements become absolute essentials:

• Decentralized enough to ensure it cannot be wholly dismantled

• Apolitical

• Free

• Financially independent or diverse enough

• Allow validation of the incoming information

Some of these are definitely achievable: apolitical, free and financially independent are all technically feasible. For example, the project could be financed openly, much like Wikipedia, but governed by a coalition. When it comes to oversight, a board made of independent volunteers and elected by the community could be responsible for this and making sure that the organization stays apolitical. 

On the other hand, decentralization and validation of incoming information (new vulnerabilities being published) are a much harder challenge: these two very much do not play well one with another as centralization tends to more easily allow for the information to be validated.

This is where distributed trust technologies like blockchain offer potential

The last 45 years have seen development beyond anything our Alexandrian ancestors could have ever imagined. The 80’s saw the first breath of blockchain development. 2008 marks the moment where the technology really entered the light with the invention of Bitcoin, the first successful cryptocurrency. Blockchain is, however, not limited to decentralized financial operations. Blockchain-based approaches could technically be used to create any data structure for which management and integrity needs to be decentralized. 

Blockchain appears to offer promising primitives for building a decentralized and open CVE-like vulnerability management program.

What exactly is a blockchain?

Let’s not reinvent the wheel, here’s a high-level description from Wikipedia:

"A blockchain is a decentralized, distributed, and often public, digital ledger consisting of records called blocks that are used to record transactions across many computers so that any involved block cannot be altered retroactively, without the alteration of all subsequent blocks. [...] A blockchain database is managed autonomously using a peer-to-peer network and a distributed timestamping server. [...] A blockchain has been described as a value-exchange protocol. A blockchain can maintain title rights because, when properly set up to detail the exchange agreement, it provides a record that compels offer and acceptance."

Or, in other words: blockchain allows a group of people to collectively exchange information while ensuring the historical integrity of all transactions made to the chain in a decentralized way.

What does this really bring to the table?

Of course, development of such a technology, in a way that satisfies security requirements, would probably be an extensive undertaking. There are many edge cases that certainly would require R&D. However, with the right approach, blockchain could offer the flexibility needed to solve multiple challenges. Coordinated disclosure, for example, could be ensured by having multiple independent parties successively sign the new 'block' (not to be confused with blockchain-level validation, but rather a form of coordinated, multiparty attestation of content). 

Based on this, it could also be possible for security researchers to register their findings to the blockchain by publishing an encrypted version of their reports and privately transmitting the decryption key to the affected vendor’s security team. This would improve attribution of work while also ensuring traceability of any given vulnerability “etymological” evolution. This approach could also enable independent collaboration in enriching vulnerability data from CVSS scoring to deeper analysis and cross-referenced metadata.

“But Phil, this idea has its fair share of weaknesses…”

Absolutely! This article isn’t meant to serve as a blueprint, but a thought experiment.

While blockchain doesn’t solve all aspects of vulnerability management, especially around validation and dispute resolution, it offers a powerful backbone for auditable, tamper-evident coordination, especially if layered with governance and metadata standards.

Some parts of this vision, like encrypted disclosures or distributed validation models would require dedicated protocol design and community coordination. But the potential for a more resilient and transparent alternative to CVE is there.

Additionally, this vision still requires some form of governance to ensure it does not become a complete mess. Governance could, and arguably should, rest with a non-partisan international body. Whether that’s the United Nations or a community-driven consortium modeled after organizations like the IETF or ICANN, neutrality and transparency must be the foundation.

Why is this important?

This is one way to escape the Alexandria Paradox while allowing highly dynamic collaboration in a safe and secure environment for both businesses and independent researchers. With the right safeguards, this kind of project could remain independent and free from political interference, a key requirement in this day and age.

I see no better way to end this post than by quoting the words of George Santayana:

"Those who cannot remember the past are condemned to repeat it."
- George Santayana, The Life of Reason

Can we afford to entrust the most critical security knowledge of our era to a single gatekeeper? History suggests that’s a risk we can’t afford to take.

Do you agree? Disagree? I'd love to hear your thoughts. This is a conversation worth having.