Stop Weaponizing CVE Counts

I've watched many teams score vendors on raw CVE counts. Not on response times, not on disclosure transparency, not on architectural controls. On the number of CVEs. I've seen it first-hand, in the wild, and it needs to stop.

The CVE system was built to encourage responsible disclosure and give the entire industry a shared language for tracking vulnerabilities. It exists to increase transparency. Somewhere along the way, security teams and procurement departments turned it into a scoreboard, and that fundamentally misses the point.

So what's actually going on when a vendor has a high CVE count? More often than not, it means they have strong internal testing, active engagement with security researchers, and the willingness to publicly acknowledge issues when they find them. That's maturity, not weakness. Meanwhile, low numbers can just as easily reflect limited scrutiny, narrower product exposure, or quieter disclosure practices. A vendor who never discloses anything isn't more secure. They're just less honest about it.

Here's the thing people forget: every single CVE was a zero-day before it got assigned a number. The vulnerability existed whether anyone published it or not. Better to have a CVE than not, because as a consumer, the only thing that changes for your organisation after a CVE is published is that there is now a defined compensating control available. Before that? You were exposed and didn't even know it.

But wait, there's more. If we keep being reductive about this, associating good security with "low CVE counts," we're going to push vendors in exactly the wrong direction. They'll focus on minimising visibility instead of maximising transparency. Vendors will start optimising for optics instead of actual risk reduction. Non-disclosure doesn't reduce your attack surface. It increases it without you even knowing. That should be a no-brainer for anyone serious about applying security best practices.

So what can we do about this? Stop fixating on the number and start asking better questions. How transparent is the vendor? Do they provide a software bill of materials? What does their responsible disclosure process look like? Why does the vulnerability exist in the first place? Is there a recurring theme in CVEs for a given vendor or product that indicates deeper QA problems? What controls does your own organisation have in place to limit and observe the attack surface? How are those controls validated and improved? What gaps remain? How does your organisation track and prioritise risk, and what types of risk are actually being tracked?

Every vendor has vulnerabilities. Every single one. What truly matters isn't how many exist, but how exploitable they are, how quickly they're remediated, and how well proper architectures limit their impact. Security is a practice and a journey, not a number on a spreadsheet. CVEs foster collaboration and visibility. Stop pushing the narrative towards obscurity and paranoia.