Most of us can tell you our open vulnerability count off the top of our heads. It is large, it grows every week, and somewhere along the way, it became the scoreboard. Fewer is good. More is bad. The job became driving the number down.
That is worth questioning, including the version of it most of us hold. We built the count into the scoreboard because, for years, finding flaws was genuinely the hard part. Not enough eyes, not enough time, not enough skill. So a long list felt like progress, because finding things was difficult and we were doing it. That instinct made sense. It may not anymore.
The reason is simple, and you have probably felt it already. Finding vulnerabilities is no longer the constraint. AI tooling now surfaces flaws faster than any team can fix them. Across roughly 50 organizations using the same AI system, over 10,000 critical and high-severity vulnerabilities surfaced in about a month. Cloudflare found 2,000 bugs in its own critical-path systems in a matter of weeks, 400 of them high or critical severity. Mozilla shipped a Firefox release fixing 271 vulnerabilities — more than ten times what a typical release addresses. Maintainers have started asking researchers to slow down, because they cannot keep up.
So the count will keep climbing no matter what we do. Which raises an honest question: if the number we have been managing goes up regardless, what were we actually measuring? Here is where the thinking has landed, including the parts that are harder than they sound.
1. A bigger list was never the thing we cared about
Vulnerability count vs. risk
We adopted the count because it was easy to produce and it correlated, loosely, with effort. But it was always a proxy. What we actually care about is whether someone can hurt the business, and a raw list of findings does not tell you that.
This was easier to ignore when the list grew slowly. Now that it grows faster than anyone can work it down, the gap between “number of findings” and “amount of risk” is impossible to miss. The count is not wrong, exactly. It is just answering a question we stopped needing answered.
2. The severity score describes the flaw, not your situation
Why CVSS scores don’t equal risk
A severity score is calculated once, in the abstract, from the properties of the vulnerability itself. It does not know your network. It cannot know whether the affected system is exposed, what it connects to, or whether an attacker could reach anything that matters from it.
A flaw turned up this year in wolfSSL, a small encryption library that sits inside an enormous number of devices. It scored about as high as a flaw can score. For one company it lands on an isolated system with nothing valuable nearby, and it is close to a non-event. For another it lands on an internet-facing system the network trusts, and the same flaw opens a route toward the payment system.
Same vulnerability, same score, two completely different situations. The score cannot separate them, because what separates them is not the flaw. It is whether a path exists to something worth protecting. None of this means the score is useless. It means it is a first filter, not a verdict.
3. The number worth watching is harder to produce, which is exactly why we avoid it
Attack paths, not findings
Threat debt is the accumulation of attack paths an adversary could actually walk to reach something the business cares about — not the whole pile of findings, but the subset that chains into a real route, in your environment, given your controls. If the vulnerability count is the wrong measure, this is the better one.
It is a useful frame, with one caveat worth getting to. It behaves like debt in ways worth sitting with. It accrues continuously, because configurations drift and the business changes even in weeks when nothing new is disclosed. You do not pay it down by closing findings faster, but by breaking the specific paths that matter. And it is not a security-team to-do list, because a real path usually crosses identity, network, endpoint, and the application at once.
Here is the honest caveat. Threat debt is harder to measure than a vulnerability count. A count is trivial to produce; a validated path is work. That difficulty is the whole reason teams default to counting. The better measure is not the easier one. The point is that the easy number stopped being worth much, so the harder one is worth the effort.
4. The uncomfortable question is about your controls, not the attacker
Having a control vs. a validated control
When we picture a breach we picture missing defenses. But in the kind of scenario above, the controls were usually all there. Endpoint detection. Log collection. A firewall in front of the crown jewels. The failure was not absence.
The failure was that no one had confirmed that those controls actually prevent an attacker from taking that specific path. Having a control and having a validated control are different things, and most of us have more of the first than the second. The question is not “do we have controls.” It is “Have we checked that they work where it counts?” That is uncomfortable precisely because the answer, honestly, is often “we are not sure.”
5. Whatever you call it, the work has to be continuous
Running CTEM as a loop, not an event
The window between a flaw existing and someone weaponizing it used to give us weeks. It now gives us hours; the same tooling that finds flaws at scale also builds working exploits quickly. Annual pen tests and quarterly reviews were not designed for that pace.
So the work has to run as a loop rather than an event. Know what you actually run. Find the flaws and the assets you overlook. Validate whether an exploit works and whether your controls stop it. Act on what is genuinely reachable. Then start over, because the picture changed while you were working. The industry’s name for running that loop is Continuous Threat Exposure Management (CTEM), but the label matters less than the habit. You could do most of this without ever using the acronym.
Where this leaves us
None of this is a revolution, and we would distrust anyone who sold it as one. It is a correction. For a long time the hard part was finding flaws, so we measured finding. That part got easy, so the measure stopped meaning much, and we have to move our attention to the part that is still hard: knowing which flaws can actually reach something, and proving our defenses hold there.
The vulnerability count will keep going up. That is fine. It was never the number that mattered. The one that does is how much real opportunity we are leaving open, and whether we are closing it faster than it accrues.
That is what we get into in our session on rethinking vulnerability scoring (you can register here), with real examples and a working demo. If any of this rings true to your own experience, we would genuinely like to hear your take, and we would love for you to join.
