Network Security: every screen, column and action

This module has more screens, more row actions and more status values than any other, and it does not share its status model with Application Security even where the words look the same. Everything below is taken from the product's own tables and templates.

The status models — four of them, all different

Network Security does not reuse the AppSec statuses

The words overlap and the sets do not. Quoting an AppSec status list to a VA caller will not match what they see.

Audit status — twelve values

Saved → Requested → PMO Verified → Approved → Scheduled → IN PROGRESS → Completed, with Failed, Aborted, Review Requested, Changes Requested and Reverted as the exceptions.

Two properties decide behaviour:

• Comment required — Failed, Changes Requested, Reverted, PMO Verified and Aborted will not save without one. The others save silently.
• Closed type — only Completed and Aborted. An audit sitting in Review Requested is still open however finished it looks.

PMO Verified sits between Requested and Approved and exists for organisations running a project-management gate before scanning starts. Where that gate is not used the status is simply never selected.

VA vulnerability status — eleven values

New, Patched, False Positive, In Progress, Reopen, Exception Applied, Verified, Validated, Risk Accepted, Risk acceptance, Expired.

Closed types are Exception Applied, Verified and Validated — three, where the AppSec side has two, and Patched is again not one of them.

False Positive, Reopen and Risk Accepted require a comment.

PT vulnerability statusThe same eleven names in a separate table, so a status renamed for VA does not change for

PT. Risk accepted and Risk Acceptance additionally display a date.

PT validation status — three values

Saved, Submitted, Approved. Three, not the five Application Security uses — there is no Closed and no False Positive at validation level here, because a PT false positive is recorded through the vulnerability status instead.

VA Audits

The busiest screen in the module.

Columns

Column	What it holds
Request Info	Who requested the audit, when, and the request ID to quote in tickets
Audit Details	Audit name and the assets or scan target it covers
Vulnerabilities	Open counts with the severity split, and the audit's risk score
Audit Properties	The chips — cycle, type, tool, scope and whether the audit is considered
Audit Status	A dropdown offering only the legal next steps from the current status
Data Process	Whether imported scan data has finished processing for this audit

Data Process is the one people miss. An audit can be Completed while its data is still being processed, and counts will keep moving until that finishes. Check this column before investigating a total that will not settle.

Row actions — twelve

Action	What it does
View Vulnerabilities	Opens the findings for this audit — the normal drill-down
Vulnerability Overview	A summary by severity and host without leaving the list
Add More Assets	Extends the audit's scope to further hosts after it was created
Export Assets	Downloads the asset list in scope, for reconciling against the scanner
Manage Audit Scope	Records what was in and out of scope, with a description and an optional image
Manage Severity Config	Overrides how this audit's severities are derived
Assign Auditors	Sets who performs the work
Edit Audit Details	Name, cycle, dates and properties
Edit Tags	Free-form labels used for grouping and reporting
Re-Audit	Creates a follow-up audit against the same scope
View Audit Chain	Shows the original and every re-audit in sequence
View Status History	Every status change, with who made it and any comment
Delete Audit	Soft delete — the record is hidden, not destroyed

Manage Severity Config changes this audit's numbers only

It overrides the derivation for the audit it is opened from. Two audits of the same hosts can therefore report different severities for the same finding, legitimately. If two scans disagree and nothing else explains it, check this first.

View Audit Chain is the answer to "why do we have four audits for the same subnet" — they are a chain of re-audits, and the chain view shows which is current.

Launching or uploading a scan

The upload dialog is a full scan-configuration form, not a file picker. What it asks for depends on the tool:

Field	Applies to
Tool	Which scanner this data comes from or runs on
Type	Upload an existing report, or launch a scan
Credential type / Credentials	The account the scan authenticates with
Scanner	Which scanner appliance runs it
Policy / Option Profile	The scan policy — what is checked
Template / Template type	Report template for the output
Repository / Scan zone / Folder	Where the scanner stores results
Work flow	How results are processed on arrival
Schedule at	Run now or at a set time
Upload document	The report file, when uploading rather than launching

Nessus and Tenable expose the largest set — scanner, policy, template, template type, repository, scan zone and folder — because those are the objects their APIs organise scans around. A field left empty that the tool requires is the usual cause of a launch that reports success and never produces data.

