Working a VA result¶
Network VA produces the highest finding volumes in the platform, and the screens are structured around reducing that volume to something actionable. Knowing which view answers which question saves most of the time spent in this module.
Three views of the same data¶
| View | Groups by | Answers |
|---|---|---|
| Vulnerabilities | Host | Which machines are worst? |
| Overall vulnerability status | Vulnerability | Which single fix helps most? |
| View vulnerability | One finding | What exactly is this, and where? |
The second is the one people miss, and it is usually the most useful. A scan reporting 4,000 findings across 200 hosts is often 60 distinct vulnerabilities — and one of them patched everywhere might close a third of the total.
Working host by host through a large VA result is the slowest available approach.
The queue view¶
Network VA imports are large, so they are processed in batches. The queue shows those batches and their state.
Its practical use is answering "is the scan still loading?" A partly loaded scan looks exactly like a complete scan with fewer findings — there is no marker on the module screen distinguishing the two. Before investigating why a host has fewer findings than expected, confirm the import finished.
Reading a single finding¶
The detail view carries the evidence: the plugin or check that fired, the affected port and protocol, the scanner's output, and remediation guidance.
Two things worth checking before assigning it:
- Port and protocol. The same vulnerability on two ports is two findings against one host, and they may have different fixes.
- Whether an exploit is known. Exploit availability, not severity alone, is what distinguishes urgent from important. A Medium with a public exploit on an internet-facing host outranks a High that requires local access.
Why a host's count changed without a new scan¶
Three causes, in order of likelihood:
- SLA states moved. Nothing about the finding changed; a date passed. Overdue counts in particular change daily with no scan activity at all.
- A severity mapping was edited. Severity is derived from the score, so changing the boundaries re-classifies existing findings in bulk.
- The asset's grouping changed. Move a host between groups and it leaves one report's scope and enters another's — both are then correct and different.
Why a closed finding is open again¶
The host was scanned again and the vulnerability was still there. NxSAM re-opens the existing finding rather than creating a new one, so its history is preserved.
The common misreading is treating this as the platform failing to record the fix. It recorded it; the next scan disagreed. Either the fix did not take, it was reverted, or — frequently on VA — it was applied to one host in a group and not the rest.
Check whether the re-opened findings are on the same hosts as before or on different ones. Different hosts means the fix worked and the rollout was incomplete, which is a distribution problem rather than a remediation one.