Counting vulnerabilities tells you almost nothing about risk
It is a natural instinct. You are choosing between two products, or deciding which of your systems to worry about, and you look up how many security flaws each has had. More flaws, more risk. It is intuitive, it is easy to measure, and on the evidence it is close to useless.
Two examples from our analysis of 248,176 public vulnerability records make the point better than any argument.
The Linux kernel has 8,053 recorded vulnerabilities, more than any other single product in the data. Under 1% of them show any evidence of being exploited in a real attack.
FortiOS, the operating system on Fortinet's firewalls, has 113. Nearly one in five has been exploited.
One product has 70 times the flaws and a fraction of the attacks. If you had chosen what to worry about by counting, you would have spent the year working through kernel advisories while the thing on the edge of your network was the one being broken into.
Why the count is misleading
Three things drive it, and none of them are about how well-built the software is.
Scrutiny inflates the count. The Linux kernel is one of the most examined codebases on earth, with automated tooling constantly finding and reporting issues. Software nobody looks at has few recorded vulnerabilities, and that silence is not safety.
Most kernel flaws need access you already have. A large share require local access or existing privileges. They matter for escalation once an attacker is inside, and they are close to irrelevant as a way in. Edge appliance flaws tend to be the opposite: reachable from the internet, often needing no credentials.
Packaging multiplies the same flaw. In our data the ten most-affected products are almost all the same kernel vulnerabilities recorded again under each distribution's packaging. Nine of the top ten entries were variants of one codebase. Adding them together would count the same flaws nine times over.
That last point is worth dwelling on, because it means product-level counts are not just a poor risk signal, they are frequently not even accurate counts. We deliberately do not publish a "most vulnerable software" table from this data, because we could not construct one we would stand behind.
What does carry signal
The pattern that survives is about position, not volume. Software sitting at the network edge, reachable from the internet, and doing authentication carries exploitation rates one to two orders of magnitude above the baseline across the whole record.
The products with the highest exploitation rates in our data cluster into two groups: internet-facing network appliances such as firewalls and VPN gateways, and the software that sits on ordinary desktops, meaning Windows and Office and browsers. Both are places an attacker can reach without already being inside.
That is the useful reframing. The question is not how many flaws has this had. It is what can reach this, and what does it protect.
What to do with this
- Inventory by exposure, not by flaw count. List what is reachable from the internet: firewall, VPN, remote access, anything with a login page facing outward. That list is short and it is where the risk concentrates.
- Patch edge devices on a different clock. A firewall or VPN vulnerability deserves a faster response than a server patch, because it is the way in rather than a step once inside.
- Do not choose software by CVE count. A product with no recorded vulnerabilities may simply be one nobody has examined. Low counts and low scrutiny look identical from outside.
- Ask who patches your edge kit. In a lot of small businesses, the firewall was installed once by somebody who has since moved on. Nobody owns updating it, and that is exactly the class of device being exploited.
How Steelwise can help
Working out what is actually exposed at the edge of your network, and whether anyone is keeping it updated, is one of the first things a security review looks at. Get in touch.
About the data. Figures come from our analysis of 248,176 public vulnerability records sourced via StackFlag, which is a Steelwise product. The underlying data is public: the National Vulnerability Database, CISA's Known Exploited Vulnerabilities catalogue, and GitHub Security Advisories. Exploitation rates are measured against CISA's catalogue of confirmed exploitation, and product-level figures carry the matching caveats described above, so treat the comparison as directional.
If you spot an error in this filing, tell us and we will correct it and note the change.