Vulnerability BI — sidebar hides with the toggle

How a Network Scan Works in VulnMonitor

A network scan tells you what is reachable and what evidence was collected. It is deliberately careful about the difference between something that was observed and something that is confirmed to be a risk.

Where the scan runs from

A network scan runs from a collector you start on a machine that can already reach the addresses you want to look at. There is no scanning from our side and no access to your network from the internet.

If the range you enter is not reachable from that machine, coverage will be incomplete. An empty result in that case means unknown, never secure.

What it records

The agent uses configured discovery checks to identify reachable hosts and collect network observations. Discovery can be limited by routing, firewall behavior, permissions, device configuration, and the collector's network location.

On each reachable address it checks a set of service ports and keeps whatever it can read without logging in or changing anything: the open port and protocol, a generic service label, and where a service answers, a banner or certificate detail. Every observation keeps its time, its host and which collector produced it.

Ports that answer but reveal nothing about the software behind them are still kept. They are real exposure and they stay visible; they simply cannot say which product is listening.

Two scan settings

Standard checks a fixed list of common service ports. It is fast and safe to run during working hours.

Deep checks the whole port range on each host. It is much slower, so it is limited to far fewer hosts per run and to a small number of runs at a time.

Both settings check TCP services only. UDP services are not examined.

An open port is not a vulnerability

A port that answers, or a generic service name such as "SMB" or "HTTP", says nothing about which product or which version is running. On its own it can never produce a vulnerability claim, no matter how well known the port is.

Before a public vulnerability becomes a confirmed exposure for you, the scan needs evidence that identifies the product and its version well enough to be checked against the versions that vulnerability actually affects.

Four honest outcomes for every result

  • Matched — the evidence lines up with a catalogue entry.
  • Several possible — more than one entry could fit; a person decides.
  • No match — nothing in the catalogue matched this evidence.
  • Rejected as too weak — something could have matched, but the evidence was not strong enough to claim it.

Those are results of the scan. Separately, each grouped issue carries its own status: Confirmed, Needs review, Identity unconfirmed, or Not affected. Only confirmed, current issues count towards your risk totals and become work in Remediation.

PC and network parts stay separate

A full scan does two different jobs: it inventories the machine it runs on, and it looks at the network range you gave it. The two sets of evidence are kept apart and stay traceable to the part that produced them, so a busy network sweep can never bury or overwrite what the machine itself reported.

When a scan does not go to plan

Unreachable targets, hosts that block probes, missing permissions, timeouts and failed uploads are all recorded as what they are: incomplete coverage. A scan that collected nothing is shown as a scan that collected nothing — it is never presented as a clean result.

Your data stays yours

Scans, evidence, findings and remediation work are visible only to members of the organisation that ran them. The original collected evidence is kept unchanged so any conclusion can be traced back to what was actually seen, and repeated uploads of the same evidence do not inflate your counts.