Honest reporting

A scan that couldn't check isn't a clean scan

A scanner's worst failure isn't a crash. It's reporting a clean result it never actually established. CveDeck keeps "no findings" separate from "didn't find out".

U1 · The problem

Four meanings of "0 findings"

A fleet row reading web-01 · linux · success · 0 0 0 0 can mean any of these. Only the first is good news, and CveDeck reports each one distinctly.

  1. Clean

    The host is genuinely clean. Every configured source answered, and nothing matched.

  2. Partial

    An advisory source was unreachable during the scan. The result is marked partial and raises a warning, never shown as clean.

  3. Stale

    The host was scanned long ago and nothing has looked since. Scan age is shown on every host, and scans older than seven days are flagged as stale.

  4. Never scanned

    The host was enrolled but never scanned. It says so, in a neutral state, rather than showing a failure for a connection nobody tried to make.

Fleet table rows from the demo: nas-01.lan last scanned a month ago, bastion.lan could not connect, dc-01.lan (Windows) never scanned, new-host.lan never scanned, and pi-sensor.lan authentication failed.
Demo fleet: a stale scan, a failed connection, failed authentication, and two hosts that have never been scanned, one of them a Windows host whose scan button is disabled.
U2 · Partial

Only real outages count as partial

Each scan records whether every configured advisory source answered. A failed lookup reaches the matcher as a failure, not as an empty answer, so a source outage can't quietly turn into "no advisories".

Only configured sources count. NVD matching is off by default, and a deployment that hasn't turned it on doesn't get every scan branded partial. That would train people to ignore the warning. When NVD is enabled, a rate-limited request counts as a real outage, so a throttled scan reports partial.

U3 · Failures

Failures that tell you what failed

An unreachable host and a failed login are reported as failures, not as hosts with zero findings. Each failure carries the original error message, so you can tell a wrong password from a rejected key, or a DNS failure from a filtered port.

A pre-flight connection test reports reachability, credentials and the OS banner before you commit to a scan.

U4 · Unknown

Unenriched is not unexploited

The same failure mode appears one level down, in threat intelligence. If no usable CISA KEV catalog existed when a finding was recorded, its exploitation status is unknown, not "not exploited".

Collapsing unknown into "no" would produce the worst available outcome: a dashboard reporting "0 actively exploited" across a whole fleet, on the authority of a catalog that was never downloaded. CveDeck shows a muted dash instead, raises a banner when a feed is stale or unusable, and reports each feed's age through its API.

The three exploitation states are explained with the ranking.

U5 · Runtime

Installed isn't the same as running

A host can have every package updated and still be running the vulnerable kernel it booted from. A scanner that only reads the package list reports that host as clean.

CveDeck's Linux collector also reads the running kernel and the pending-reboot state: /var/run/reboot-required on Debian and Ubuntu, needs-restarting -r on the RHEL family. Where a distribution offers no read-only way to ask, the state is recorded as indeterminate rather than guessed.

U6 · Windows

Refusing a scan rather than faking one

Windows hosts can be discovered and enrolled, but CveDeck can't yet match Windows software or cumulative updates against vulnerability data. A Windows scan would finish with no findings, which looks exactly like a clean host. So Windows scans are refused, with that reason, and the host stays enrolled and never scanned.