|
Getting your Trinity Audio player ready...
|
Most CISOs I’ve worked with understand intuitively that vulnerability scanners – like any tool in the security stack – have their limits. So, what happens when an organization decides to build a Continuous Threat Exposure Management (CTEM) program and assumes the scanner they already have in place can carry the load? On the surface, it’s a reasonable assumption – scanners are familiar, they produce reports, and they create a sense of forward motion.
Yet in my experience, security leaders who build CTEM programs on a scanner foundation tend to hit the same wall: the program stalls the moment it needs to go deeper than a CVE list. In this blog, I’ll explain where scanners genuinely contribute in CTEM, why context is the one thing they cannot provide, and what a solid CTEM foundation actually requires.
What a Vulnerability Scanner Does and Doesn’t Do
Vulnerability scanners are an important part of the security toolbox. By NIST’s definition, a scanner is a tool used to identify hosts and their associated vulnerabilities – CVEs, CWEs, and similar known flaws. They identify missing patches, flag known CVEs, and surface some configuration issues. For compliance reporting, they are a practical and widely accepted tool.
Some vendors have responded to the CTEM conversation by bolting prioritization and exposure scoring onto their existing vulnerability scanner platforms. Yet the underlying foundation remains a point-in-time CVE list. And a CVE list – however it’s dressed up – cannot provide insight into organizational risk.
The thing is, CTEM is all about context: which findings connect to each other, which findings sit on a path to a critical asset, and which ones an attacker could chain together to reach something valuable. A vulnerability scanner produces none of that. It delivers a list of findings ranked by severity scores – and has no native visibility into identity exposures, user behavior, browser configurations, or AI-related attack surfaces.
Where Exactly Scanners Break Down Across the CTEM Lifecycle
CTEM is a five-stage process: scoping, discovery, prioritization, validation, and mobilization. It helps to walk through the stages and see exactly how far vulnerability scanner capabilities can reach for each:
❌ Scoping – A vulnerability scanner has no concept of business priority. It scans what it can reach and returns what it finds, with no understanding of which assets would cause real damage to your organization if they were compromised.
✔️ Discovery – Scanners contribute here, but only partially. Identity exposures, misconfigured permissions, cached credentials, lateral movement paths, user behavior, browser configurations, and AI-related attack surfaces have no CVE numbers and don’t appear in scanner output.
❌ Prioritization – Scanners rank findings by CVSS scores only, with no connection to business impact. A critical CVE on an isolated system would score identically to a misconfiguration that sits one step from your domain controller.
❌ Validation – A scanner confirms a vulnerability exists, and may provide an EPSS score suggesting exploitability in the wild. It cannot check whether a certain exposure is exploitable in YOUR environment, nor whether it can be used to compromise other entities in the environment.
❌ Mobilization – A CVE list identifies what is broken. It does not indicate the urgency of remediation, remediation guidance, remediation ownership, or what the impact of each fix will be on risk to the business.
The Reporting Problem
Vulnerability scanner-based reporting creates a unique problem for CISOs: it generates answers to questions that nobody is asking.
When a high-profile CVE makes headlines, organizational leadership wants to know what it means for their organization – which systems are exposed, how serious the risk is, and what it would take for an attacker to reach something critical. What I see time and again is the scanner delivering a list – how many systems are affected, ranked by severity score, but with no business context whatsoever.
The consequences play out the same, too. Based on the list, security teams spend cycles chasing high-scoring vulnerabilities on low-value systems while genuinely dangerous exposures go unaddressed. I’ve also watched leadership operate with either false confidence – believing their patching regime actually lowers risk – or false urgency, treating every critical CVE as an immediate crisis regardless of its real-world exploitability. Both scenarios waste organizational resources that CTEM could direct more precisely.
The Threat Landscape Has Moved On
Something I raise with every security leader I work with is how dramatically the threat environment has shifted – and how that shift has exposed the limits of point-in-time assessment.
A scan scheduled for Tuesday morning reflects the state of your environment on Tuesday morning. Within 48 hours, as your teams patch systems and configurations change, that data is already stale. That’s the nature of point-in-time assessment – it was never designed to keep pace with a continuously changing environment.
Yet your continuously changing environment is exactly where AI-powered attackers are thriving. AI-assisted attack tooling has shrunk the window from initial access to full breach from weeks to minutes – faster than any scan cadence can match. That’s exactly the gap CTEM was built to close – continuous assessment that reflects how the environment actually looks at any given moment.
The Threat Landscape Has Moved On
In my experience, most organizations run vulnerability scans primarily to satisfy compliance requirements – and this is a legitimate use. Frameworks like PCI-DSS, HIPAA, and NIST call for periodic scanning, and scanners deliver exactly what those frameworks ask for.
The problem comes when compliance-driven scanning gets mistaken for a risk management program.
In these cases, I remind leaders that CTEM is not a compliance exercise. It is a continuous assessment of how attackers could actually move through your environment – and what they could get to. Attack path management – the core of any serious CTEM implementation – operates at a fundamentally different level than periodic compliance scanning. Compliance tells you whether required controls exist. CTEM tells you whether they work.
Building on the Right Foundation
Vulnerability scanners have a place in a mature security program. But a CTEM program built on scanner output alone will stall – because CTEM demands continuous assessment, attack path context, and prioritization aligned with business goals. These are things a scanner was never designed to provide. The same holds for scanners with CTEM capabilities bolted on. Capabilities assembled on top of a foundation never match those built into the design from the start.
The security leaders who are effectively driving CTEM adoption have learned this firsthand. And they’re not doing it for compliance reasons. They’re doing it because they’ve watched their teams spend cycles on the wrong problems. The right CTEM foundation changes that. It gives security and IT a shared, accurate picture of risk – and a clear basis for every remediation decision that follows.
The path from vulnerability management to exposure management starts with knowing where you are. Assess your program’s maturity now.
