mipo

Results

Displays the detailed findings of a single completed scan, including all discovered hosts, ports, and services. Security engineers use this page for attack surface monitoring — identifying unexpected open ports, new services, and deviations from expected baselines. Results are paginated and loaded on demand as you scroll to handle large scans efficiently. Failed scans show per-scanner error details.

Fields & columns

NameDescription
IP AddressThe target host IP (IPv4 or IPv6) where the port was discovered
ScannerName of the scanner that discovered this result (useful for multi-vantage scans)
PortPort number and protocol (e.g., 443/tcp)
StatePort state: Open (accepting connections), Closed (refused), or Filtered (no response / firewalled)
ServiceDetected service name based on port number or banner analysis
BannerRaw response string from the service, useful for version identification
DiscoveredTimestamp when the scanner detected this host/port combination
ChangesOpened/closed port-state transitions vs the previous scan of this template (per scanner vantage). "Baseline scan" means there is no prior scan to compare.

Gotchas

  • The Changes section compares this scan against the previous completed scan of the same template, per scanner. A scanner that did not run this time will not produce false "closed" changes. "No changes since scan #N" is a real result (stability), distinct from a baseline scan.
  • Results are paginated server-side — scroll down in the table to load additional pages automatically. Use the rows-per-page selector in the table footer to choose how many results are fetched per scroll page (20 / 50 / 100 / 250). Changing the value restarts loading from the top.
  • The IP, Port, State, Service, and Scanner columns support server-side filtering: selecting a filter value re-queries the server for the full matching set, so the "of Z" total in the footer always reflects the filtered result count — not just the rows loaded so far.
  • A scan with zero results does not necessarily indicate an error; it may mean no open ports were found in the target range.
  • Failed scan error details come from the jobs database and may take a moment to load separately from the scan metadata.
  • Export-context tracking is operational, not user-tagging. When you export results, mipo records WHO exported, WHEN, the source query, the row count, and the file format. This builds the audit trail for compliance review. It does NOT let you attach custom labels (department, audit period, framework) to the export — that taxonomy lives in your downstream evidence-management system.
  • You can cancel a pending or running scan with the Cancel button by the status badge. Pending work never dispatches; in-flight scanners abort mid-probe (older scanner builds finish their current job, then the scan still reaches "cancelled"). Partial results gathered before the stop are kept. A cancelled scan is never used as a diff baseline.

API calls (9)

MethodPathDescription
GET /api/scans/:id Retrieve scan metadata (name, status, timestamps, result count)
GET /api/scans/:id/results Paginated scan results (hosts, ports, services)
GET /api/audit/states?scanId=:id Port-state transitions (opened/closed) detected for this scan
GET /api/scans/:id/progress Scan progress and per-scanner error details for failed scans
POST /api/scans/:id/save-tests Save test baselines for scan results
GET /api/scans/:id/results-with-tests Get results with test pass/fail data
GET /api/export/context Get export metadata for compliance reporting
POST /api/export/context Configure export context for audit evidence
POST /api/scans/:id/cancel Cancel a pending or running scan (requires scans:execute)

Related

  • Recent Scans — Lists all scans; click a completed scan to view its results
  • Scan Templates — Defines which subnets and ports were included in the scan
  • Execution Proof — Per-job receipts proving the scan ran (including no-change runs); results show what it found, proof shows that it happened