Workflow: a vulnerability from discovery to closure¶
The end-to-end journey, with the decision points where things actually go wrong. This cuts across every security module — the specifics differ, the shape does not.
Stage 1 — Discovery¶
A finding enters NxSAM by scanner integration, by report upload, or by hand.
What is decided here: its identity. The platform must determine whether this is something it has seen before or something new. For network VA this is the vulnerability key; for application findings it is the tool's identifier plus asset context.
Where it goes wrong:
| Symptom | Cause |
|---|---|
| Counts double after an import | Identity changed, so nothing matched the previous data |
| Findings reopen unexpectedly | Same cause, seen from the other side |
| Two distinct findings merged into one | Key parts coerced to the same value (blank port becomes 0) |
| Findings attached to the wrong asset | Asset identifier in the file differs from the one held |
Detail in the integrations reference.
Stage 2 — Approval¶
A discovered finding is not yet counted. Someone reviews it and approves it into the audit.
Why it exists: scanners report things that are not real. Approval is where a human accepts the finding as genuine before it starts consuming anyone's attention.
The support consequence: unapproved findings are visible inside the audit but absent from dashboards and posture counts. "The dashboard is missing findings I can see in the audit" is this stage, essentially every time.
At import, some findings may be auto-classified as false positives and never enter the open population at all. That is configuration, not data loss.
Stage 3 — SLA assignment¶
On approval the finding is given an SLA date derived from its severity.
What to know:
- The date is stored; the overdue state is computed live against today's date.
- Changing SLA configuration does not re-date existing findings.
- Shortening an SLA can push a large number of findings overdue immediately, because the comparison is against today.
- A finding with no SLA date is never overdue — and never compliant either. It is simply outside SLA reporting.
Stage 4 — Ownership and remediation¶
The finding becomes visible to whoever owns the asset, and moves through working statuses: New, Patch in progress, Patched.
The critical misunderstanding lives here. Patched does not close a finding. It records that work was done. The finding remains open, keeps ageing, and keeps counting.
Where it goes wrong:
| Symptom | Cause |
|---|---|
| "We fixed it but it still shows open" | Marked Patched, not Validated |
| "The owner cannot see it" | Asset ownership, not role |
| "It is assigned to someone who left" | Ownership follows the asset, not the person |
Stage 5 — Validation and closure¶
Someone confirms the fix actually worked and sets the finding to Validated. Only this — or Exception Handled — stops the clock.
Statuses that look like closure and are not: Risk accepted, Not Applicable, Duplicate, Expired. All four continue to count as open. See the counting rules.
Stage 6 — Reopening¶
A validated finding seen again by a later scan returns as Reopen.
What it means: the weakness is present again. Usually a rolled-back patch, a host rebuilt from an old image, or configuration drift.
What to check when it looks wrong: whether identity changed. If the vulnerability key was reconfigured, findings can appear to reopen en masse when nothing on the systems changed at all. A sudden reopen spike with no corresponding infrastructure event is an identity question, not a security one.
The alternative path: accepting the risk¶
At any point after approval, a deviation may be raised to accept the risk for a fixed period. It is a dated decision with an approver, not a way of removing the finding.
The finding stays open throughout. When the deviation expires the finding continues exactly as before — it was never closed. See the deviations reference.
Diagnostic summary¶
Given a symptom, the stage to examine first:
| Reported symptom | Stage |
|---|---|
| Counts jumped or doubled | 1 — identity |
| Findings visible in audit, missing from dashboard | 2 — approval |
| Overdue figures changed with no data edit | 3 — SLA computed live |
| "We fixed it but it is still open" | 4/5 — Patched is not Validated |
| Sudden mass reopen | 6, then back to 1 — identity changed |
| Accepted risk still counting as open | Alternative path — by design |