Part 1 of a three-part series based on Ruchit's Tenable ExposureCon session, "Operationalising CTEM," on what it really takes to operationalise exposure management and reduce measurable cyber risk.
At this year's Tenable ExposureCon, I spoke about a pattern I keep running into: security teams working harder than ever, with better scanning tools than ever, and still falling behind the remediation work.
The honest answer isn't what most people expect, and it has nothing to do with your scanners missing information or your remediation team not pulling their weight. More visibility was never going to fix this on its own.
Why does vulnerability management feel like it's failing?
Most organisations have significantly more visibility than they did even a few years ago. That's no longer the primary constraint. The harder problem is deciding which exposures deserve immediate action, and having the operational capacity to act on that decision once it's made.
One of the first things I look for in a new engagement isn't how many critical vulnerabilities an organisation has. It's whether different teams would prioritise the same ten findings if you handed them the same list. Often, they wouldn't.
I see the same pattern walking into most engagements: alert fatigue, findings with no business context attached, a handful of disconnected tools each reporting its own version of "critical," and a picture of risk that's already out of date by the time anyone gets to act on it. These four show up in almost every engagement, in some order, and I'd bet most security leaders reading this will recognise at least two or three of them in their own environment.
None of it is because people aren't trying hard enough. Most security programs are built to find problems, not to rank them.
Figure 1: Traditional vulnerability management asks "which vulnerabilities should I patch?" CTEM asks "which exposures could compromise critical assets?
More vulnerabilities don’t equal more risk. But when every finding on the list looks equally urgent, that's how they end up being treated, and that's how patch management teams end up with a six-month backlog and no real sense of which five findings out of five thousand would stop an attacker.
That's why many boards still struggle to answer a simple question: are we becoming harder to attack? A shrinking backlog doesn't answer it. Neither does a rising patch rate. Those are activity metrics, not risk metrics, and executives are increasingly aware of the difference.
What's the difference between a vulnerability and an exposure?
I explain it to clients this way:
A vulnerability is a fact about a system. An exposure is that same fact plus everything that determines whether it matters.
A vulnerability exists. An exposure is that fact combined with what the asset connects to, who or what can reach it, what it protects, and what happens if it's compromised.
A critical CVE sitting on an internet-facing system holding customer data isn't the same risk as the identical CVE on an isolated internal test box. Technically it's the same vulnerability. Operationally, it isn't remotely the same problem, and treating them the same is exactly how teams end up drowning in volume while the exposures that matter sit buried somewhere in the middle of an undifferentiated list.
One security leader I worked with had closed thousands of tickets in a single quarter and still couldn't tell the board with any confidence whether the organisation was safer. Ticket volume had quietly become the metric that mattered, simply because it was the easiest thing to count.
Getting this right rarely means buying another tool. Most organisations already have the context that matters. It's just scattered across systems that don't talk to each other:
-
-
Business criticality: what does this asset support?
-
Attack paths: could this be chained into something that reaches a critical system?
-
Identity and access: who or what can reach it, and what would that allow?
-
Cloud posture: does configuration expose this, not just by code?
-
External attack surface: is it even reachable from outside the perimeter?
-
Once you can see a finding through that lens, prioritisation stops being a guess.
What is CTEM (Continuous Threat Exposure Management)?
CTEM is a structured, continuous approach to identifying, prioritising, validating and reducing the exposures that genuinely matter to a business, rather than chasing an ever-growing list of everything that could theoretically go wrong. Gartner introduced the term because vulnerability counts had stopped answering the question executives care about.
Most security leaders don't need convincing that risk is growing. What they need is a credible way to show it's being reduced, not just documented. Boards are asking harder questions than "how many vulnerabilities do we have." They want to know whether the organisation's real exposure to an attack is increasing or decreasing, what that means for operational resilience, and what's being done about it.
A vulnerability count doesn't answer that question; it was simply good enough for long enough that nobody pushed back on it.
Technology provides the visibility, but what turns that into measurable risk reduction is the program built around it, the part that translates visibility into the kind of business risk conversation that protects the services your organisation depends on.
So what does that look like day to day, inside a real organisation? That's the operating model we build at The Missing Link, and it's what Part 2 gets into.
Continue to Part 2: Why exposure management programs stall, and how to operationalise them
Want to see where your own exposures would hold up? Book a Threat Validation Workshop
