So, what if it's a bug in a project that has forked a few times with renames? You're possibly inviting people to ignore a CVE that says "chrome" or "webkit" or "blink" in the name, when in reality it could be from far enough in the past that it affects all of them.

What about project with a license that allows for easy inclusion of source in another project (BSD license, for example). If most people are exposed to the bug through a bunch of other projects that include it, what do you name it? Any choice likely implies something that might keep people from looking closer initially when they are affected.

What about this specific but? Should it say CoreAudio, or iOS, MacOS, or just Apple?

Naming things usefully in a way that conveys additional information is hard. Looking up CVEs is fairly easy. Just throw it into a search engine.

You have it backwards: I can't remember to care about CVE 2025 31200 vs CVE 2025 32100. People should refer to CoreAudio Corruption Antelope and the infrastructure should allow em to easily search for that and get it unambiguosly linked to CVE 2025 31200 (or was it 32100? Better double-check.)

You can remember CoreAudio Corruption Antelope a lot longer than you can care about 2025 301200.

As for whether it's CoreAudio or IOS or Apple or whatever: as long as it is not woefully inaccurate, it's fine. The format is necessary to prevent people from marketing "Extreme Apocalypso" as the name for an input issue in syslog that can only be used to fill a disk slowly.

a CVE is just a link to uniquely identify a specific problem. They often also have names, coined by the people that discovered them, such as "heartbleed". A CVE is similar in concept than a URL shortener but with more procedural name generation.

A CVE is not the actual exploit or security issue, it's a way to reference the exploit or security issue. Internally, before this got a CVE entry, it likely also had an entry in Apple's internal bug system tracking. The identifier for that is similarly just another way to reference this specific problem.

A CVE number is no different than an incrementing ID in a database, except that it encodes slightly more information in the name. You can try to put additional information in the identifier, but it's hard to change after the fact, so you want to be careful what you put. Should you put the score in the identifier? Careful, they often increase after additional scrutiny is given to the issue. What about the product name, as is requested here? Sometimes additional products are discovered that are affected later. Sometimes those are just as important or more as the original, but the correct people that knew weren't contacted until the CVE was released. A CVE is most useful in providing a global id that different parties can use to reference the same item in their own databases.

It's an identifier. Keep it simple. Call it whatever you want in addition to that. If you subscribe to the CISA catalog update mailing list, they reference items like so, which is perfectly fine IMO:

- CVE-2025-4632 Samsung MagicINFO 9 Server Path Traversal Vulnerability

But that's not the CVE itself that is noting what it affects, that is CISA proving a summary of the problem, and notably in this case, one that's more descriptive than listed on the item itself and a combination of a few fields.

Edit: I'll note that from looking at a different response to me, that if you were just suggesting people name stuff more usefully when submitting here, I have absolutely zero problems with that suggestion, which should be obvious by the above. I interpreted your original comment to mean "CVE's should have more context in their names", which is what I disagree with if we're talking about the name as identifier.

CVEs are always filed against a specific product. If it's in a library, then it's typically the library and not all of its user. All of that information is already in the CVE database: https://nvd.nist.gov/vuln/detail/CVE-2025-31200

What OP wanted to stress is that just the CVE number on its own is not very helpful as a title. It would be helpful to at least mention the type of vulnerability and the affected product according to the CVE database entry.

Possibly, in which case, I'm not in disagreement, but that's not how I interpreted "Okay, fine: there is a use for human names for security bugs".

I'm happy to be wrong about this, but it strikes me that the fallacy of this argument is that it says that some bugs would be ignored because of namung confusion. But that's already the status quo for all bugs!

I have a secondary reservation which is that people don't really browse for bugs by name in the way that this argument suggests.

Also, both of them could be solved just by replacing Antelope with a serial number.

> the fallacy of this argument is that it says that some bugs would be ignored because of namung confusion. But that's already the status quo for all bugs!

I don't think so. The difference is when you arbitrarily constrain data your introduce errors and edge cases. Either the name is standardized in which case what can go in portions of it needs to be constrained, or it's not. If it's constrained, someone will need to make a decision on what's appropriate and inappropriate to add. If the list of items that can and should be put in that field is large, you're likely so see some or (most) omitted.

The real question is whether that omission will be viewed as people to imply something is unaffected before they look more closely, and then ignore what might be something important. An argument could also be made that people might see a CVE name without a product and decide that it doesn't affect them, or ignore it when they might have looked closer because something in the name caught their attention, but I think that's a slightly different problem. I think my stance can mostly be boiled down to not wanting to unintentionally train people to rely on something that is unreliable.

I'll freely admit there are cases for both sides of this and differing opinions. It's similar to Postel's law in that it deals to a degree with human nature and people's propensity to take shortcuts (in both actions and thinking), so what we're actually talking about is how we perceive human nature and how it interacts with systems we create.

Software bill of materials type of initiatives could help with that.

Bug names are useful for bugs the average sysadmin needs to know about and talk about, e.g. heartbleed, spectre. This bug feels more like an update and forget it type of bug. I don't think it needs a unique name.

We could name them like hurricanes.

Kind of hard to come up with tens of thousands of huricane names.

Maybe we should write less software.