How findings are identified, matched and classified on import¶
When a scan is imported, NxSAM has to decide, for every row, whether it is a finding it has seen before or a new one. That single decision drives almost everything downstream: whether an item is reopened or created, whether its age and SLA continue or restart, and whether closed findings come back.
Nearly every "the numbers jumped after a scan" escalation traces to this page.
Network VA: the vulnerability key¶
Default behaviour¶
Out of the box, Enable Key for VA Vulnerability (Configurations → System → System Settings) is off. With it off, a VA finding's identity is the tool's own identifier (the track ID) carried in the scan file.
The setting applies to Nessus VA uploads only. When it is on, findings are matched using the Key Columns / Key Header set on the Tenable configuration page.
That is usually what you want, and it means identity is entirely the scanner's opinion. It also means that if the scanner changes how it issues identifiers — a plugin rewrite, a platform migration, a different export format — NxSAM sees a completely new set of findings, and the previous ones stop being observed.
When the key is enabled¶
With the setting on, NxSAM builds its own composite key from columns you choose, joined by a configured separator. The available parts are:
| Part | Notes |
|---|---|
| Port | Empty is coerced to 0; must otherwise be numeric |
| Protocol | Empty is coerced to 0 |
| Plugin ID | Must be numeric |
| Host IP | |
| Host Master ID | Must be numeric |
A manual upload may also carry an explicit key column. If that column is present and its value is valid, it wins outright — the configured columns are not consulted.
The three behaviours that surprise people¶
Changing the key columns redefines what 'the same finding' means
The key is what matches an incoming row to an existing record. Change the columns and the next import will not match the previous data: existing open findings stop being observed, and their equivalents arrive as brand-new findings. Counts appear to double.
Treat a change to VA key columns as a data migration, not a preference. Plan it, and expect a one-off discontinuity in trend charts.
An empty port and port zero are the same identity
Port and Protocol are coerced to 0 when blank. A finding with no port recorded and a
finding on port 0 therefore produce the same key. On hosts where the scanner omits
port for some plugin types, distinct findings can collapse into one.
Invalid key parts are dropped, not rejected
If a configured part is missing or fails its type check — a non-numeric Plugin ID, for example — that part is discarded and the key is built from whatever remains. The import does not fail. It records the invalid parts and proceeds with a shorter, less specific key, which matches more loosely than intended.
If every part is invalid, identity falls back to the tool's track ID.
Support check: when VA counts move unexpectedly after an import, establish first whether the key is enabled, and whether the incoming file actually carries every configured column. A column that is present in one export format and absent in another is the usual cause.
Application security: automatic classification on import¶
Tool integrations such as Checkmarx do not merely import findings — they can classify them on the way in. The configuration takes the shape:
when report field matches condition / value → mark as approved, not approved, or false positive
Three mappings are configured per tool: an approval condition, a non-approval condition, and a false-positive condition, each with its own field and comparison value.
The consequences worth knowing:
- A finding auto-marked false positive never enters the open population. It is not hidden by a filter; it was classified at import. Someone looking for it in the open list will not find it, and nothing on that screen explains why.
- Changing the mapping does not reclassify history. It applies to subsequent imports only. After a mapping change, older findings and newer ones will have been judged by different rules.
- Unmatched findings fall through to the default. A finding matching none of the three conditions is not classified by this mechanism at all.
Support check: "the scan had 800 findings but NxSAM shows 600" is usually the approval or false-positive mapping doing its job. Compare the tool's own report against the configured conditions before treating it as data loss.
What each integration actually needs¶
Credentials differ by tool, but the shape is consistent — a reachable endpoint, an account, and a scope. For example, a Qualys connection is defined by:
| Field | Purpose |
|---|---|
| URL | The Qualys API base URL for your platform. Platform-specific — the wrong regional URL authenticates but returns nothing. |
| Port | Usually 443. |
| Username / Password | An API-capable service account, not an interactive user. |
| Client | Which NxSAM tenant the imported data belongs to. |
Cloud integrations such as Prisma follow the same pattern on their own configuration form (Configurations → Integration → Prisma): an Enable toggle, API URL, Username and Password, and a Use Proxy toggle that reveals a Proxy URL when on.
The Enable toggle and Test Connection are paired deliberately — the form will not save an enabled integration whose connection has not been tested, which is what stops a typo in the API URL from being discovered days later by an empty sync.
Two failure modes look identical from the UI
A connection that authenticates but returns nothing looks exactly like a connection that is working and genuinely has nothing to report. Distinguish them by checking whether the account's scope covers the assets you expect — the most common cause is a service account with valid credentials but no visibility of the target scope.
Triage order for import problems¶
- Did the count jump or double? → VA key columns changed, or a column is missing from the new export format.
- Are findings missing entirely? → auto-classification mapping (AppSec), or account scope (any tool).
- Did findings reopen unexpectedly? → identity changed, so previously matched records no longer match.
- Did nothing import at all? → authentication succeeded but scope is empty; check the service account's permissions, not the credentials.