Why is a finding's absence from the next scheduled host scan not proof of a fix, and what evidence closes it?
answer
- absence is not a negative result
- did the check actually run
- same vantage, same access, same check
- record the evidence with the closure
basics
~20 sAbsence only shows nothing was reported: the host may have been unreachable or unauthenticated, or the check never ran. Close a fix on a targeted rescan in which the same check ran with the same access and found the flaw absent.
solid answer
~40 sA finding can drop out of a scan for many reasons besides a fix: the host was off or filtered, login failed so local checks never ran, the target list or scan policy changed, the scan timed out, or the check itself was rewritten. So closure needs **positive evidence**: a rescan of that host from the same vantage point, with authentication confirmed, using a policy that includes the check, in which the check ran and reported not-vulnerable. Trigger it as a targeted verification scan of the host and that check, so the owner gets an answer in minutes rather than at the next cycle, and record the scan, time and authentication status with the closure. If a fix was installed but is not yet active, the rescan rightly refuses to close it.
go deeper
Remember that a finding missing from a later scan is not the same as a check that ran and said not vulnerable; hosts can be skipped, unreachable or unauthenticated.
Explain the list of reasons a finding can vanish, and what a verification rescan must match: target, vantage point, authentication, the check itself and evidence that it ran.
Show how you run on-demand verification scans, record their evidence with every closure, and dispose of false positives narrowly, with a reviewer and reopen triggers.
Set the programme's evidence standard for closure and false-positive disposal so that closure rates mean something, and decide how much owner self-attestation, if any, the programme accepts.
## Why absence is weak evidence When a host owner says *fixed*, the tempting test is: did the finding disappear from the next scheduled scan? That test confuses **absence of a report** with a **negative result**. A scanner reports a finding when a check runs and decides the host is vulnerable. If the check never ran, or ran with less access, the finding disappears just as it would after a real fix. | Why the finding vanished | How to tell | |---|---| | The host was off, filtered or out of range | The host is missing or marked dead in that scan | | Authentication failed or lacked privilege | Per-host authentication status is failed or partial | | The scan policy changed and no longer includes the check | The policy's check list differs from the original scan's | | The scan timed out or was stopped early | The host's scan is marked incomplete or its duration is cut short | | The check was revised or retired in an update | The check's history or version changed between runs | | The flaw was actually fixed | The check ran, with full access, and returned not-vulnerable | Only the last row is a fix. Every other row is a coverage problem that looks like progress. ## What a verification rescan must match A **rescan-to-verify** is a targeted scan whose purpose is to produce a negative result you can trust. It should match the original detection on every dimension that matters: 1. **Same target**: the host, identified the same way (address changes after a rebuild are common). 2. **Same vantage point**: the same scanner or zone, so the path does not differ. 3. **Same or better access**: authentication confirmed as passed, with the same privilege. 4. **Same check included**: a policy that contains the check that raised the finding, at a current version. 5. **Evidence that it ran**: the check appears in the scan's executed set for that host and returned not-vulnerable. Scoping the rescan to that host and the relevant checks makes it fast enough to run on demand, so closure is not held until the next scheduled cycle and owners get feedback while the change is fresh. ## Recording the closure A closed finding should carry its evidence with it: - the verification scan's identifier and time; - the host's authentication status in that scan; - the check's result (ran, not vulnerable); - the change that fixed it, if the owner supplied one. With that record, a reopened finding can be compared directly, and an auditor can see why each closure was accepted. ## Disposing of a false positive with evidence Sometimes the owner's claim is not *fixed* but *never real*. Disposing of that as a **false positive** needs a different kind of evidence, and the same discipline: - **Show the premise is false on this host.** The record should hold the local evidence (installed version, configuration, presence of the fixed component) that contradicts the condition the check reported. - **Scope it narrowly.** The disposition applies to this check on this host. One host's evidence does not justify silencing the check across the fleet. - **Name a reviewer.** Someone other than the owner who benefits from closure should confirm the evidence. - **Set reopen triggers.** If the check is revised, or the host is rebuilt or its software changes, the disposition should lapse and the finding be re-evaluated. Why a check produced a false positive in the first place is a detection question; the programme's job is to make sure the disposal is evidenced, narrow and revisited. ## When the rescan still shows it A verification rescan that still reports the finding is doing its job. Common reasons are a fix installed but not active (a service or host that has not restarted), a fix applied to one of several instances behind the same name, or a second vulnerable copy of the software elsewhere on the host. Making the fix take effect is the patching discipline's problem; the scan programme's contribution is refusing to close what it cannot verify.
- The owner says the finding was never real. What must a false-positive disposal record?Local evidence that the condition the check reported is not present on this host, scoped to this check on this host, confirmed by a reviewer other than the owner, with reopen triggers when the check is revised or the host changes. Without the evidence it is an unverified claim; without the scope it silences the check fleet-wide.
- How do you make verification fast enough that owners actually ask for it?Offer an on-demand verification scan scoped to the host and the checks behind its open findings, run from that zone's scanner with its normal credentials, and triggered from the remediation ticket. Post the result, with authentication status, back to the ticket. Minutes of feedback while the change is fresh beats waiting for the next cycle and arguing about it.
saying these in an interview costs you the question
- If the next scheduled scan does not list the finding, it is fixed.
- An owner's ticket comment saying it was patched is enough to close the finding.
- One host's false-positive evidence justifies suppressing the check across the fleet.
- A verification scan can use any scan policy as long as it targets the host.
- Once a finding is marked false positive it never needs revisiting.