CVE Futures

Since last week’s CVE budget kerfuffle, I’ve been drawn into many conversations about “what comes next?” And while I want to say that I don’t know and I haven’t been involved in too long, it turns out I have a perspective that I keep sharing. To summarize: Decide what problem you’re solving.

Since I wrote my post, CISA has made a strong statement:

To set the record straight, there was no funding issue, but rather a contract administration issue that was resolved prior to a contract lapse. There has been no interruption to the CVE program and CISA is fully committed to sustaining and improving this critical cyber infrastructure.

I’m glad that we’re talking about how to strenthen and improve the program. To start, what is CVE?

First and foremost, CVE is a naming system

Naming is a hard problem. To me, the core value CVE provides is a way to cross-reference between databases and tools. I remember when, shortly after the launch of CVE, a vendor launched their own ID system. I think it was bugtraq IDs. I was annoyed. Why would they not use CVE? I’ve learned that each institution wants an identifier that works for them, much like we have ISBNs and UPC codes on books. One serves authors, the other retailers. Bugtraq needed to issue a permanent identifier when things went in their database, and then have that included in the CVE entry. It was the right choice.

A huge reason that CVE has been valuable is the focus on simplicity, and the rejection (or deflection) of requests to do more. The simplicity of the system allows others to layer on things like CVSS, to the point where people conflate and refer to CVE scores. Adding enrichment doesn’t require coordination with CVE, it requires an RSS feed from them.

CVEs are generally public, and the faster CVEs are public, the more useful they are. Generally, CVEs don’t have enough data to point to an 0day. There’s a lot of people who think that more opacity will serve the program, and I disagree. CVE ran very publicly, with the mail archives being public, and that’s to everyone’s benefit, even with the kerfuffle.

What problem do you want to solve?

A lot of the folks who are asking what comes next lack clarity on what they want to do. That’s fine, but it’s also the first thing to settle. When I talk about why we start threat modeling with the question “what are we working on,” I often say that if I come into a room and people can’t answer that question, we can’t do a lot of threat modeling. As we start to answer it, we can get into the question of “what can go wrong?”

If funding is the thing you want to settle, Jen Easterly lays out an important argument, which is that naming is likely a public good. She points out the conflict of interest in letting companies control that, and I’ll add — companies are incredibly opposed to even breach disclosure laws, admitting when they’ve been vicitmized. She’s right that letting them control vuln naming...while, there’s an obvious answer to what can go wrong.

There’s a bit of an elephant in the room when the former director of the Cyber Security and Infrastructure Security Agency of The United States talks about the public good. Perhaps other countries feel that the US view of the public good excludes their public, or that the English-centered nature of CVE should be corrected, or that the US government is now less focused on public good than it has been.

Those concerns are unlikely to be raised in tweets or blog posts, but that doesn’t obviate them. My perspective is that MITRE has the organizational maturity to handle them, and alternate hosts who would do better are ... rare.

If you want to improve the CVE, the first step is identifying the problem. If the problem is funding, I believe that MITRE’s Center for Threat Informed Defense is standing by for donations.

If the problem is something else, start by explaining what it is.

Originally published by Adam on 24 Apr 2025
Categories:   books   software engineering   security