What each choice actually decides

Three of these change the result, not just the mechanics, and they are the ones worth deliberating over:

Type — upload or launch. Uploading parses a report the scanner already produced; launching asks the scanner to run now. An upload can be repeated and re-checked without touching the estate. A launch cannot be undone, and on a fragile production host that distinction matters.

Upload Type — how incoming rows meet existing ones. The single most consequential choice on the form:

Upload type	Effect
Merge	Adds new findings, leaves existing ones as they are
Closure	Anything absent from this report is treated as fixed and closed
Limited Closure	Closes only within the scope this report covers
Ignore	Records the upload without changing finding states

Closure on a partial report closes findings that were never re-tested

A report covering ten of your two hundred hosts, uploaded as Closure, marks findings on the other hundred and ninety as fixed — because they are absent from the file, which is exactly what closure means.

Limited Closure exists for this case: it confines the closing to the hosts actually in the report. When in doubt, that is the safer of the two, and Merge is safer still.

Work flow — how results are processed on arrival. Decides whether findings arrive already approved or require validation first. It is the difference between a scan that immediately moves your published numbers and one that waits for a person.

Policy / Option Profile decides what was checked, and therefore what an absence in the report means. A finding missing because the policy never tested for it is not a finding that was fixed — which is why the policy is worth recording alongside the result.

Schedule at runs the scan later. A scheduled scan that never appears to run is usually scheduled in a different timezone from the person looking for it.

Cancel Scan stops a launched scan that has not completed. It does not remove data already collected.

The upload queue

Reached from the audit, and the first place to look when imported data is questioned.

Column	What it tells you
Report Type	Which kind of report was uploaded
Upload Type	Whether this run merged with existing data or replaced it
Workflow	The processing path applied
Status	Where the job is
Initiated By / Initiated At	Who started it and when
Queue File	The file itself, for confirming what was actually uploaded
Queue Summary	What the job did — rows processed, rows rejected

Upload Type is the one to check on any "the numbers changed unexpectedly" question. A merge and a replace produce very different totals from the same file, and the difference is invisible once the job has finished.

Row actions: Queue File, Queue Summary, Cancel Scan. A failed job additionally offers a re-check, which re-runs the import without re-uploading the file.

Host selection, and App Code

Defining an audit's scope opens a host list carrying Host IP, Host Name, Application Name and App Code.

App Code is your organisation's own identifier for the application — from the CMDB, the change process or the finance system — not something NxSAM generates. It appears here because VA scope is agreed per application while the scan runs per host, and the code is what connects the two conversations.

It is also what survives a rename. Asset names drift; the code usually does not, which is why it is the field to quote when reconciling a scope disagreement with an application team.

Queue Summary — why the numbers differ from the file

This is the most useful dialog in the module, and the one most people never open. A report of 900 findings landing as 640 is not data loss; it is the sum of these counters, and the summary is the only place they are shown.

Hosts

Figure	Means
Mapped hosts on report	Hosts in the file that matched an asset in NxSAM
Unmapped hosts	Hosts in the file with no matching asset — their findings had nowhere to land
Invalid hosts	Rows whose host could not be read at all
Ignored hosts	Hosts deliberately excluded from this audit's scope
Overridden hosts	Hosts whose existing data this upload replaced

Findings

Figure	Means
Total instances added	What actually landed
Duplicate instances	The same finding on the same host more than once in the file
Invalid instances	Rows that could not be parsed into a finding
Ignored instances on merge	Existing findings the merge left untouched
Severity ignored	Findings filtered out by the severity configuration
Vulnerability type ignored	Findings filtered out by type

Unmapped hosts is the number to act on

An unmapped host means the scanner assessed something NxSAM does not know about. Those findings are not hidden or filtered — they were never created, because there was no asset to attach them to.

A steadily growing unmapped count is an inventory problem surfacing as a scanning problem, and it is invisible everywhere else in the product.

Severity-ignored and type-ignored are configuration, not defects

Both counters reflect filters your organisation set deliberately — commonly dropping informational findings at import to keep volumes manageable. A customer asking why their scanner reports more findings than NxSAM is usually looking at these two lines.

They apply at import. Changing the filter does not retrospectively bring back findings that earlier uploads discarded.

