Hidden Assets, Hidden Risk: The Visibility Gap Attackers Use

Working as a Sales Engineer in cybersecurity means I spend a lot of time looking at customer environments.

Different industries, different infrastructure, different security stacks. But there is one question I like asking during technical discussions because the answer often reveals more than expected:

“How many assets do you actually have?”

It sounds like a simple question.

Sometimes I get an immediate answer: 5,000 endpoints. 800 servers. 12,000 devices.

Then we start looking a little deeper.

The CMDB says one number. The endpoint management platform says another. The vulnerability scanner has a different number again. Active Directory contains machines nobody immediately recognizes. And once cloud workloads, remote devices, network infrastructure, test systems, and older servers enter the conversation, that original number suddenly becomes much less certain.

That is where asset visibility stops being an inventory discussion and starts becoming a security discussion.

Because a system being unknown to the security team does not make it unknown to an attacker.

You Can Only Secure What You Know Exists

A lot of vulnerability management conversations naturally begin with vulnerabilities.

How many Criticals do we have? What is our CVSS exposure? Which CVEs are exploitable? How quickly are we patching?

All important questions.

But during technical evaluations, I often find myself going one step backwards and asking:

What exactly are we scanning?

A vulnerability scanner can do an excellent job assessing the assets it knows about. A patching platform can achieve impressive compliance across the endpoints it manages.

But neither percentage tells the whole story if part of the environment is missing from the scope.

Imagine a company reports 98% patch compliance across 5,000 managed endpoints.

That sounds excellent.

But what if another 200 systems are sitting somewhere on the network without an agent, outside the inventory and therefore outside that calculation?

Suddenly the more important question is not whether the 98% figure is accurate.

It is whether the 5,000-device scope is accurate.

That distinction matters.

The Interesting Part Usually Starts When the Numbers Do Not Match

One of the useful things about running a PoC is that you are not only demonstrating features. You are testing assumptions about the customer's environment.

And asset discovery can challenge those assumptions very quickly.

You might discover a server nobody realized was still running. A machine that stopped reporting to the existing management platform. A network device that cannot support an endpoint agent. Or software that nobody expected to find on a particular system.

From an SE perspective, those moments are particularly valuable because we have moved from discussing a theoretical security problem to looking at something that actually exists in the customer's environment.

The conversation changes from:

“Can your platform discover assets?”

to:

“What is that device, who owns it, and why didn't we know about it?”

That is a much more useful conversation.

One Discovery Method Is Rarely Enough

Another thing I have learned from customer environments is that there is rarely one perfect source of truth.

Agents provide rich endpoint information, but not every asset can necessarily have an agent installed.

A CMDB is useful, but it depends on information being maintained correctly.

Active Directory provides another view, but it does not represent everything connected to the environment.

Cloud environments add another layer of complexity because workloads can be created and removed constantly.

This is why, when demonstrating Saner CVEM, I tend to look at asset visibility as a combination of approaches rather than a single discovery mechanism.

For managed endpoints, the Saner agent can provide detailed information about the system, installed software, vulnerabilities, configuration posture, and patch status.

For other parts of the infrastructure, network-based discovery and assessment can help identify reachable systems where installing an agent may not be practical.

But simply discovering another IP address is not particularly interesting by itself.

The useful part is what happens next.

What is this asset? What is running on it? Is it vulnerable? Is it compliant? How risky is it? And can we do something about it?

That is where asset discovery becomes part of exposure management rather than simply another inventory exercise.

Discovery Is Only the Beginning

Let's say we discover an unmanaged server during an assessment.

Finding it is useful.

But as an SE, I would immediately want to know more.

What operating system is it running? What software is installed? Does it contain known vulnerabilities? Are any of those vulnerabilities actively exploitable? Is the system exposed? Does it meet the organization's security baseline? Is remediation available?

Because the fact that an asset exists does not automatically tell us how worried we should be about it.

This is where I think the relationship between asset visibility and risk prioritization becomes important.

Saner CVEM connects asset visibility with vulnerability management, posture assessment, compliance, risk prioritization, patch management, and endpoint management.

So rather than stopping at:

“We found another asset.”

the conversation can continue into:

“We found another asset, this is the exposure associated with it, and this is what we can do about it.”

For me, that is a much more meaningful security outcome.

The Handoffs Are Often Where Things Slow Down

Another pattern I regularly see is that customers already have good security tools.

The challenge is not necessarily that any individual product is failing.

The challenge is what happens between them.

One platform discovers the asset. Another identifies the vulnerability. Someone exports the finding or creates a ticket. Another team evaluates it. A different tool handles patching. Then somebody needs to confirm whether remediation actually worked.

Each individual step makes sense.

Collectively, however, those handoffs create time and operational overhead.

And during that time, the vulnerable condition may still exist.

This is one of the areas I focus on when demonstrating Saner CVEM: connecting discovery, detection, prioritization, remediation, and validation as part of the same exposure management workflow.

If a vulnerability is identified and remediation is available, the objective should not simply be to produce another finding or ticket.

The objective should be to remove the vulnerable condition and verify that it is gone.

That last part is important.

A deployment saying “successful” and a vulnerability saying “no longer present” are not necessarily the same thing.

From a security perspective, I care much more about the second.

Attackers Do Not Care About Your Inventory

Ultimately, attackers are not working from your CMDB.

They do not care whether a server has an assigned owner, whether an endpoint is enrolled in the correct management platform, or whether a device appears on the vulnerability dashboard.

If it is reachable, exposed, misconfigured, outdated, or vulnerable, it can become part of the attack surface.

That is why one of the questions I increasingly think security teams should ask before discussing remediation speed is:

“Are we confident we know what we are responsible for securing?”

Because you can have excellent vulnerability SLAs, strong patch compliance, and impressive dashboard metrics across everything you are monitoring.

But if part of the environment is missing from that picture, there is still a gap.

And in my experience as a Sales Engineer, sometimes the most valuable thing you can discover during a security assessment is not another vulnerability.

It is an asset nobody knew needed to be assessed in the first place.