Risk

Exposure management past the slide deck

Continuous threat exposure management is the phrase of the year and most implementations of it are a scanner on a schedule. What separates the version that changes decisions from the version that produces a longer list.

Continuous threat exposure management, which everybody now shortens to CTEM, was introduced by Gartner as a way of describing something security teams had been reaching for without a name. A large share of what gets sold under the label is a vulnerability scanner running more often, with a dashboard.

The framing is genuinely useful. The gap between the framing and most implementations is where the value is, and it comes down to one step that is almost always skipped.

What it is meant to replace

Vulnerability management finds flaws. Exposure management proves which ones work here.
Vulnerability management finds flaws. Exposure management proves which ones work here.

Traditional vulnerability management runs on a rhythm. Scan, produce a list, sort by severity, send it to the people who own the systems, watch a proportion get fixed, scan again.

Three things break it.

The list is always longer than the capacity to work it, so prioritisation decides everything and severity is a poor way to prioritise. We argued that case in stop patching by severity, and the short version is that a flaw being genuinely exploited matters far more than a flaw being theoretically severe.

The scan covers what you told it about. Cloud environments change daily and the asset that hurts you is usually the one that was not in scope.

And a vulnerability is not an exposure. A critical flaw on a system with no route to it, behind controls that would stop the technique anyway, is not the same risk as a medium severity flaw on something internet facing with a known exploit. The scanner cannot tell them apart. It does not know your environment.

A vulnerability is a property of software. An exposure is a property of your organisation. Only one of them can be scanned for.

The five stages, and the one everybody skips

Scoping, discovery, prioritisation, validation and mobilisation. Validation gets skipped.
Scoping, discovery, prioritisation, validation and mobilisation. Validation gets skipped.

The model has five stages. Scoping, discovery, prioritisation, validation and mobilisation.

Most programmes do discovery well, because tooling handles it. Most do prioritisation adequately. Almost nobody does validation, and validation is the stage that makes the whole thing work.

Scoping starts from the business rather than the network. Which systems, if compromised, would actually matter. Not every asset. The ones where the consequence is real.

Discovery finds what is in that scope, including what you did not know. Externally facing assets, forgotten subdomains, staging environments reachable from the internet, SaaS platforms procured by a department. Identity belongs here too, and it is frequently left out, which matters because standing privilege is an exposure even where no software flaw exists.

Prioritisation orders by what can actually hurt you. Exploitation in the wild, reachability, and what the affected asset touches. The CISA Known Exploited Vulnerabilities catalogue and EPSS are both free and both change the ordering substantially.

Validation asks the question nobody wants asked. If somebody tried this, would it work here, and would we see it. This is the stage that converts a theoretical list into a short list of things that are genuinely exploitable in your environment. It is also the stage that requires effort rather than a licence, which is why it gets dropped.

Mobilisation is getting it fixed, which is an organisational problem rather than a security one. If the output of your programme is a ticket that sits in somebody else's backlog for a quarter, the preceding four stages were a research exercise.

Validation is the whole argument

Without validation, exposure management is vulnerability management with better branding and a bigger list.

With it, the conversation changes completely. You stop saying there are four thousand findings and start saying there are eleven paths an attacker could actually take today, here is the first one, and here is what we saw when we tried it.

That second statement gets acted on. It gets budget. It survives contact with an engineering team who have heard the first version too many times.

Validation also tells you something a scanner never will, which is whether your detection would have caught it. Running a technique and finding that nothing fired is one of the most useful results available, and it costs nothing beyond the time to look.

Where the model is weak

Two honest limitations.

It is organisation shaped. Exposure management assesses what you own, and modern failures travel through providers you do not. Your own exposure can be minimal while your concentration risk is severe, and no CTEM programme surfaces that because it sits outside scope by definition. That is the argument in infrastructure fails in chains, and it remains the harder problem.

And it can become continuous in the wrong sense. Always on discovery against an environment that changes daily produces a stream nobody can absorb, which is how you arrive back at the alert queue nobody works by a different route. Continuous should describe the coverage, not the interruption.

Where we stand

We think the sequence matters more than the tooling, and that most organisations would get more from doing two stages properly than five badly.

If you are starting, start with scoping and validation, and be prepared to do them with a smaller scope than feels comfortable. Twenty systems validated properly will tell you more about your actual risk than four thousand findings sorted by severity, and you can act on the result this month.

Our VAPT and red team practice does the validation stage, which is the part that cannot be bought as a subscription, and our threat intelligence practice supplies the exploitation context that drives prioritisation. Threat Intelligence Mapper is built for exactly that join, ending its output at the check worth running rather than at another advisory.

For mobilisation, which is where most programmes actually die, CyberNexus carries the finding through to a closure somebody named accepted against evidence, and ControlGraph answers what a given weakness reaches so the fix gets the priority it deserves rather than the priority its severity score suggests.

Start here

Take your ten most important internet facing systems. For each one, answer two questions.

Is there anything on it currently listed as known exploited. If somebody exploited it today, would anybody notice.

That is a validation exercise on a scope small enough to finish this week, and it produces the kind of finding that changes a budget conversation.

Common questions

What is continuous threat exposure management

A programme model, introduced by Gartner, covering scoping, discovery, prioritisation, validation and mobilisation. It aims to replace periodic vulnerability scanning with an ongoing view of what could genuinely be exploited and what that would cost the business.

How is CTEM different from vulnerability management

Vulnerability management finds software flaws and sorts them by severity. Exposure management asks whether a flaw is reachable and exploitable in your specific environment, validates that assumption, and drives remediation. The validation stage is the main difference.

What is the validation stage in CTEM

Testing whether a prioritised exposure can actually be exploited in your environment and whether your controls would detect it. It converts a long theoretical list into a short list of demonstrated paths, and it is the stage most programmes skip.

Do we need a CTEM platform

No. The model is a sequence of activities, not a product category. Most organisations can run meaningful scoping, prioritisation and validation with tools they already have plus free sources such as the CISA KEV catalogue and EPSS.

What are the limitations of CTEM

It assesses what your organisation owns, so concentration risk in shared providers stays invisible to it. Run without discipline it also generates a continuous stream of findings nobody can absorb, which recreates the alert fatigue problem in a new place.

CTEMRisk ManagementVulnerability ManagementExposure

Working on something this touches?

If this raises a question about your own compliance position or your security operations, the quickest route is a direct conversation.