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.

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".

> 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.

Maybe we should write less software.