Counting CVEs tells you nothing about security
You regularly see comparisons that rank systems by the number of published CVEs, the lowest count winning the title of most secure. I tend to strongly temper that kind of result, because the number itself does not measure what people think it measures. A CVE counter counts flaws that were made public and nothing else. It says nothing about the ones that exist, that are known internally, or that quietly circulate far from any advisory.
Two worlds, two disclosure policies
In proprietary software, most vulnerabilities are not necessarily disclosed officially or publicly, everything depending on the policies the vendor applies. As for shipping a patch, it obeys a host of parameters: acknowledging the flaw, actually fixing it, commercial agreements struck with customers or governments, not to mention the existence of a black market for 0days.
In free software, the relationship is reversed. There, most vulnerabilities are known and published openly, together with their fixes, which in no way prevents 0day exploits from existing on the market anyway. The difference, then, is not in the quantity of flaws, but in how much of them you agree to show.
The thought experiment
Take two systems and deliberately fictional figures, just to frame the reasoning.
The first reports 3000 vulnerabilities patched over the year out of 4000 known to the community, with a dozen exploits circulating on the market. Everything is on the table, the holes as much as the plugs.
The second reports 2500 vulnerabilities patched out of 4000 known to the vendor, except that 1500 of them, critical once chained together, were simply omitted. And more than a hundred exploits would be on sale for that system, half of them targeting flaws the vendor itself is unaware of.
Which of the two would you rather administer ? The first has the higher CVE count and yet it is plainly the healthier of the two.
The counter rewards opacity
Here is the central bias. A low CVE count can just as easily reflect an exemplary disclosure discipline as an organized silence. Stare at the number too long and you end up rewarding the most opaque vendor, the one who fixes on the sly and publishes only what it can no longer hide.
Security through obscurity is not security, at best it buys a little time, at worst it costs a great deal and above all it distorts the trust relationship you can maintain with a supplier. It is quite likely, moreover, that some proprietary flaws linger for years without ever surfacing in a single advisory, not for lack of risk, but for lack of any will to show them.
Your CVE tally lies
- A CVE counter measures disclosure transparency, not the real level of security.
- A high count of published and fixed CVEs is often healthier than a low count from an opaque vendor.
- In proprietary software, most flaws are neither disclosed nor public and a 0day market runs in parallel.
- Security through obscurity distorts the trust relationship and never stands in for security.
- To compare two systems, look at their disclosure and patching policies, not the raw score.
On the tooling side, the same reasoning applies when you scan an image or a fleet: see Trivy and the supply chain for inventorying known vulnerabilities and debsecan for matching a Debian system against what the community has actually published.
[edit: 2026] The Ansible implementation of all this: the unattended-upgrades role .