Y
Yuriy Butuzov
Guest
Two exposure-management tools can examine the same environment and return very different numbers. That does not necessarily mean that either is wrong.
In May 2024, XM Cyber and the Cyentia Institute estimated that a typical organisation had about 15,000 exposures. Fewer than one per cent were vulnerabilities with CVEs [1]. Roughly 80 per cent were associated with identity and credential misconfigurations [1].
These are slightly awkward figures for vulnerability management. The familiar machinery of scanners, patching programmes, SLAs and vulnerability backlogs appears to deal with only a small part of what is now being described as exposure.
There is an awkwardness for exposure management too. A single vulnerability scanner can readily generate tens of thousands of critical findings. Yet the supposedly broader category produces only 15,000 exposures.
The difficulty is mostly one of accounting. The figures are not counting the same thing.
A scanner may count conditions. Another product may count affected assets. A graph-based system may count attack paths. All can put the word exposures above the resulting number.
Until the unit is known, comparison is largely decorative.
For the purposes of this article, four terms need separating.
A condition is a security-relevant state: a CVE, a public bucket, an administrative account without MFA, an excessive IAM permission or an exposed service.
A finding is evidence reported by a tool that such a condition exists. It has a source, an age and, with luck, some measure of confidence. A public bucket discovered by CSPM, DSPM and a cloud audit remains one public bucket. That doesn’t make three buckets.
An exposure is a combination of an attacker's starting position, one or more existing conditions, a technique, and the target — an entity, data set or function — against which that technique can be applied. It exists when the target is reachable from that starting position and the technical prerequisites for the technique are satisfied.
Probability is deliberately absent from that definition. So are target value and the presence of an effective compensating control.
The last omission is important. Suppose a WAF rule completely blocks an exploit. The underlying conditions have not changed. Nor have the attacker origin, technique or target. Disable the WAF rule tomorrow and the same exposure becomes usable again.
The exposure has changed state, not identity.
A blocked exposure therefore remains in the ledger. It belongs in a different column.
Risk is a separate question. It concerns how difficult exploitation is, whether anyone is likely to attempt it and what the consequences would be.
The distinction is less academic than it sounds. An Internet-facing development server with a working exploit is still exposed even if it contains nothing of consequence. Its low value reduces the risk. It does not make the technical opportunity vanish.
Consider a short chain:
Internet → public workload → cloud role → secret → production database.
There is a public entry point, excessive permissions on the cloud role and an accessible credential.
A scanner might produce three findings. A platform combining several sources might produce five or seven because some of the same conditions were detected more than once. An asset-oriented product may count affected workloads and identities. A graph system may count the available attack paths.
Another platform may collapse the chain into one exposure: a toxic combination in which several factors together create a problem that none represents on its own [2].
It is therefore quite possible for the same environment to contain 40,000 findings, 8,000 affected assets, 600 attack paths and 900 exposures without any obvious arithmetic error.
The unit has changed.
A larger number does not necessarily indicate better discovery. It may simply indicate finer granularity.
Comparing findings with exposures is rather like comparing notes with melodies.
There is another source of disagreement even after two products have decided to count exposures rather than findings or assets.
They may not start the attacker in the same place.
Take BOLA. An authenticated user changes an object ID and obtains another tenant’s data.
Viewed from the unauthenticated Internet, there is no exposure yet; the attacker first needs an account. Viewed from the position of an ordinary authenticated user, the same endpoint and defect are sufficient.
“An attacker cannot reach it” is consequently an incomplete statement. The identity and position of the attacker matter.
Origin belongs in the model: Internet, authenticated user, compromised endpoint, contractor VPN, insider, compromised vendor tenant, or another explicitly defined starting point.
It also matters to deduplication. One CVE on one asset does not necessarily amount to one exposure. A different starting position may create a different opportunity and lead to a different action.
Such distinctions rarely receive much space on product-demo heatmaps. They matter rather more when two numbers are being compared.
I reviewed 47 primary sources from analyst firms, platform vendors, attack-path and validation specialists, ratings companies and independent analysts. There is broad agreement on the verbs. Exposures are to be discovered, assessed, prioritised, validated and remediated [3].
The noun is less settled.
Wiz draws the distinction between vulnerability and exposure through reachability. A weakness becomes an exposure when an attacker can actually get to it because of Internet accessibility, excessive permissions, missing compensating controls or similar circumstances. Its analogy is a useful one: a vulnerability is a door with a weak lock; exposure is the same door standing open to the street [4].
XM Cyber counts something rather different: a vulnerable resource combined with a credible threat technique along an attack path [5].
Gartner does not provide a strict standalone definition of the object on its Exposure Assessment Platforms page. It nevertheless refers to “exposures, such as vulnerabilities and misconfigurations”, allowing the underlying condition itself to sit inside the category [6].
The differences are not semantic niceties.
Under the Wiz formulation, exposure resembles a reachable weakness. Under XM Cyber’s, the unit contains both the resource and the attacker technique. Under Gartner’s wording, a vulnerability or misconfiguration may itself be an exposure.
There is no particular reason for those three models to produce the same number when presented with the same estate.
The usual question — which vendor found the correct number of exposures? — is therefore premature. One first needs to know what each vendor has elected to count.
The market has failed to agree on the object. It has had no such trouble with names.
CTEM, EAP, AEV, UVM, TEM, CEM, USEM, UEM, ROC, CREM and CRPM have all appeared [7].
They describe overlapping rather than identical propositions. Some begin with discovery, others with validation or remediation. Boundaries have shifted quickly.
Forrester in 2025 criticised the remediation capabilities of exposure-management products and treated UVM as a distinct field [8]. Within months, attack-surface management, exposure management and UVM were being brought together again under the broader label of proactive security platforms [9].
It may be the consolidation of a mature market. Or of an immature one. On this evidence, the difference hardly matters.
The unit of account remains unresolved either way.
There is some history here.
The first CVE list, published in September 1999, contained 321 entries. One of the problems it was intended to address was that security-tool vendors used their own measures of vulnerabilities and exposures. Buyers had no common basis for comparing the numbers [10].
CVE supplied a common identifier at the level of an individual vulnerability. Exposure has no obvious equivalent one level above.
It may not acquire one.
An exposure contains judgement in a way that a CVE identifier need not. Someone must decide what constitutes a single unit and when the technical prerequisites are sufficient to treat a technique as applicable. Part of the count is observed; part of it is modelled.
This makes the fate of Cisco Vulnerability Management an interesting footnote. Cisco announced its end-of-sale and end-of-life on 10 December 2025. The product, formerly Kenna, was among the better-known platforms built around CVE prioritisation. Cisco named no replacement [11].
The market grew out of counting CVEs. Twenty-seven years later it still lacks agreement on what, at the next level, should be counted instead.
Even a common unit would solve only part of the problem.
XM Cyber said in early 2026 that 74 per cent of identified exposures were dead ends: they did not lead to critical assets [12]. Its 2024 research put roughly 1.5 per cent of exposures on choke points traversed by a disproportionate share of attack paths [13].
A thousand exposures in one environment can therefore be quite unlike a thousand in another.
Removing a single condition from a point shared by hundreds of attack paths may matter more than repairing a hundred unrelated vulnerabilities.
There is nothing wrong with reporting that 5,000 CVEs have been closed. It is a measure of work done. It is not, by itself, a measure of how much attacker opportunity has been removed.
The two are easily confused because both produce numbers.
Absolute counts also conceal what was observed.
Suppose one company reports 900 active exposures and another 300. That doesn’t make the second company safer.
The first system may observe 95 per cent of the relevant declared infrastructure while the second observes 30 per cent.
The smaller number then becomes less impressive.
No finding does not mean no condition. It can also mean no data.
An exposure count therefore needs a denominator. At a minimum, a useful number should say what is being counted and how much of the declared scope is actually visible to the system.
A fall from 900 exposures to 500 could be the result of an effective remediation programme.
It could also mean that a connector failed yesterday.
The dashboard may look better in both cases.
Before comparing two exposure-management products, I would want five things made explicit.
Those answers tend to explain the difference between 40,000 exposures in one product and 900 in another more effectively than a discussion of whose algorithm is more sophisticated.
The useful question is a simpler one:
What do you count as one?
Until there is a common answer, two exposure dashboards can disagree without either being wrong.
They may simply be keeping different books.
Sources and references are provided in the appendix. Data current as of September 2026.
All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.
15,000 exposures, fewer than one per cent of them CVEs
In May 2024, XM Cyber and the Cyentia Institute estimated that a typical organisation had about 15,000 exposures. Fewer than one per cent were vulnerabilities with CVEs [1]. Roughly 80 per cent were associated with identity and credential misconfigurations [1].
These are slightly awkward figures for vulnerability management. The familiar machinery of scanners, patching programmes, SLAs and vulnerability backlogs appears to deal with only a small part of what is now being described as exposure.
There is an awkwardness for exposure management too. A single vulnerability scanner can readily generate tens of thousands of critical findings. Yet the supposedly broader category produces only 15,000 exposures.
The difficulty is mostly one of accounting. The figures are not counting the same thing.
A scanner may count conditions. Another product may count affected assets. A graph-based system may count attack paths. All can put the word exposures above the resulting number.
Until the unit is known, comparison is largely decorative.
The object being counted
For the purposes of this article, four terms need separating.
A condition is a security-relevant state: a CVE, a public bucket, an administrative account without MFA, an excessive IAM permission or an exposed service.
A finding is evidence reported by a tool that such a condition exists. It has a source, an age and, with luck, some measure of confidence. A public bucket discovered by CSPM, DSPM and a cloud audit remains one public bucket. That doesn’t make three buckets.
An exposure is a combination of an attacker's starting position, one or more existing conditions, a technique, and the target — an entity, data set or function — against which that technique can be applied. It exists when the target is reachable from that starting position and the technical prerequisites for the technique are satisfied.
Probability is deliberately absent from that definition. So are target value and the presence of an effective compensating control.
The last omission is important. Suppose a WAF rule completely blocks an exploit. The underlying conditions have not changed. Nor have the attacker origin, technique or target. Disable the WAF rule tomorrow and the same exposure becomes usable again.
The exposure has changed state, not identity.
A blocked exposure therefore remains in the ledger. It belongs in a different column.
Risk is a separate question. It concerns how difficult exploitation is, whether anyone is likely to attempt it and what the consequences would be.
The distinction is less academic than it sounds. An Internet-facing development server with a working exploit is still exposed even if it contains nothing of consequence. Its low value reduces the risk. It does not make the technical opportunity vanish.
Counting the same environment
Consider a short chain:
Internet → public workload → cloud role → secret → production database.
There is a public entry point, excessive permissions on the cloud role and an accessible credential.
A scanner might produce three findings. A platform combining several sources might produce five or seven because some of the same conditions were detected more than once. An asset-oriented product may count affected workloads and identities. A graph system may count the available attack paths.
Another platform may collapse the chain into one exposure: a toxic combination in which several factors together create a problem that none represents on its own [2].
It is therefore quite possible for the same environment to contain 40,000 findings, 8,000 affected assets, 600 attack paths and 900 exposures without any obvious arithmetic error.
The unit has changed.
A larger number does not necessarily indicate better discovery. It may simply indicate finer granularity.
Comparing findings with exposures is rather like comparing notes with melodies.
Reachable from where?
There is another source of disagreement even after two products have decided to count exposures rather than findings or assets.
They may not start the attacker in the same place.
Take BOLA. An authenticated user changes an object ID and obtains another tenant’s data.
Viewed from the unauthenticated Internet, there is no exposure yet; the attacker first needs an account. Viewed from the position of an ordinary authenticated user, the same endpoint and defect are sufficient.
“An attacker cannot reach it” is consequently an incomplete statement. The identity and position of the attacker matter.
Origin belongs in the model: Internet, authenticated user, compromised endpoint, contractor VPN, insider, compromised vendor tenant, or another explicitly defined starting point.
It also matters to deduplication. One CVE on one asset does not necessarily amount to one exposure. A different starting position may create a different opportunity and lead to a different action.
Such distinctions rarely receive much space on product-demo heatmaps. They matter rather more when two numbers are being compared.
A market with several definitions
I reviewed 47 primary sources from analyst firms, platform vendors, attack-path and validation specialists, ratings companies and independent analysts. There is broad agreement on the verbs. Exposures are to be discovered, assessed, prioritised, validated and remediated [3].
The noun is less settled.
Wiz draws the distinction between vulnerability and exposure through reachability. A weakness becomes an exposure when an attacker can actually get to it because of Internet accessibility, excessive permissions, missing compensating controls or similar circumstances. Its analogy is a useful one: a vulnerability is a door with a weak lock; exposure is the same door standing open to the street [4].
XM Cyber counts something rather different: a vulnerable resource combined with a credible threat technique along an attack path [5].
Gartner does not provide a strict standalone definition of the object on its Exposure Assessment Platforms page. It nevertheless refers to “exposures, such as vulnerabilities and misconfigurations”, allowing the underlying condition itself to sit inside the category [6].
The differences are not semantic niceties.
Under the Wiz formulation, exposure resembles a reachable weakness. Under XM Cyber’s, the unit contains both the resource and the attacker technique. Under Gartner’s wording, a vulnerability or misconfiguration may itself be an exposure.
There is no particular reason for those three models to produce the same number when presented with the same estate.
The usual question — which vendor found the correct number of exposures? — is therefore premature. One first needs to know what each vendor has elected to count.
The market has failed to agree on the object. It has had no such trouble with names.
CTEM, EAP, AEV, UVM, TEM, CEM, USEM, UEM, ROC, CREM and CRPM have all appeared [7].
They describe overlapping rather than identical propositions. Some begin with discovery, others with validation or remediation. Boundaries have shifted quickly.
Forrester in 2025 criticised the remediation capabilities of exposure-management products and treated UVM as a distinct field [8]. Within months, attack-surface management, exposure management and UVM were being brought together again under the broader label of proactive security platforms [9].
It may be the consolidation of a mature market. Or of an immature one. On this evidence, the difference hardly matters.
The unit of account remains unresolved either way.
A familiar problem
There is some history here.
The first CVE list, published in September 1999, contained 321 entries. One of the problems it was intended to address was that security-tool vendors used their own measures of vulnerabilities and exposures. Buyers had no common basis for comparing the numbers [10].
CVE supplied a common identifier at the level of an individual vulnerability. Exposure has no obvious equivalent one level above.
It may not acquire one.
An exposure contains judgement in a way that a CVE identifier need not. Someone must decide what constitutes a single unit and when the technical prerequisites are sufficient to treat a technique as applicable. Part of the count is observed; part of it is modelled.
This makes the fate of Cisco Vulnerability Management an interesting footnote. Cisco announced its end-of-sale and end-of-life on 10 December 2025. The product, formerly Kenna, was among the better-known platforms built around CVE prioritisation. Cisco named no replacement [11].
The market grew out of counting CVEs. Twenty-seven years later it still lacks agreement on what, at the next level, should be counted instead.
The count is not the risk
Even a common unit would solve only part of the problem.
XM Cyber said in early 2026 that 74 per cent of identified exposures were dead ends: they did not lead to critical assets [12]. Its 2024 research put roughly 1.5 per cent of exposures on choke points traversed by a disproportionate share of attack paths [13].
A thousand exposures in one environment can therefore be quite unlike a thousand in another.
Removing a single condition from a point shared by hundreds of attack paths may matter more than repairing a hundred unrelated vulnerabilities.
There is nothing wrong with reporting that 5,000 CVEs have been closed. It is a measure of work done. It is not, by itself, a measure of how much attacker opportunity has been removed.
The two are easily confused because both produce numbers.
The missing denominator
Absolute counts also conceal what was observed.
Suppose one company reports 900 active exposures and another 300. That doesn’t make the second company safer.
The first system may observe 95 per cent of the relevant declared infrastructure while the second observes 30 per cent.
The smaller number then becomes less impressive.
No finding does not mean no condition. It can also mean no data.
An exposure count therefore needs a denominator. At a minimum, a useful number should say what is being counted and how much of the declared scope is actually visible to the system.
A fall from 900 exposures to 500 could be the result of an effective remediation programme.
It could also mean that a connector failed yesterday.
The dashboard may look better in both cases.
Five questions
Before comparing two exposure-management products, I would want five things made explicit.
- The unit. What does one record represent: a condition, a finding, an affected asset, an attack path or a normalised exposure? If it is an exposure, how is it constructed?
- Identity. Which fields make two observations the same exposure? If three scanners report the same condition, is that one record or three? If an asset is reclassified as Tier 0, has the exposure changed or merely its risk?
- Origin. Where does the attacker start, and is that position stored in the model? Is an opportunity from the Internet the same exposure as one from a compromised endpoint?
- State. If a compensating control completely blocks the technique, does the exposure disappear, become blocked or remain active? The terminology is secondary. What matters is whether existence and state are treated separately.
- Coverage. How much of the declared scope is actually observed, and what happens to the count when a data source disappears?
Those answers tend to explain the difference between 40,000 exposures in one product and 900 in another more effectively than a discussion of whose algorithm is more sophisticated.
The useful question is a simpler one:
What do you count as one?
Until there is a common answer, two exposure dashboards can disagree without either being wrong.
They may simply be keeping different books.
Sources and references are provided in the appendix. Data current as of September 2026.
All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.