VA Vulnerabilities

One row is a host, not a finding. The count columns are described in Reading the Network Security screens.

Viewing one host's findings

Opened from a host row.

Column	Notes
Vulnerability Details	The finding, its plugin and description
Port/Protocol	The same weakness on two ports is two findings
Severity/Risk	Both the scanner's severity and the derived risk
Status	One of the eleven VA statuses
Discovered On	First seen on this host
Last Observed Date	Most recent scan that still saw it — the pair is what tells you whether a fix has landed
SLA Details	Duration and expiry
POC	Proof of concept, where a tester attached one

Discovered On and Last Observed Date together are the most useful pair on this screen. A finding discovered in March and last observed in March is fixed but not yet re-scanned; one last observed yesterday is still present.

Row actions here are Vulnerability History and View Status History — what changed about the finding, and who changed its status.

Overall Vulnerability Status

Groups by vulnerability instead of by host, which is what makes it worth using.

Column	Notes
Vulnerability	The weakness itself, once
Port/Protocol	Where it appears
Severity	As derived
Status	Aggregate state across the hosts it affects
Audit	Which audit reported it
Open/Close Date	When it opened, and closed if it has

A scan returning four thousand findings across two hundred hosts is often sixty distinct vulnerabilities. This screen shows those sixty, and one of them patched everywhere may close a third of the total.

PT Audits

Same shape as VA with a smaller action set: Vulnerability Overview, View Vulnerabilities, Manage Audit Scope, Assign Auditors, Edit Tags, View Status History, Delete Audit, plus Download Audit Status Report, which takes a start and end date and produces a status summary for that window.

PT Vulnerabilities — three views of one audit

By asset

Column	Notes
Asset ID / Asset	The host tested
Accessibility	External or Internal — the only two values
Port	Where the tester worked
No. of Vulnerabilities	Found on this asset
Info Gathered	Reconnaissance recorded against the asset, separate from findings

Accessibility drives prioritisation more than severity does. A Medium on an external host is usually more urgent than a High on an internal one, and this is the column that says which is which.

Info Gathered is what the tester learned that is not itself a weakness — versions, banners, enumerated accounts. It is uploaded separately, has its own type and document, and is worth reading before disputing a finding: it is often the evidence that the finding was reachable.

Grouped

Title and No. of Vulnerabilities — findings collapsed by name, for seeing that one issue affects nine hosts.

Flat

Column	Notes
Vulnerability	The finding
Host / Port	Where
Risk	The tester's rating
Validation	Saved, Submitted or Approved — three values only
Status	One of the eleven PT statuses
Artifacts	Screenshots and files the tester attached as proof

Row actions: Edit Vulnerability, Delete Vulnerability, Vulnerability History.

Artifacts are the difference between a PT finding and a scanner finding. A scanner finding is reproducible by re-running the scanner; a manual one often is not. If a PT finding is disputed and has no artifacts, there is nothing to review.

Segmentation

Tests whether network separation holds.

By source — Host Name, Host, Info. By destination — Hosts ID, Destination Host, Source Host (Host Name), Port, Info.

A finding is a path: this source reached this destination on this port. Info carries what was observed. The question is not how severe it is but whether the path was supposed to exist, which is why the tables pair source and destination rather than ranking by severity.

The segmentation audit list itself carries Audit Details, Business Unit, Status, Auditor, Source Hosts and Requested By. Business Unit matters more here than elsewhere: segmentation is usually tested because two business units are meant to be separated from each other, so the column names the boundary being verified.

The Nmap report view

Where a scan was run with Nmap, its raw output is viewable per host:

Column	What it holds
Port / Protocol	The port and whether TCP or UDP
State	open, closed or filtered
Reason	Why Nmap concluded that — which packet it saw back
Service	What Nmap believes is listening
Product / Version	The software and version it fingerprinted
Extra Info	Anything further the fingerprint returned, such as an OS hint or a module list

Version and Extra Info are the two worth reading. A finding that says "outdated service" is confirmed or refuted by what the fingerprint actually reported, and a disagreement between the two usually means the service was patched without a restart — the running binary is still the old one.

The dashboard

Its two row actions are Download PDF and Download PNG, per widget — the charts are exportable individually for putting into a report or a deck without recreating them.