If the CVE program goes away

How many of our security tools would notice if no new CVE were ever published again?

I didn’t know the answer this afternoon, when a letter from MITRE started going around. It’s addressed to the CVE board, signed by a MITRE vice president, and it says that the government contract under which MITRE runs CVE, and related programs like CWE, expires tomorrow, April 16th. It says the government is still making “considerable efforts” to keep MITRE in that role. It doesn’t say what happens if those efforts don’t work out. As I write this, nobody official has said much more than that, and I’ve no idea whether this gets fixed tonight, next week or not at all, so I’m not going to guess. I took an inventory instead.

What CVE actually is

It’s easy to forget how small the core of it is. A CVE ID like CVE-2021-44228 is a name. The program’s job is to make sure each vulnerability gets exactly one, and that there’s a public record saying what the name refers to. Most IDs aren’t assigned by MITRE directly. They come from a few hundred CVE Numbering Authorities, vendors and projects and security companies (GitHub, Microsoft and Red Hat are all CNAs), who get blocks of numbers and publish records for vulnerabilities in their own scope. MITRE runs the root, the services the CNAs publish through, the rules and the website. CISA pays for it.

The scores mostly don’t come from CVE at all. The CVSS numbers most tools show are either supplied by the CNA or added by NIST’s National Vulnerability Database, which is a separate program at a separate agency, and which has had a large backlog of records it hasn’t analyzed since early last year. We’d already learned to live without NVD being prompt. This is the layer below that.

The existing records aren’t going anywhere. They’re published in a public GitHub repository, and plenty of people (me included, about an hour ago) have a clone. What’s at risk is the next one.

Our inventory

So I went through our setup, piece by piece, asking what each part keys on.

Dependabot alerts on our GitHub repos come from the GitHub Advisory Database, which has its own GHSA IDs and its own reviewers, and GitHub is a CNA. A lot of GHSA entries are created from CVEs, though, and an advisory that never gets a CVE is one that a lot of other tools won’t pick up, so this keeps working but gets thinner.

bundler-audit on the Ruby services reads the community ruby-advisory-db, whose entries list CVE and GHSA IDs. dotnet list package --vulnerable for the C# services uses vulnerability data that NuGet takes from the GitHub database. Same story as Dependabot, roughly.

The container image scanner is the one that worried me. It matches installed OS packages against the distributions’ own security trackers, which are mostly organized around CVE IDs, and it pulls severities from NVD. If the distros keep publishing fixes under their own advisory numbers, the scanner can still see “this package has a newer security release”, but the thing it shows us, and the thing we sort by, is a CVE with a score.

And then there’s the part that isn’t a tool at all. The patching SLA that a forgotten Struts jar slipped past in 2017, critical issues in anything internet-facing within 7 days and anything internal within 30, is written in terms of CVEs and their severity. So are the answers we give on customer security questionnaires, which ask how quickly we patch “critical CVEs”, in those words. So is the vendor tab in the spreadsheet we built during Log4Shell, where we tracked which vendors were affected by CVE ID.

What CVE gives all of these is a join key. When a scanner, Dependabot, a vendor’s advisory and a customer’s question all mention CVE-2025-something, I know they’re talking about the same bug. Without that, each feed has its own name for it, and the first job of every alert becomes working out whether it’s one we already know about. That’s the cost I hadn’t thought about before today. The information would mostly keep coming, but it would stop lining up.

What I’m doing this week

Not much that’s dramatic. I’m adding the OSV feed for our ecosystems as a second source, because it already aggregates GitHub’s advisories, the Python and Go databases and others, under their own IDs, with aliases between them where they exist. I’ve asked whoever’s on security rotation to keep an eye on the distribution trackers directly for the base images we use, for a few weeks, instead of trusting that the scanner will notice. And I’ve rewritten the first line of the patching policy to say “security fixes with a published advisory” rather than “CVEs”, which is what it always meant.

The CVE program dates from 1999. I’ve spent my whole career with it as part of the furniture, and most of the reaction I’ve seen today is people realizing the same thing at the same moment. I’d like to think it gets sorted out by tomorrow. If it is, I’ll still keep OSV in the pipeline, because it turns out we had a single point of failure in a place I’d never thought to look.