Application Security: support reference¶

Internal. The customer-facing explanation is in Reading the Application Security screens, How an audit is created and the screen reference.

Most AppSec tickets are one of four things: a finding that is not counted, an audit in the wrong period, an edit that changed more than the caller intended, or a status that will not move.

The two-status model¶

A finding carries Validation (has it been confirmed) and Current Status (what is being done about it). They are independent, and almost every "the numbers are wrong" question comes from reading one as the other.

Nothing is counted anywhere until Validation reaches Approved.
Discovered On is blank until approval — that is the field being unset, not missing data.
Current Status has fourteen values, of which only two close the finding. Risk accepted is still open.

Full detail in Two status fields.

The edit that changes more than expected¶

Edit Vulnerability Master Details sits directly beside Edit Vulnerability in the same row menu, and the dialogs look similar.

Action	Scope
Edit Vulnerability	The one occurrence you opened
Edit Vulnerability Master Details	The catalogue entry — every occurrence, every audit, every asset

A caller reporting "the description changed on findings I never touched" has almost certainly used the second. There is no per-occurrence copy to fall back on: the master's text is inherited live, so the correction is to fix the master again rather than to restore one finding.

Audits in the wrong period¶

Three dates exist and only one drives reporting:

The scan date — when the tool ran.
The import date — when it reached NxSAM.
The date the audit reached a final state — what dashboards and reports use.

A scan run in March, imported in April, completed in May is a May audit. This single rule resolves most "findings appearing in the wrong month" tickets.

An audit that is not considered keeps its findings and shows them on the module screen, while contributing to nothing aggregated. If a module screen and a dashboard disagree, check considered before anything else.

Statuses that will not move¶

The status dropdown offers only transitions legal from the current state and permitted for the caller's role. A missing option is one or the other, never a defect.

An audit sitting in Approved with nothing happening usually has no auditor assigned — it can be requested and approved without one, and cannot be worked.

A reverted audit returns with its start date cleared and will not save until it is set again.

Where findings come from¶

Audits arrive by four routes, and the route explains the audit's shape:

Route	Tell-tale
Requested in the UI	Complete audit-property chips
Bulk import	Missing chips — the column was absent from the file
Tool integration	Audits nobody created, named after the scan
Re-test	A Confirmatory chip and a parent audit

"Audits are appearing on their own" is an integration doing its job. The control is the integration's scope, not deletion.

Import classification¶

Checkmarx-style integrations can classify findings on the way in. A finding auto-marked false positive never enters the open population — it is not hidden behind a filter, and nothing on the screen explains its absence. "The scan had 800 findings, NxSAM shows 600" is usually this. See import classification.

Permission-gated controls¶

Absent, not disabled. Before treating a missing control as a defect, compare what the caller can see against their role:

Approve / reject
Edit vulnerability master details
Delete
Export
Artifacts (viewing a finding's proof-of-concept)

What to collect before escalating¶

Audit ID and client — audit names repeat across clients.
Validation and Current Status of the specific finding, quoted exactly.
Whether the audit is considered, and when it reached a final state.
For "changed unexpectedly": the finding's Vulnerability History and View Status History, which name who changed what and when.
For count disputes: the same number from the module screen and from the dashboard.