Three questions, sold as one

A security team can end up holding three quotes that read almost identically. Each one says continuous. Each one says exposure. Each one shows a dashboard with a count going down. Bought together, they overlap in places and leave gaps in others, and the gaps surface when an auditor asks a specific question rather than during the evaluation. Telling the three apart is less a technical exercise than a procurement one, and it has to happen before the shortlist is drawn.

Three buying questions under one vocabulary

Attack surface management, vulnerability management and security control validation are sold with the same nouns, and three buying questions sit under them. What can the internet reach right now, with nobody inside granting access to anything. Which finding already in a console gets worked on this week, and who closes it. Whether the control bought to close it is running on the machine it was licensed for.

None of the three is a stage of the other two, and ranking them as maturity levels is where a budget goes wrong. Where a tool stands decides which question it can answer. Outside the estate with no credentials, it sees what a stranger sees, not whether an internal server was patched. Collecting from the endpoints, it sees whether the agent is running, not the subdomain nobody wrote down. Above the scanners, it sees every scanner's output at once, produces no finding of its own, and knows as much as it is fed.

What the internet can already reach

The answer is outside, so that is where the looking happens. Reconnaissance starts from a domain name, not from an inventory. Which hostnames resolve, and which point at a cloud instance created for a campaign that ended in March. Whether the DMARC record was started and never finished, so the mail domain can be spoofed by anyone who reads it. The asset that causes the incident is the one nobody entered in the inventory, and a tool working outward from that list cannot look for it.

The gap widens on its own. Code and infrastructure are generated faster than change processes record what was deployed, so what an organisation owns runs ahead of what it has written down. That is a discovery problem, not a ranking one.

One public authority has written the cadence down in days. CISA's Binding Operational Directive 23-01 tells US federal civilian agencies to perform automated asset discovery every 7 days and to initiate vulnerability enumeration across discovered assets every 14 days. It binds those agencies and nobody in this region. CISA calls asset discovery non-intrusive, usually needing no special logical access privileges, while vulnerability enumeration detects host attributes and identifies missing updates. Two activities, two access requirements, and a product doing one is not quietly doing the other.

Which finding gets worked on first

This one begins after the findings exist. It is an ordering problem, not a detection one. A network scanner, a web application scanner and a cloud posture tool each write their own severity field. The same weakness appears three times under three names with three severities, and whichever console the team opens in the morning becomes the working order. Nobody decided that order. It came from a field in an export.

Severity is also a weak stand-in for urgency, and the body publishing exploitation data says so. FIRST, which maintains the Exploit Prediction Scoring System, states in its EPSS documentation that CVSS and EPSS measure different things and are empirically uncorrelated, and that high severity scores are slightly better than random at predicting exploitation activity. The same page puts the base rate at roughly 0.5 percent of published CVEs in the CISA Known Exploited Vulnerabilities catalogue, with exploitation activity observed on roughly 2.5 to 3 percent in any 30 day window.

AI changed an input here rather than the vocabulary. A severity score says how bad a flaw would be if somebody exploited it, and nothing about the effort of building that exploit, which is work code generation tools now assist. An exploit likelihood signal therefore belongs next to severity rather than inside it, and FIRST defines EPSS as the probability that a published CVE will be exploited in the next 30 days. Likelihood is still only half an order, because asset criticality says what happens if the attempt succeeds, and a queue needs both.

Whether the control is actually running

This is the question an auditor asks and a purchase order cannot answer. An organisation buys an endpoint agent for every machine and holds a licence count as proof. The licence count and the installed count are different numbers, drifting apart one administrative act at a time.

• A machine joined the estate after the rollout list was frozen, so no agent was pushed to it.
• An exception was written for a migration and stayed after the migration finished.
• An agent has not reported in since a reboot, so the console lists it and the machine does not run it.
• A detection was tuned down to stop an alert nobody read, and the tuning took more than the noise.

None of that requires carelessness. In October 2023 the NSA and CISA published a joint advisory on the top ten cybersecurity misconfigurations their red and blue teams found. The agencies wrote that these illustrate a trend of systemic weaknesses in many large organisations, including those with mature cyber postures. Those organisations bought the controls. Nobody instrumented them in the field.

A service provider meets this from the other side. An auditor does not ask whether the customer owns an endpoint product, but for evidence that it was installed, configured to a named policy and running on a named machine on a named date. That evidence comes from inside the estate, and neither an outside-in scan nor a merged queue holds it. Run several customers and the gap repeats once per tenant.

Where CTEM sits next to vulnerability management

CTEM is used as a synonym for vulnerability management and it is not one. Gartner defined continuous threat exposure management as a programme in five steps, set out in its own article. Scope the attack surface including the parts that are not devices, discover the assets and their risk profiles, prioritise what is likely to be exploited, validate that an attacker could use the path and that the response is fast enough, and mobilise people so findings become approved work.

Read against that list, the vulnerability management a team already runs covers discovery and part of prioritisation. It is a component of the programme, not a shorter name for it. Gartner also warns that scoping and discovery get confused, and that the volume of assets discovered is not success in itself.

CTEM names a programme, so no product completes it. A datasheet carrying the label tells you which category it competes in, not which of the five steps it performs, so ask which step, and who owns the other four. It is an analyst's model rather than an obligation anybody has to meet.

The products behind these three questions

We carry all three rather than picking one, because none of them answers another's question. S4E starts from a domain name, needs no agent and no access to anything inside, and reports what the public internet can already reach. Vultage reads the exported results of the scanners you already run, collapses duplicates and turns what is left into one ranked queue that can be assigned and closed, and it scans nothing itself. CyberCyte collects from the machines and from the security tools installed on them, and reports whether each control is installed, configured and running. Two of them carry a CTEM label from their vendor at different steps of the programme.