A vulnerability scan run last month captured a moment in time. It doesn’t tell you what is exploitable today. Attack surfaces change constantly. Developers deploy new code, cloud instances spin up, SaaS integrations add API tokens, and contractors connect new devices. None of it waits for the next scheduled scan.
Equifax ran vulnerability scans. Its own SSL inspection appliance sat behind an expired certificate for 19 months, silently failing to decrypt and inspect traffic through the affected network segment. CVE-2017-5638, an Apache Struts remote code execution flaw, had a patch available in March 2017.
Attackers exploited the unpatched flaw in May 2017. The breach exposed 147 million records and cost the company more than $1.4 billion in total settlement and remediation costs, per Equifax’s own SEC filings.
Source Type: Company financial disclosure · Attribution Confidence: High.
The scan existed. It was not looking at the right thing, at the right time. That is the defect built into the point-in-time model: it answers a snapshot question inside an environment that moves continuously.
Why the Common Approach Fails
Periodic scanning treats vulnerability management as an inventory exercise: scan, list, patch, repeat next quarter. The gap between scans is where the damage happens.
Log4Shell, CVE-2021-44228, disclosed on December 9, 2021. Cloudflare recorded mass exploitation attempts within hours of disclosure, some within nine minutes of the proof-of-concept going public.
Source Type: Vendor blog · Attribution Confidence: Medium.
Organizations relying primarily on monthly or quarterly scans often lacked timely visibility into their exposure until the next cycle. By then, nested and shaded Log4j instances buried inside third-party dependencies had already been probed by opportunistic scanners running at internet scale.
Three structural failures repeat across breaches like these:
- Scans capture a fixed moment, but assets change continuously: new cloud instances, forgotten subdomains, and shadow SaaS connections all appear between cycles.
- Dependency chains hide vulnerable components inside other software, so a scan that only checks top-level inventory misses them entirely.
- The gap between scan and remediation creates a standing window, and mass internet scanning finds that window in hours, not months.
Point-in-time scanning is not a bad idea executed with bad tools. It is a model that assumes stability inside an environment defined by constant change.
The Better Model: Continuous Threat Exposure Management
Gartner introduced Continuous Threat Exposure Management in 2022, structured around five stages: scoping, discovery, prioritization, validation, and mobilization, run as an ongoing cycle rather than a quarterly project.
Gartner has projected that organizations building their security investment around CTEM will suffer two-thirds fewer breaches by 2026.
Source Type: Analyst report · Attribution Confidence: Medium.
The shift CTEM demands is not “scan more often.” It is a change in what the program treats as the unit of work. A point-in-time program manages a list of findings collected on a fixed date.
A CTEM program manages a live model of exposure that updates as the environment changes: new assets discovered continuously, new exploit intelligence pulled in as it publishes, remediation validated against the current state of the environment rather than the state at last scan.
Continuous does not mean scanning more frequently on the same calendar model. It means discovery, prioritization, and validation running as standing processes with feedback loops, not scheduled events with a start date and an end date.
Practical Application
Moving from point-in-time to continuous does not require replacing existing tools. It requires restructuring how those tools are used and what triggers them.
- Replace calendar-triggered full scans with asset-triggered discovery: a new instance spins up, discovery runs against it immediately, not at the next quarterly window.
- Feed exploit intelligence, including CISA KEV listings and EPSS scores, into prioritization as a live input rather than a monthly report reviewed after the fact.
- Validate that a finding marked “patched” is actually remediated in the running environment, not just closed in a ticketing system.
- Track exposure windows in days, not scan cycles: the metric that matters is how long a live, exploitable vulnerability sat in production before remediation, not how many scans were completed on schedule.
The Equifax certificate failure went undetected for 19 months precisely because nobody was validating that the scanning pipeline itself was functioning. Continuous validation catches a silently failing control long before an attacker finds the same gap.
Noorstream Perspective
Point-in-time scanning measures what the environment looked like. Continuous Threat Exposure Management measures what an adversary can reach now. That distinction is no longer academic. It is the difference between documenting risk after the fact and reducing it before compromise. In modern security, the question is not whether a scan completed. It is whether the organization understands its live exposure faster than an adversary can exploit it.