Skip to content

Reading Reports

Evan Newman edited this page Oct 3, 2026 · 1 revision

Reading reports

A Watchpost report is a starting point for human investigation, not an automated security verdict.

Check the context first

Each report records the input paths, UTC scan windows, Nmap version, scan method, and observation counts. It states that the user confirmed matching scan context. It does not independently verify the scanner's location or the intended target scope.

Keep the original XML files with the report. Source references do not embed or authenticate those files.

Understand the findings

Finding What it means What it does not prove
Port state changed Both snapshots contain explicit states, and those states differ Why or exactly when the change happened
Port newly observed No earlier explicit record exists for that address/port The port was previously closed or a service just started
Port not observed later No later explicit record exists The port closed
Address newly observed The address appears only in the later inventory A new physical device joined
Address not observed later The address appears only in the earlier inventory A device was removed

not observed is Watchpost's description of missing evidence, not an Nmap port state. Grouped <extraports> counts do not become explicit per-port observations.

Address and port differences are separate counts. One address difference plus several port differences does not mean several separate incidents.

Read states literally

  • open: the supplied scan reports the port as open from that scan location.
  • closed: the supplied scan explicitly reports the port as closed.
  • filtered, unfiltered, open|filtered, and closed|filtered: retain their original labels.

An open port does not identify the application or prove Internet exposure. A closed observation does not prove inaccessibility from every location. Watchpost does not relabel uncertain states as confirmed open or closed.

Review the evidence

  1. Read the earlier and later evidence for each finding.
  2. Confirm address assignments using separate asset records.
  3. Compare the observation with the intended deployment and access policy.
  4. Check listening interfaces and applicable firewall rules.
  5. Record supporting evidence, unanswered questions, and a bounded conclusion.

The report provides blank investigation and conclusion fields. Its suggested checks use fixed rules, not AI analysis.

No observed changes

Matching supported observations produce:

No observed changes in explicit IPv4/TCP records.

This is not a safety verdict. Watchpost does not compare hostnames, service names, script results, host status, or grouped states.

Practice the three scenarios →

Reference: reporting boundaries and safety design.

Clone this wiki locally