[Update: Even before I publish this, I want to keep everything I wrote for now. But I believe this rebuttal is in response to trash written by SpiceWorks and a GPT.]
The world of vulnerability disclosures is growing fast, for a variety of reasons I won’t get into. Suffice it to say my time is limited. So a quick rebuttal to an article on Spiceworks titled “What Are Common Vulnerabilities and Exposures (CVE)? Meaning, Identifiers, Uses, and Challenges” written by Vijay Kanade, listed as an “AI Researcher”. I am not sure if that is code for someone crossing fields from so-called “AI” to vulnerabilities, or this article was written by so-called “AI”. Either way, vulnerability tourist warning.
The MITRE Corporation oversees CVE, supported by diverse bodies called CVE Numbering Authorities (CNAs), encompassing open-source initiatives and government bodies like the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA).
It is important to note that commercial companies are also CNAs, as well as one independent researcher (hi Larry!) that is a CNA.
When a new vulnerability is discovered, the responsible CNA requests a CVE ID from MITRE. For instance, if a security flaw is identified in an open-source software library, the open-source project’s CNA will request a CVE ID from MITRE.
That’s not how it works. The entire purpose of a CNA is that they are assigned a pool of CVE IDs in advance, and can assign them as they need without going to MITRE. This “federated model” as MITRE calls it alleviates them being a primary bottleneck for years.
To better understand the severity of each vulnerability, a Common Vulnerability Scoring System (CVSS) score is assigned. This score indicates the potential negative impact of a vulnerability, ranging from 0 to 10, with higher scores indicating greater risk. The CVSS score considers factors like the vulnerability’s exploitability, potential damage, and ease of mitigating the issue.
CVSSv2 and CVSSv3 base scores do not get influenced by “ease of mitigating the issue”. CVSsv3 temporal metrics include “Remediation Level” but many vulnerability databases, including the National Vulnerability Database (NVD), which does all scoring for CVE IDs. You can see in this example, that they score CVSSv3 base metrics only.
The CVE list, maintained by MITRE, provides a comprehensive database of known vulnerabilities and exposures.
[Citation Needed]
Unfortunately, “comprehensive” is subjective. I’d argue that when a vulnerability database misses over 100,000 publicly disclosed vulnerabilities, it is not comprehensive.
CVE plays a crucial role in cybersecurity by acting as a central repository of vulnerability information. Without CVE, there would be confusion and inefficiency in addressing security issues.
Unfortunately, due to many systemic problems in the CVE ecosystem, and with MITRE directly, there is already considerable confusion, horrible efficiency, and as noted above, incredible blind spots in their data.
Next, in the “Current CVE statistics” heading, the author goes on to quote a report from April 2023 and a second from earlier in 2023. Those are not current for an article written in 2024, almost a year later.
Let’s say a software program used by many has a flaw that allows hackers to sneak in. The tech wizards pinpoint the flaw’s specifics and assign a CVE identifier. This code becomes the universal language for discussing and addressing the flaw.
Except, it isn’t the universal language by any means. That is why we continue to see many vendors use their own advisory IDs, bug tracking numbers, or a mix of those and a CVE ID. This statement is patently false when you consider that 100k vulnerabilities that don’t have a CVE ID. How do you think they get referred to if there isn’t a CVE ID?
But how are these identifiers born? When a vulnerability is discovered, software vendors, cybersecurity researchers, and others rush to report it to a special organization CNA.
This sounds like it was written by so-called “AI” for sure. This is patently false. Sometimes… but far from even most of the time, this does not happen. Researchers are more prone to take it to the vendor first, unless farming CVEs for their resume, which has become a considerable problem as of recently.
But why use these codes? Why not just describe vulnerabilities in plain English? In the vast landscape of technology, with diverse systems and languages, plain descriptions can get tangled. CVE identifiers cut through the chaos, providing a clear, concise reference point everyone can understand.
A vast majority of the time, they do! Until they don’t… like with the Log4Shell vulnerability. There is certainly confusion around that since it has four different identifiers (2021-44228, 2021-45046, 2021-4125, 2021-44530). Take the last, which three years later still has not been rejected despite violating CNA assignment rules.
Next, the “CVE Data Fields” section appears to be written by a GPT. In a couple minutes, I cannot reproduce this act text using ChatGPT 3.5, but the style is similar. One thing that made me think this was GPT-written was this:
Exploit status: This field indicates if the vulnerability has been exploited in the wild. It’s like knowing whether a virus is spreading in a community or contained.
Acknowledgments: Recognizes the people or organizations that discovered or reported the vulnerability. Similar to giving credit to firefighters who put out a blazing fire.
CVE and NVD do not provide these fields. There are associated organizations, like CISA, that maintains the Known Exploited Vulnerability index, or “KEV” that attempt to track that. Acknowledgements simply aren’t done via either, other than relatively recently, noting the assigning CNA which is typically not the person or organization that discovered the vulnerability. The next section, “Importance of CVE Databases” also seems like a GPT-style response. Referencing “CVE Databases”, plural, is odd in our industry. Sure, there are two primary ones, CVE run by MITRE and NVD run by NIST, as well as hundreds of security companies that consume CVE data, put lipstick on the pig, and display it proudly. But referring to them in the plural is not how most people interact with or consume CVE data.
And here we go, this certainly shows the author, or GPT, simply do not understand the most basics of CVE. Looking at “Challenges of CVE” and point five:
CVE identifier shortages: As vulnerabilities surge, unique CVE identifiers might be depleted. This scarcity is like running out of unique names for newborns in a growing population.
This is absurd and laughable. There was an entire ordeal, a multi-year effort, and plentiful news articles that announced the change from the limited four digit style CVEs, to open ended. This happened in 2014, almost ten years ago.
Since SpiceWorks wasted my time, I have not-so-politely reached out to them asking if they will confirm this is GPT trash.