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 400,837 public vulnerabilities make the point better than any argument.
The Linux kernel has 15,006 recorded vulnerabilities, among the most of any product in the data. 33 of them, about 0.2%, show any evidence of being exploited in a real attack.
FortiOS, the operating system on Fortinet's firewalls, has 284. 24 of them, about one in twelve, have been exploited.
One product has more than 50 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 all the same kernel vulnerabilities, recorded again under one distribution's separate kernel packages. Adding them together would count the same flaws ten 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. That baseline is about 0.3%.
The products with the highest exploitation rates in our data cluster into a few groups: desktop versions of Windows, internet-facing appliances such as VPN gateways, and enterprise server platforms. The first two 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 400,837 distinct public vulnerabilities sourced via StackFlag, which is a Steelwise product, queried on 4 October 2026. 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. Product rates are sensitive to how much of the record is held: every rate in this filing fell when the missing data was restored.
If you spot an error in this filing, tell us and we will correct it and note the change.
Further reading
Correction
4 October 2026, 16:06 BST. This filing was first published on 3 August 2026 using a dataset that turned out to be incomplete. A fault in StackFlag had silently failed to store about 180,000 records from the National Vulnerability Database. We re-ran the analysis on the complete data.
The original said the Linux kernel had 8,053 recorded vulnerabilities, "more than any other single product in the data", that FortiOS had 113 of which "nearly one in five" had been exploited, and that the kernel had "70 times the flaws". On complete data the kernel has 15,006 and is no longer the single largest entry, FortiOS has 284 of which 24 (about one in twelve) have been exploited, and the ratio is a little over 50 to one. We also said nine of the ten most-affected products were kernel packaging variants. It is now all ten.
The conclusion holds: FortiOS flaws are exploited at roughly 38 times the rate of kernel flaws, and flaw counts remain a poor guide to risk. The size of the FortiOS figure we first published was more than double what the full record supports.
← All filings