Port State Changes
The Port State Changes page tracks port state transitions between consecutive scans. The ledger is populated automatically after every completed scan — each scan is diffed against the previous completed scan of the same template, per scanner vantage, and only the opened/closed transitions are recorded (unchanged ports are not re-listed). This is a core GRC feature for compliance tracking, providing evidence of network changes over time for SOC2 and ISO 27001 reporting.
Fields & columns
| Name | Description |
|---|---|
Time | Timestamp when the state change was detected |
IP | IP address of the host where the port state changed |
Port | Port number that changed state |
Protocol | Transport protocol (TCP or UDP) |
Previous State | Port state before the change (open, closed, or filtered) |
Current State | Port state after the change (open, closed, or filtered) |
Service | Detected service running on the port, if identified |
Version | Detected service version, if identified |
Scan | Name of the scan that detected the state change |
How to
Track port state changes for compliance
- Navigate to Audit > Port State Changes.
- Filter by subnet or port range.
- Review opened and closed port events.
- Export the filtered view for compliance documentation.
Gotchas
- State changes are stored in TimescaleDB for efficient time-series queries and automatic compression.
- Scanner groups scanning from different vantage points may report different states for the same port, since network path or firewall rules may differ per location.
- A port transitioning from "filtered" to "closed" or vice versa may indicate firewall rule changes rather than service changes.
- State changes are only detected between consecutive scans of the same target. A port must have been seen in a prior scan to generate a change record.
- Only state CHANGES are recorded — a port that stays open across scans is not re-listed (storage compaction). Absence of rows for a scan can mean "no changes" (it had a baseline) or "baseline scan" (no prior scan); the scan results page distinguishes these.
- A change row that came from a scanner-reported (compacted) run links to the execution receipt for the job that produced it (its job id → the job receipt detail). The receipt is the proof the change is grounded in a real, fully-attempted run. Rows derived by the server-side reconciler have no single owning job, so they show no receipt link.
- The evidence hash on a change row is the receipt result hash — a verification REDUNDANCY you can cross-check against the linked receipt, not the lookup key. The job id is the link; the evidence hash is the anchor you compare once you arrive.
API calls (1)
| Method | Path | Description |
|---|---|---|
| GET | /api/audit/states | List port state changes with filtering |
Related
- Changes — Tracks configuration changes rather than network state changes
- Views — Tracks read access to resources rather than port state transitions
- Auth — Tracks authentication events rather than network state changes
- Execution Proof — The per-job receipts a compacted change row links to via job id — proof the change came from a real run
- Job Receipt — The single receipt a change row opens; its result hash is the row's evidence anchor