How NxSAM Works¶
NxSAM collects security findings from many different tools, keeps them in one place, and tracks each one until it is fixed and verified. Everything else in this manual is a variation on that idea, so it is worth understanding once.
The four things NxSAM keeps track of¶
| What it is | |
|---|---|
| Asset | Something that can have a weakness — a web application, a mobile app, an API, a server, a container image. |
| Audit | One assessment of one or more assets. A scan you imported, or a manual test your team performed. |
| Vulnerability | A single weakness found by an audit, on a specific asset. |
| Deviation | A formal, time-limited decision to accept a vulnerability rather than fix it now. |
An audit belongs to an asset. A vulnerability belongs to an audit. That chain is why the same finding appears in several places in the interface — you are looking at the same record from different directions.
The life of a vulnerability¶
- Discovered. A scan is imported, or a tester records a finding by hand.
- Approved. Someone reviews the finding and accepts it into the audit. Until this happens, it is not counted in dashboards.
- Assigned an SLA. Based on its severity, the vulnerability is given a date by which it should be resolved. More severe findings get less time.
- Worked on. The owner investigates and fixes it, moving it through statuses such as Patch in progress and Patched.
- Validated. Someone confirms the fix actually worked. This is the step that closes it. A finding marked as patched but not yet validated is still open.
- Or reopened. If a later scan finds the same weakness again, it comes back as Reopen and continues to age.
Patched is not closed
The most common misunderstanding in NxSAM. Marking something Patched records that work was done; marking it Validated records that the fix was verified. Only the second one closes the finding and stops the SLA clock.
Severity and SLA¶
Every vulnerability carries a severity — Critical, High, Medium, Low or Informational. Severity drives two things: how it is ranked for attention, and how long you have to fix it before it is overdue.
The exact number of days per severity is configured per organisation, so check your own SLA configuration rather than assuming. What is universal is the shape: the more severe the finding, the shorter the window.
A vulnerability is overdue when today's date has passed its SLA date and it has not been closed. This is worked out fresh each time you look, which is why something can become overdue overnight without anyone changing it.
Deviations: accepting risk on purpose¶
Sometimes a finding cannot be fixed in the time available — the fix needs a vendor release, or a change freeze is in effect. A deviation records that decision formally: who asked, who approved, why, and until when.
Deviations expire. When one does, the vulnerability returns to normal tracking. The point is that risk acceptance is a dated, reviewable decision rather than a finding quietly disappearing.
Who sees what¶
NxSAM shows people only the assets they are responsible for. An asset owner sees their own applications; a security analyst sees the whole estate. If a colleague cannot see something you can, that is access control working, not a fault — the fix is a permission change, not a data change.
Where to go next¶
- To find your way around the interface, see Navigating NxSAM.
- Each security module — application, API, network, container, cloud — follows the same audit-and-vulnerability pattern described here, with its own specifics.