What does a quarterly point-in-time vulnerability scan miss that continuous assessment of the same estate catches?
answer
- a snapshot ages from the moment it ends
- assets, state and knowledge all drift
- hosts born and gone between runs
- new checks against software already present
basics
~20 sA point-in-time scan proves the state of the hosts it reached on the day it ran. It misses hosts that came and went between runs, changes made since, and newly disclosed flaws in software it already saw.
solid answer
~40 sA scheduled scan is a snapshot: it describes the hosts that answered, at that moment, judged against the checks the scanner had that day. Between runs three things drift. The **asset set** changes (short-lived instances, laptops off the network on scan day), **host state** changes (a package installed, a service enabled, a fix rolled back) and **knowledge** changes (new checks published for software that was already there). Continuous assessment narrows those gaps by keeping inventory and installed-software data fresh, through frequent scans, resident agents or a passive sensor, and by re-assessing stored data when new checks arrive. A quarterly scan can still serve as an audit artefact, but its result goes stale as soon as the run ends.
go deeper
Remember that a scan report is dated: it shows the hosts that answered, as they were, against the checks known that day. Name the three things that drift afterwards: assets, host state and new checks.
Explain how continuous assessment is assembled from frequent scans, agents, passive sensors and re-assessment of stored software inventory when new checks arrive, and why short-lived hosts defeat any fixed scan interval.
Show that you set cadence per segment from asset lifetime, exposure and fragility, and that you track time since last successful assessment per host so stale coverage is visible.
Frame cadence as a cost-versus-staleness trade across the estate: where creation-time assessment replaces scanning, where a rare thorough scan is the only acceptable option, and which freshness target leadership signs up to.
## What a point-in-time scan actually proves A **point-in-time scan** is a scheduled run (weekly, monthly, quarterly) that probes a list of targets and produces a report. That report is precise about three things and silent about everything else: - **which hosts answered** during the run, from the scanner's position on the network; - **what state those hosts were in** at the moment each was checked; - **which flaws the scanner knew how to detect** that day, because detection depends on the set of checks it had loaded. Everything the report says is true *as of the run*. The mistake is reading it as a description of the estate *now*. A quarterly cadence means that, on average, the report a manager is looking at is about six weeks old, and for some hosts it is almost three months old. ## Three kinds of drift between runs | Drift | Example | Why the last scan cannot show it | |---|---|---| | **Asset drift** | An autoscaling group creates and destroys instances every few days; a laptop was at home on scan day | The host never existed, or never answered, while the scan ran | | **State drift** | Someone enables a legacy remote-admin service, installs an old library, or rolls back a patch after an incident | The host was clean when checked and changed afterwards | | **Knowledge drift** | A flaw is disclosed in a web server version the scan inventoried last month | The check for it did not exist when the scan ran | Knowledge drift is the one people forget. A host can be untouched since the last scan and still be newly exposed, because the world learned something about software it already runs. A clean report from before the disclosure says nothing about the new flaw. ## What "continuous" means in practice Continuous assessment is not one technique; it is the goal of keeping the gap between reality and the record small. Programmes get there by combining: - **frequent scheduled network scans**, daily or weekly for exposed or critical segments instead of quarterly for everything; - **resident agents** that report installed software and configuration on a short heartbeat, which also covers hosts that are rarely on the corporate network; - **passive sensors** that notice new hosts and services from traffic as they appear; - **re-assessment of stored inventory**: when a new check arrives, comparing it with the software lists already collected, so a newly disclosed flaw is flagged without waiting for the next probe; - **inventory feeds** from virtualisation and cloud APIs, so a host created between runs is at least known to exist. How each collection method sees a host, and what each misses, is a detection question rather than a programme one; here the point is that the programme needs *fresh* data, by whatever means. ## Choosing the cadence Cadence is a risk decision, not a fixed rule. A workable way to set it: 1. **Measure asset lifetime.** If many hosts live for days, a monthly scan cannot see them; inventory and assessment have to happen at creation time instead. 2. **Weigh exposure.** Internet-facing and high-value segments get the shortest interval; an isolated test lab can tolerate a longer one. 3. **Respect fragility.** Active scanning has a cost on delicate devices, so some segments get infrequent, carefully windowed scans plus passive observation in between. 4. **Track freshness per host.** Record the last time each host was successfully assessed and set a target (for example, every production host assessed within seven days). Hosts outside the target are a gap, whatever their finding count. ## Where the snapshot still belongs Point-in-time scans are not useless. An external auditor may ask for a dated report; a scan before and after a major change gives a clean comparison; and a deliberately thorough scan of a fragile segment may only be acceptable inside a rare maintenance window. The discipline is to label the result honestly: *this is what we saw on this date, from this position, with these checks*, and to measure the estate's real state with something that does not age as fast. ## Summary - A point-in-time result is accurate about the past and silent about the present. - Assets, host state and detection knowledge all drift between runs. - Continuous assessment combines frequent collection with re-assessment of stored data against new checks. - The metric that exposes staleness is **time since last successful assessment per host**, not the number of open findings.
- If the estate is scanned weekly instead, what still escapes it?Hosts that live for less than a week may never be scanned at all, hosts that were off the network on scan day are skipped, and anything disclosed or changed mid-week waits for the next run. Short-lived workloads need assessment at build or creation time and an inventory feed from the platform that creates them, not a faster network sweep.
- How do you show an auditor that coverage held continuously across a quarter?Report time since last successful assessment for every host in the inventory, the share that stayed inside the freshness target each week, and the hosts that fell outside it with a reason. A single end-of-quarter report proves one day; a freshness series shows the whole interval.
A quarterly scan is a photograph of a busy street: accurate about who stood there when the shutter clicked, silent about who has arrived since. Continuous assessment is closer to a camera that keeps recording and re-examines old footage when it learns what to look for.
saying these in an interview costs you the question
- A clean quarterly report means the estate is clean today.
- A host that has not changed since the last scan cannot have become vulnerable.
- Hosts that were offline on scan day can be assumed unchanged.
- Continuous scanning means running intrusive checks against every host around the clock.
- The open-finding count tells you how current the scan data is.