I’ve (mercifully) never needed to deal with CVEs, but my understanding is that maintainers often dislike them because the process isn’t run by vendors/developers/maintainers but by “anyone who plugs details in the MITRE form”. After looking at the process a bit, it looks like it would be easy for me to submit a CVE for any product I wanted, give a link to a self-referential security page (“Foo has security issue bar, see CVE-XXX”), and have the same thing happen.
Part of the problem here is that the idea of CVEs is not aligned with what many people think CVEs are.
Ultimately the core idea of the CVE system is just to have a common identifier when multiple people talk about the same vulnerability. In that sense having bogus CVE entries doesn’t do much harm, as it’s “just another number” and we won’t run out of numbers.
But then some security people started treating CVEs as an achievement, aka “I did this research and I found 5 CVEs!” etc. - and suddenly you have the expectation of the CVE system being a gatekeeper of what vulnerability is “real” and what not. (And having seen a lot of these discussions, they are imho a waste of energy, you’ll have cornercases of the form: might be a vuln, might help if you have another vuln to chain together, whether to call it a vuln people will never agree.)
But then some security people started treating CVEs as an achievement, aka “I did this research and I found 5 CVEs!” etc. - and suddenly you have the expectation of the CVE system being a gatekeeper of what vulnerability is “real” and what not.
That is a maddening behavior that I’ve also observed. It’s also a hard thing to fix, considering that the CVE database was conceived in the face of vendors who refused to admit that they shipped security issues. We needed a common way to reference them even if the vendor disagreed.
The fact that you can is a strong checks-and-balance method of making sure that a maintainer cannot stonewall an actual vulnerability and pretend it doesn’t exist. The process is not without flaws, but it’s the devil we know and being an honors system it works surprisingly well. Speaking as a member of a security team in a well known project, the CVE part of the security process is among the least complicated aspects.
It’s even weirder. I needed a CVE once for a library I maintain, and I couldn’t get one! Apparently ranges of numbers are allocated to certain organizations (big corporations and Linux distros), and you’re supposed to ask “your” organization to give you a number. I was independent, and nobody wanted to talk to me.
Having dealt with issuing and publishing CVE details, I can tell you it’s a pain. Up until very recently, there was no good tooling and you had to your own. Synchronize stuff with bug trackers and spreadsheet. It’s no fun. And once you commit a mistake into the CVE details, it’s hard to take it back. It’s a shame that people make stuff up, especially since the internet never forgets..
Maybe Apple thought they need a meta-CVE to talk about “outdated curl on macOS”?
People involved in Red Hat and Debian used to help out the Django project by doing CVEs for us. Then we switched to doing our own direct through the MITRE form. I think we’ve had a couple people threaten to file their own CVEs for things we didn’t feel needed to invoke our security process, but I don’t know of any that succeeded at it yet.
I’ve (mercifully) never needed to deal with CVEs, but my understanding is that maintainers often dislike them because the process isn’t run by vendors/developers/maintainers but by “anyone who plugs details in the MITRE form”. After looking at the process a bit, it looks like it would be easy for me to submit a CVE for any product I wanted, give a link to a self-referential security page (“Foo has security issue bar, see CVE-XXX”), and have the same thing happen.
Strange system.
Part of the problem here is that the idea of CVEs is not aligned with what many people think CVEs are.
Ultimately the core idea of the CVE system is just to have a common identifier when multiple people talk about the same vulnerability. In that sense having bogus CVE entries doesn’t do much harm, as it’s “just another number” and we won’t run out of numbers.
But then some security people started treating CVEs as an achievement, aka “I did this research and I found 5 CVEs!” etc. - and suddenly you have the expectation of the CVE system being a gatekeeper of what vulnerability is “real” and what not. (And having seen a lot of these discussions, they are imho a waste of energy, you’ll have cornercases of the form: might be a vuln, might help if you have another vuln to chain together, whether to call it a vuln people will never agree.)
That is a maddening behavior that I’ve also observed. It’s also a hard thing to fix, considering that the CVE database was conceived in the face of vendors who refused to admit that they shipped security issues. We needed a common way to reference them even if the vendor disagreed.
I’m not sure how I think we should fix it, yet.
The fact that you can is a strong checks-and-balance method of making sure that a maintainer cannot stonewall an actual vulnerability and pretend it doesn’t exist. The process is not without flaws, but it’s the devil we know and being an honors system it works surprisingly well. Speaking as a member of a security team in a well known project, the CVE part of the security process is among the least complicated aspects.
It’s even weirder. I needed a CVE once for a library I maintain, and I couldn’t get one! Apparently ranges of numbers are allocated to certain organizations (big corporations and Linux distros), and you’re supposed to ask “your” organization to give you a number. I was independent, and nobody wanted to talk to me.
Having dealt with issuing and publishing CVE details, I can tell you it’s a pain. Up until very recently, there was no good tooling and you had to your own. Synchronize stuff with bug trackers and spreadsheet. It’s no fun. And once you commit a mistake into the CVE details, it’s hard to take it back. It’s a shame that people make stuff up, especially since the internet never forgets..
Maybe Apple thought they need a meta-CVE to talk about “outdated curl on macOS”?
People involved in Red Hat and Debian used to help out the Django project by doing CVEs for us. Then we switched to doing our own direct through the MITRE form. I think we’ve had a couple people threaten to file their own CVEs for things we didn’t feel needed to invoke our security process, but I don’t know of any that succeeded at it yet.