Why does a vulnerability scanner's verdict depend on its vendor-maintained check feed, and what does feed lag mean for a clean scan run the day after a disclosure?
answer
- the engine knows no vulnerabilities
- a check per flaw
- authoring lag and sync lag
- no check fired is not safe
basics
~20 sA scanner detects only what its checks describe, and checks arrive through a vendor-maintained feed. Until a check for a new flaw is written, published and downloaded, nothing reports it, so a next-day clean scan says nothing about that flaw.
solid answer
~50 sThe scanning engine itself knows no vulnerabilities; every finding comes from a *check* that carries the detection logic — affected versions or the probe to send, the conditions, severity and remediation text — and the vendor ships checks through a feed that scanners typically pull daily. That creates two lags: the **authoring lag** between public disclosure and the vendor publishing a check, and the **sync lag** between publication and your scanner loading it, which a failing update job or an isolated scanner can stretch to weeks. So a clean scan the day after a disclosure means "no loaded check fired", not "not affected": first confirm a check for that flaw exists, and was in the feed your scanner had when the scan started. The feed also changes results on hosts that did not change: a new or corrected check adds or clears findings.
go deeper
Recall that a scanner only finds what its checks describe, and that those checks arrive through a regularly updated vendor feed.
Explain the authoring lag and the sync lag, what a check carries, and why a corrected check changes results on a host that did not change.
Show how you prove a scan could have detected a specific flaw — check existence, feed version at scan start, enablement, prerequisites — before reporting exposure to anyone.
Weigh feed coverage and speed as a detection dependency: what you do for products the feed covers poorly, and how a scanner's update failures are themselves monitored.
## The engine knows nothing; the checks know everything A host vulnerability scanner is two things: an **engine** that connects to hosts, logs in, runs procedures and records results, and a **library of checks** that tells the engine what to look for. The engine contains no knowledge of any particular flaw. Every finding in a report exists because a check for it was loaded when the scan ran and its conditions matched. The check library comes from the scanner's vendor as a **vendor-maintained check feed**: a continuously updated set of checks the scanner downloads, typically every day. ## What a check carries A single check usually bundles: - **Detection logic** — which versions are affected, which probe to send, which local file or package to read. - **Prerequisites** — the port or service it needs, whether it requires credentials, whether it is safe or intrusive. - **Metadata** — the identifiers of the flaw, a severity, a description and remediation text. Because the logic lives in the check, a check can also be **wrong** and later **corrected**: a mis-stated version range, a missed distribution release, a false-positive condition. The correction arrives through the same feed. ## The lags between disclosure and detection From the moment a flaw becomes public to the moment your report can show it, several steps must happen: 1. The flaw is disclosed, often with an advisory naming affected and fixed versions. 2. The vendor's researchers write and test a check for it. 3. The check is published in the feed. 4. Your scanner downloads that feed update. 5. A scan runs with the check enabled and its prerequisites met. | Lag | Between | What stretches it | |---|---|---| | **Authoring lag** | Disclosure and published check | Missing details in the advisory, hard-to-detect flaws, many simultaneous disclosures | | **Sync lag** | Published check and loaded check | Failing update jobs, scanners without internet access, manual offline updates | | **Scan lag** | Loaded check and next scan | The schedule of the scan itself | Isolated scanners deserve particular attention. A scanner on a network without internet access is updated by hand from an offline copy of the feed, so its sync lag is whatever that manual procedure makes it. A failing update job is worse than a slow one: the scanner keeps scanning and keeps producing reports that look complete. For a widely deployed product and a well-documented flaw the authoring lag can be short; for an obscure product it can be long, and for some products no check ever appears. ## Reading a clean result correctly A clean result is only meaningful if the scan *could* have found the flaw. Before trusting it, establish: - **Does a check exist?** Search the vendor's check catalogue for the flaw's identifier and note its publication date. - **Was it loaded?** Compare that date with the feed version the scanner recorded at scan start. - **Was it enabled?** A check excluded by the scan configuration — an intrusive check in a safe-only scan, a disabled check category — never runs. - **Were its prerequisites met?** A local check without working credentials, or a remote check against a port it could not reach, cannot fire. Only when all four hold does "no finding" mean "not detected by a check that looked". ## Feed updates change findings on hosts that did not change The feed is the most common reason a report changes overnight on an untouched host: - **New checks** add findings for flaws disclosed since the last update — the host was already affected; the scanner just learned to see it. - **Corrected checks** add findings (a widened version range) or clear them (a fixed false-positive condition). - **Re-scored checks** change a finding's severity without changing the host at all. So before crediting someone with a fix, or opening an incident over a new critical, compare the two scans' feed versions and the changed checks' dates. ## What to take away A scanner's knowledge is exactly its feed, as of its last successful update. A clean scan right after a disclosure is the expected result of the authoring and sync lags, not evidence of safety; and a changed report on an unchanged host usually means the feed changed. Knowing which checks were loaded — and when — is what turns a scan report into evidence.
- How do you establish that a scan was capable of detecting one specific, newly disclosed flaw?Find the check for that flaw in the vendor's catalogue and note when it was published, then compare with the feed version the scanner had loaded at scan start. Confirm the check was enabled in the scan configuration and its prerequisites held: working credentials for a local check, a reachable port for a remote one. Only then does an absent finding carry meaning.
- Findings changed overnight on a host nobody touched. What is the first explanation to rule out?A feed update. New checks add findings for flaws disclosed since the previous scan, and revised checks add or clear findings when a version range or condition is corrected. Compare the two scans' feed versions and the changed checks' publication dates before opening an incident or crediting anyone with a fix.
saying these in an interview costs you the question
- The scanner can detect new vulnerabilities without updating its checks.
- A clean scan after a disclosure proves the estate is unaffected.
- If findings change, something on the host must have changed.
- Checks for every disclosed CVE are available on disclosure day.
- Feed updates only ever add findings; they never remove any.