The Large Project Bias of CVEs

I recently discovered some vulnerabilities in C-Kermit, one dating back to 1984. I tried to do the reasonable thing: create advisories with CVEs.

That turns out to be pretty difficult for a small independent project.

Large projects have a way to self-assign CVE IDs. They are their own CVE Numbering Authority (CNA). There is a massive list of CNAs. Just looking at the first page of results, I see everyone from Airbus to 9front (the niche Plan 9 OS). The OpenKermit project is not a CNA.

If you’re a CNA, you can create and publish CVEs on your schedule. There is apparently no external review process. You can wait for months, or publish immediately.

If you’re not a CNA, you have to find someone that is. The general ones that are CNAs appear to be Github and MITRE.

Since C-Kermit is hosted on Github, I thought I would go that route. I followed the documented procedure: created Github security advisories for C-Kermit, then clicked the request CVE button for each. The documentation states they will typically review within 72 hours.

It’s been a week and a half and no sign of a review yet. Apparently the real review time is more than a month.

The other option for projects without a CNA is via MITRE. You have to use a strange and often broken web form, logging in with either Google or Gitlab. (It seems to be broken on Firefox). Then you submit your request and wait.

How long do you wait on MITRE? It seems it could be anywhere from a day to several months.

The first CVE I obtained for C-Kermit was CVE-2025-68920. At the time, I had not yet started the OpenKermit project. That issue was found and fixed in the context of my work maintaining C-Kermit for Debian, and Debian is a CNA.

These were discovered while wearing my “upstream C-Kermit maintainer” hat. I’m sure I could ask Debian for CVEs again, but that seems a bit cheating; not everyone that maintains a FLOSS project will have connections with a distro like I do.

There are a lot of components of a modern OS and Internet ecosystem that are small projects without a large institution behind them.

This bias towards large organizations when it comes to communicating security problems benefits nobody. It doesn’t benefit users, and only serves to discourage timely communication. Not everyone is as persistent as I am, and when it is made so difficult to make announcements — which seem to go into a giant black hole — it’s easy to say, “why bother?”

By Microsoft’s own admission, they are under-funding their CVE process on Github (which may also be poorly-designed). They blame it on increasing load due to LLMs — a problem they helped create and predicted! Having a fiction about being able to communicate a security issue in a reasonable time is worse than not offering the path at all.

Linux was once a student’s experiment. Let’s not pretend that quality only matters from large projects.