Scan coverage and sources

The Scan coverage screen compares the inventory's server list against the names vulnerability sources have reported on, and puts the servers nobody has said anything about first. That denominator — who was supposed to be scanned — is not something a scanner holds. The inventory is.

What is actually measured

The screen counts servers some source has already reported a finding on, using the exact server list each register row carries. That is not the same thing as “scanned”.

Estimated matching — the OS-family identification described in How a vulnerability is matched to a server — is deliberately not counted here. A guess that a server is probably vulnerable is not evidence that anybody looked at it.

The three counts

Count	What it holds
No source reported on them	Inventory servers no register row has named. Clicking filters the table down to them
Servers reported on	The counterpart, and its share of the inventory
Names reported that are not in the inventory	Names a source gave that the inventory does not know — a machine nobody registered, or a spelling that cannot be reconciled

The third is counted and named on the screen. It is not dropped.

The table itself gives each server its state, its system, its tier, its operating system, which sources reported on it, how many reports and when the last one arrived. Clicking a row opens the server record. If the inventory or the register could not be read, the screen says which leg is missing and that the numbers are partial — rather than showing a smaller number as though it were complete.

Sources — what actually fed the register

The Sources screen reports not what was configured but what arrived. Every row in the register carries the source that wrote it, and the screen groups by that: how many rows, how many of them carry an exact server list, how many inventory servers they touched, and when the last one was.

Source kind	What it is
Automatic feed	A process that runs on its own and writes into the register
File import	A file fed in by hand through the screen
Manual entry	A vulnerability written in the form

This screen is open to administrators only.

File import

The Import CVEs from a file button accepts CSV or JSON, by drag or by picking. The file format is readable inside the dialog itself, under “File format”:

cve_id,title,cvss_score,severity,os_family,os_pattern,kb,published_date,patch_release_date,notes

A header row is required, cve_id is required, dates are YYYY-MM-DD, and JSON is an array of objects with the same fields. severity is one of critical · high · medium · low, and when it is missing it is derived from the CVSS score. os_family is Windows or Linux. A report is shown at the end: how many were added, how many updated, how many skipped, and the list of errors.

A vulnerability already in the register is updated — but its status is kept. An import never returns something marked as resolved to Open.

On a disconnected network this is the ordinary path; see Air-gapped deployment.

Clearing legacy records

A “legacy record” means a record with no recorded patch, and that is the only criterion.

Two things are easy to infer here and are not true. Such a row does not necessarily land in the No patch group — if it carries a KB number it is grouped by the KB, and it then appears in Working by patch exactly like any other row. And host matching does not follow from it at all: a row counts as authoritative when the feed named the affected host names, whether or not a patch was recorded. See How a vulnerability is matched to a server.

Clearing is a button, and never a side effect of an import. The dialog states the criterion, counts the rows and shows them, and requires typing the count before the delete is armed. Hand-entered vulnerabilities are excluded unless explicitly ticked — somebody typed those on purpose, and “no patch yet” is a normal state for one.

The delete cannot be undone, it also removes the per-server handled marks, and the audit log is kept. Until the button is pressed, legacy records keep rendering in the register as before — an ingest that quietly deleted records would be indistinguishable from a fault.