[Quick update! This was titled ‘2026’, but Josh Bressers pointed out I missed that Netscout’s blog is from 2024. It came up a few days on a Google Alert so I mistakenly assumed it was a new blog. I have updated the title, but the URL slug will still say 2026. Either way, I think the point remains!]
Every year I hold out hope that the security industry will better understand the Common Vulnerabilities and Exposures (CVE) system. A surprising number in this industry barely know about it, let alone any meaningful details. It’s one thing for a random security wonk in a back corner somewhere, laser-focused on their myopic work not to. It’s another thing for a security company that offers “unmatched visibility with the data that drives observability, fortifies security, and fuels resilience” and claims to have “redefined visibility to tackle the observability, cybersecurity, and AI challenges of the world’s largest, most complex organizations.“
In the past I have written this similar style blog after Spiceworks showed a lack of understanding of CVE, another after Redscan had curious comments about CVE, and yet another after Anaconda tried to explain CVE to data scientists. This time, Netscout jumps into the fray trying to explain CVE to whoever reads their blog and gets many things wrong. In their blog titled “What are Common Vulnerabilities and Exposures (CVE)?” they use a ‘Frequently Asked Questions’ (FAQ) style approach to trying to impart their skewed knowledge of the program.
So here is a simple break-down and rebuttal to help educate the “Guardians of the Connected World” as they refer to themselves, and even trademarked. It’s baffling that so many companies go to a security provider that doesn’t seem to get an industry cornerstone of vulnerability tracking. But, here we are, in the stupidest timeline.
The identifier is compiled in a standardized format, being “CVE-Year-XXXX” with the X’s being arbitrary digits. To avoid boiling over at 10,000, additional digits, up to 6 total digits, can be added to arbitrary numbers once they have exhausted what is available.
Wrong. Per the CVE spec change, it is not limited to six digits. There are literally CVE IDs with seven digits currently. For example, CVE-2017-1000001! Please Netscout, don’t try to explain why that happened either, it is a popcorn-fueled episode of drama in the CVE world.
The CVE Board and CNAs are tasked with investigating and validating reported issues to ensure that only true vulnerabilities and exposures are published.
Wrong. The CVE Board, previously the CVE Editorial Board, has not been tasked with that since the initial year or two. The last 25 years, that is not their purpose. Today, not even MITRE or the CNAs are necessarily tasked with this, as odd as it sounds. You only have to… *checks notes*, ah yes, work with CVE data to know this. Check out CVE-2025-23175 or CVE-2025-36892 for examples. CVE, the CNA, and NVD did nothing to enrich those descriptions. CVE and NVD did nothing to investigate or validate. The CNA, Android, presumably did the investigation and validation, but we’re left with so little information we cannot distinguish it from any other vulnerability other than the CVE ID itself. And given how often duplicate assignments happen, we cannot even rely on a unique CVE ID meaning it is a unique vulnerability.
Each CVE is assigned a Common Vulnerability Scoring System (CVSS) score to rate the severity of the vulnerability. [..] That said, CVSS scores are not published alongside the CVE listing but must be tracked down using the National Vulnerability Database (NVD).
Wrong. There are countless vulnerabilities that have not been given a CVSS score by NVD. Further, in the last year or two, many CNAs have started providing their own CVSS scores as well as CISA’s Vulnrichment efforts. You can’t rely on these CVSS scores sourced from other places than NVD to appear in NVD, or if so, not necessarily in a timely manner.
Benefits of Using CVE
Keeping up with the most recent CVE releases, as well as submitting CVEs when they arise, is a key step to ensuring organizational security.
Wrong. You’d think that keeping up with CVE is a key step, and sometimes it is? Sometimes it is actually a very misleading step giving organizations a false sense of security. Many vendors don’t “submit” CVEs for their own products to this day. Worse? Even many CVE Numbering Authorities (CNA) don’t assign CVEs for their own published vulnerabilities oddly enough. So just like using CVE for that false sense of security, this statement from Netscout gives the same fuzzy feeling that just isn’t accurate.
Benefits of Using CVE
When vulnerabilities are submitted, a group response triggers to identify them and develop and release a fix in a timely manner. Collaboration among professionals expedites this process by quickly finding the best fix.
Wrong. These statements just get more baffling and make me want to seek out new words for “wrong”. Searching VulnDB, I can find somewhere between 50 and 65 thousand vulnerabilities that have a CVE ID and no solution. I give that range because sometimes there is a solution, but vendors don’t update their advisories among many other difficulties in tracking mitigation information for disclosed vulnerabilities. But the notion that a CVE somehow triggers a fast response, to provide a solution in a “timely manner” is absurd.
The truth is that CVEs show that a software developer takes security seriously and wants to inform users of weak points to keep their networks and applications safe.
Wrong. Again, it’s clear that Netscout doesn’t actually work with CVE data, keep up with the happenings in the CVE ecosystem, and has no awareness of the reality here. First, so many thousands of developers have no idea what CVE is to begin with. Second, there are plenty of disillusioned developers that despise CVE and have no desire to work in that ecosystem. Third, a handful have become CNAs simply to stop the abuse of getting CVE IDs assigned for what are ultimately non-issues. Fourth, look at Microsoft as an example, and look at their advisories. Notice anything? Like the fact that they don’t post advisories for lower severity issues. Do they take security seriously? Arguably yes. Do they want to inform users? Partially, but definitely not fully and certainly not enough to use the ridiculous blanket statement Netscout did.
CVEs also often have limited information, as they are brief and offer only basic references by design.
Wrong. Limited information? Often yes! Brief and “only” basic references by design, no. The actual purpose of CVE, originally, was to unify vulnerability information by linking to the various places and bringing them together under one ID number. By linking to e.g. X-Force, BID, Secunia, Bugtraq, Full-disclosure, OSVDB, etc. that is how the “dictionary” worked. Recall, even from the start, MITRE has argued they are a dictionary rather than a vulnerability database. They can use that word all day long but fundamentally, they are a vulnerability database like it or not.
This, paired with the fact that CVE is intentionally an incomplete database, limits its true power.
Wrong? Citation needed! Where did CVE ever say it was intentionally incomplete? Of course they are incomplete, very much so. But where do they say that is by design?!
Sorry Netscout, please submit your homework again. This did not get a passing grade.
p.s. May want to fix your domain. Requiring people to use “www” is so 1998.
Leave a Reply